How To Move A Storage Group and Database on a CCR Cluster

When I started doing research for this task, I found a lot of conflicting information. It took some time to get all the relevant information together, but the task was completed successfully, so I wanted to take the time to document exactly what I did, in the hopes that it may benefit someone else.


The steps detailed in this article were performed on an Exchange 2007 SP2 (w/ hotfix rollup 4) CCR cluster. My cluster node disks are configured as follows:


C: - System, local drive (RAID1)
D: - Logs, local drive (RAID1)
E: - Applications (Exchange), local drive (RAID1)
H: - Databases 1, SAN drive
I: - Databases 2, SAN drive
J: - Transaction Logs 1, SAN drive
K: - Transaction Logs 2, SAN drive


Our CCR cluster contains 25 databases, spread over the two database drives (H: and I:). In general, for each database on drive H:, its related system and transaction logs are stored on drive J:. For each database on drive I:, its related system and transaction logs are stored on drive K:.


The problem: Over time, the databases on drive H: have grown in size at a faster rate than the databases on drive I:. Although free disk space was not yet an issue, I wanted to take action now, to balance out the disk usage before it became a problem at a more inopportune time. The difference in free space between drives H: and I: was approximately 50 GB. In reviewing the sizes of our databases, I found that the Accounting database, at 22 GB, was the best candidate for the move. This database is in a storage group named "SG Accounting". I should also note that each storage group and database lives in its own subfolder. Therefore, the Accounting storage group lives in the "J:\SG Accounting" subfolder, while the Accounting database lives in "H:\SG Accounting" subfolder.


The first thing I did was suspend the transaction log shipping between the CCR nodes for the SG Accounting storage group:


Suspend-StorageGroupCopy "MailboxServer\SG Accounting"


At this point, the database is still online and active. All we did was suspend log shipping for that storage group. All other storage groups are still replicating normally.


Next, I have to dismount the database, so the files can be moved. This will take the database offline, so be sure to schedule this task in the wee hours of the morning, when no one from Accounting is likely to be using their mailbox.


Dismount-Database "MailboxServer\SG Accounting\Accounting"


Although only the database drives have significant differences in free disk space, since we're moving the database from drive H: to drive I:, we'll also want to move the storage group system and transaction logs from drive J: to drive K:, in order to maintain the logical layout we described earlier.


To move the storage group system and log file paths, we'll use the following command:


Move-StorageGroupPath "MailboxServer\SG Accounting" -LogFolder "K:\SG Accounting" -SystemFolderPath "K:\SG Accounting" -ConfigurationOnly


Red Flag! - The above command only modifies the location of the SystemFolderPath and LogFolder in Active Directory. No files are actually moved on disk. You must manually move the files yourself - on both nodes of the CCR cluster. Personally, I just copy the files to the new location, in case I have to roll back to the old location.


With the storage group files moved, it's time to move the database files. Again, the following command will only modify the location in Active Directory. You will have to move the files yourself.


Move-DatabasePath "MailboxServer\SG Accounting\Accounting" -EdbFilePath "I:\SG Accounting" -ConfigurationOnly


Don't forget to move the database files on both nodes of the cluster.


With the storage group files and the databases in their new locations, all that's left is to mount the database and turn log shipping back on.


Mount-Database "MailboxServer\SG Accounting"


Resume-StorageGroupCopy "MailboxServer\SG Accounting\Accounting"


That's it. You can check on the status of the log shipping with the following command:


Get-StorageGroupCopyStatus


In the output, look for "Healthy" under SummaryCopyStatus, and "0" under CopyQueueLength. Depending on how long the database was offline, it could take a few minutes for log shipping to catch up. On my cluster, copying a 22 GB database, search index files, and another 1 GB of transaction logs, the Accounting database was only offline for about 14 minutes. Since there almost no activity on my system at the time I performed these steps, the databases were back in sync in less than a minute.


The last step was to go back and delete the old database and storage group files. In the end, the database drives on my cluster nodes were within 5 GB of each other, which is less than a 1% difference. I know it won't last long, but I know I won't have to worry about disk space for a little while longer.


Thanks for stopping by!


Mike