Migrate SQL Server Cluster Storage to New Disks

To migrate cluster storage for a SQL Server failover cluster, swap the disks and keep every drive letter. If the new disks take over the old drive letters, nothing else has to change. No database, no job and no connection string needs an edit. The only long downtime is the file copy.

Plan the Cluster Storage Swap

A failover cluster instance keeps its data on shared disks. Each disk is a cluster resource, and the SQL Server resource depends on it. You can’t unplug a disk. You add the new disk, move the data, and then tell the instance to use the new disk instead.

The example assumes an old SAN with five disks and a new SAN with five matching ones. The table shows how they map.

The method has two layers. The data disks keep their drive letters, so the instance never notices. The quorum and MSDTC disks are replaced through the cluster’s own wizards. Both are described below, in the order you would run them.

Check What Lives Where

Before the work, list what sits on each volume of the cluster storage. This query groups every database file by drive and type. On the cluster, run it on the instance to confirm that nothing important lives on a volume you forgot.

SELECT UPPER(LEFT(physical_name, 3)) AS Volume, type_desc AS FileType,
       COUNT(*) AS Files, CONVERT(decimal(12,1), SUM(size) * 8 / 1024.0) AS SizeMB
FROM sys.master_files
GROUP BY UPPER(LEFT(physical_name, 3)), type_desc
ORDER BY Volume, FileType;

This table is from a development server with two volumes. On your cluster it shows the data, log and tempdb disks. Add up the sizes. The new disks must hold that total plus growth.

The Steps for the SQL Server Disks

Take full backups of all databases first, system databases included. Keep them off the disks being replaced. They are for disaster recovery only, and you won’t need them if every step works.

1. Present the new disks to every cluster node. In Failover Cluster Manager, they appear under Storage, Disks, as available storage.
2. Add them to the SQL Server role. Format them with the same allocation unit size as the old disks, which is a habit, not a rule.
3. Test before the cutover. Move the role to the other node and back with the new disks attached. That proves both nodes can reach them.
4. Take the SQL Server resource offline in Failover Cluster Manager. Only the node that owns the role runs the instance, so one offline step is enough. Don’t stop the service from the Services console, because the cluster would restart it. Keep the disks themselves online.
5. In Failover Cluster Manager, open Roles, the SQL Server role, the SQL Server resource, Properties, and the Dependencies tab. Remove the old data, log and tempdb disks. A dependency tells the cluster not to start the instance until that disk is online.
6. Copy every folder from each old disk to its new disk, unchanged. Use robocopy from an elevated prompt, and copy the permissions with the files.
7. Swap the drive letters. In Disk Management on the owner node, give each old disk a free letter. Then give each new disk the old letter.
8. Add the new disks as dependencies of the SQL Server resource. Bring SQL Server online.
9. Test the applications. When they pass, remove the old disks from the cluster.

The Copy Step

The copy is where most mistakes happen. The command mirrors a whole disk, and it copies the security settings that the SQL Server service account needs. This is a command for an elevated command prompt, not T-SQL. The instance must be offline when you run it.

robocopy R:\ N:\ /MIR /COPY:DATSO /DCOPY:DAT /R:1 /W:1 /XD "System Volume Information" "$RECYCLE.BIN"

Two cautions apply. /MIR deletes files in the destination that aren’t in the source, so a swapped source and destination destroys data. Add /L the first time. It lists what would happen and copies nothing. And /COPY:DATSO copies data, attributes, timestamps, security and owner. /COPYALL also copies auditing information, and it fails without the Manage Auditing right.

Exit codes below 8 mean success. Code 1 means files were copied. Run the command twice. The second run should copy nothing and return 0, which proves the two disks match.

If the instance fails to start and the error log mentions operating system error 5, the permissions didn’t travel. Compare the folder security on the new disk with the old one, and copy it again.

Other Questions

Mounted folders. A disk that is mounted into a folder needs its host volume in the cluster as well. The host volume is a disk resource, and SQL Server must depend on both.

Less downtime. A SAN can copy or virtualize the old LUN while it stays online. That shortens the outage to a reboot or a failover. If the SAN team offers it, it beats copying files by hand.

Backup and restore, or log shipping. Restore each database to the new disks under a temporary name. Apply a final differential or log backup in the window, and rename. The downtime is short, and every database needs its own steps.

Changing paths with T-SQL. If the new disks use different letters, change the file paths instead. The master database moves through the startup parameters, and the Resource database stays where it is. For tempdb, model and msdb, this query prints the statements for you. It changes nothing. Review the list before you run any of it. The statements change only the catalog, so the files must be in place before the next start.

DECLARE @newFolder nvarchar(260) = N'N:\SQLData\';
SELECT CONCAT(N'ALTER DATABASE ', QUOTENAME(DB_NAME(database_id)), N' MODIFY FILE (NAME = ', QUOTENAME(name),
              N', FILENAME = N''', @newFolder, RIGHT(physical_name, CHARINDEX(N'\', REVERSE(physical_name)) - 1), N''');') AS StatementToReview
FROM sys.master_files
WHERE database_id IN (2, 3, 4)
ORDER BY database_id, file_id;

Move the model and msdb files first. With the instance stopped, copy them to the new folder. Give the service account full control of that folder. Missing model files mean SQL Server can’t create tempdb, and the instance can fail to start. Missing msdb files mean msdb fails to open. The tempdb files are created at startup, so tempdb only needs the folder to exist.

The Quorum and MSDTC Disks

Replace the quorum witness in the Configure Cluster Quorum Settings wizard. Choose a disk witness, pick the new disk, and finish. A file share witness or a cloud witness is also possible and needs no disk at all.

The simplest way to move MSDTC is to rebuild it. Remove the clustered MSDTC role, then create it again with the Configure Role wizard. Pick Distributed Transaction Coordinator, name it, and select the new disk.

Is the Swap Riskier Than T-SQL?

You could argue that a drive letter swap is riskier than changing paths in T-SQL. It touches the cluster more, and it touches SQL Server less. For many databases and one outage window, that is the better trade.

What to Remember

Run the whole cluster storage plan on a test cluster first. Keep the old disks until the applications have passed their checks.

A storage migration is not a copy job, it is a promise that nothing will notice.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.