July 3, 2015 at 7:32 am
Hi All,
As part of a migration of data to a new SAN I have hit a bit of a snag in the migration. In summary what will happen is user database data files will be moved from one LUN (say drive F:\) to a new LUN (say drive G:\). Once all the data is migrated, plan is to remove dependency of that drive from SQL server and remove the drive and delete the LUN. So far, so good.
However one of the LUNs (drive D:\) destined to be deleted also hosts the instance default directories, i.e. everything under \MSSQL11.MSSQLSERVER (Data, Backups, FTData, JOBS, etc). BOL has articles on how to migrate system databases, including tempdb. But there is no guidance that I could find on how to relocate other folders. There are forums where users have listed registry changes, etc that can achieve this but these are steps I am unwilling to take on a production server.
So my plan is:
1) Add new drive to cluster (drive E:\), sufficiently large enough to host instance default folders
2) Shutdown SQL server
3) Copy all default folders to new drive
4) Swap drive letters so that new drive is now D:\
5) Start SQL server and if everything works, delete the original drive (which is now drive E:\).
Has anyone ever done anything similar? Would it work?
Thanks!
July 6, 2015 at 3:52 am
I've moved what I would call the static folders before and yes theyre in registry keys in the sql instances hive. Why are you changing drive letters, why not retain them?
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
July 6, 2015 at 4:16 am
Hi Perry,
It was more of a drive-letter swap. The reason was that new, faster storage has been provisioned so data on the old drive was moved to the new. And I wanted to "trick" SQL into continuing to think it was accessing the old drive.
Anyway, to my great relief, the swap went fine. The method I would recommend (because it worked for me!) is:
1) Take the SQL service, SQL Agent service and SQL application offline via Failover Cluster Manager
2) Copy data using ROBOCOPY <source> <target> /MIR (e.g. robocopy D:\Data\MSSQL11.MSSQLSERVER\ G:\Data\MSSQL11.MSSQLSERVER\ /MIR)
3) Copy security permissions (ACL's) and owner details using ROBOCOPY <source> <target> /E /Copy:SO /IS/ /IT
4) In Failover Cluster Manager swap drive letters so that D:\ becomes G:\ and vice versa
5) Bring online all the services taken off line in step 1. If everything has worked the cluster will be online. Happy days!
6) Perform checkdb, failover test, etc.
July 6, 2015 at 10:17 am
feersum_endjinn (7/6/2015)
Hi Perry,It was more of a drive-letter swap. The reason was that new, faster storage has been provisioned so data on the old drive was moved to the new. And I wanted to "trick" SQL into continuing to think it was accessing the old drive.
Anyway, to my great relief, the swap went fine. The method I would recommend (because it worked for me!) is:
1) Take the SQL service, SQL Agent service and SQL application offline via Failover Cluster Manager
2) Copy data using ROBOCOPY <source> <target> /MIR (e.g. robocopy D:\Data\MSSQL11.MSSQLSERVER\ G:\Data\MSSQL11.MSSQLSERVER\ /MIR)
3) Copy security permissions (ACL's) and owner details using ROBOCOPY <source> <target> /E /Copy:SO /IS/ /IT
4) In Failover Cluster Manager swap drive letters so that D:\ becomes G:\ and vice versa
5) Bring online all the services taken off line in step 1. If everything has worked the cluster will be online. Happy days!
6) Perform checkdb, failover test, etc.
Yes I have completed this myself just recently for a number of clusters, with the sql service offline you can remove\add and copy the data to your hearts content. Just ensure the final drives have the correct ACLs, drive letters and dependencies are set on the new drives within the cluster
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply