Recently, we got a new SAN (yeah!!!), unfortunately, our SAN vendor’s migration utilities are priced at such a level, that there is no way we were going to use them. So we had to resort to manually moving the disks. Fortunately in this instance all of the directory names and data files were the same, so there was no need to do anything internal to SQL Server. What happens when you have to make those changes will be part II of this post.
I would feel remiss to not include a statement about discussing your storage layout and performance needs with you Storage Administrator, but that’s outside of the scope of this particular blog post.
Of course, with any all activity like this, the #1 rule is TAKE A BACKUP BEFORE DOING ANY OF THIS! This is a NON-destructive process, but better safe than sorry.
If you don’t need to change any directory names—the process is as simple:
- Mount the drives in your cluster (See my post here on how to do that)
- Make your SQL Server service offline–I used failover cluster manager to do this
- Copy the directories from your source drive to your target drive
- Remove the older drives from your cluster service and take them offline (This isn’t a necessity, but I do it to prevent any possible conflict). You can bring these drives back if needed–you are not destroying any data
- Select the drive you had chosen as the root drive (S:\) and change the drive letter to match what your SQL Server instance is expecting. The mount points underneath it should be maintained.
- Make the SQL Server service dependent on the root disk. In order to do this right click on the SQL Server service name > Dependencies Tab > Add. See screenshot below
- Restart your SQL Service–everything should be ready to go.
If anything fails investigate the alert log, for both Windows and SQL Server, and resolve any issues. A common problem would be the dependency or a directory not being copied (generally SQL binary files)
Of course, this is assuming you do not have to change directory names or move any databases. More on that next week.
