Replacing a Shared Disk on a 2008 Failover Cluster

Several months ago, I posted a blog on adding a new disk to an existing cluster. Another question we get asked a lot is “How do I replace a disk?”

In this blog, I’ll walkthrough the process of replacing a 1GB disk with a 2GB disk. This process is similar to how you could go about doing a SAN migration where you are replacing all of your shared disks with storage from a new SAN.

The preferred way of getting a larger cluster disk is to use the built in capability of most SANs to dynamically expand a LUN then use an OS utility like DiskPart or Disk Manager to extend the size of the disk. If that’s not feasible or you simply want to replace a LUN with a larger one or as I mentioned, as part of a SAN migration, this process works well.

The first thing we need to do is present your new disk to the cluster. The nuts and bolts of how to do that are outside the scope of this post so just ask your SAN administrator for a new LUN and present it to all nodes of the cluster. Since by default in Server 2008, we leave new LUNs offline, there’s no risk in presenting a new LUN to all nodes at the same time. In the below figure is what Disk Manager would look like after my new disk had been presented.


Figure 1.

Note how the new disk ‘Disk 9’ is in an ‘Offline’ state. In order to prepare it to be the replacement disk for an existing disk, we need to do the following.

  • Online the disk
  • Initialize the disk (MBR or GPT)
  • Create a new volume
  • Format as either FAT32 or NTFS

Note: You do NOT need to assign the new drive a drive letter during the format process.


Figure 2.

Figure 2 now shows ‘Disk 9’ as Online and formatted with an NTFS partition. At this point, we can now go into Failover Cluster Manager to complete the rest of the replacement.

The screenshot below shows a File Server group with ‘Cluster Disk X:’ of size 1GB. This is the disk that I am going to replace with the new 2GB disk from above.


Figure 3.

Failover Cluster Manager has a built in ‘repair’ functionality that allows replacing a failed disk with a new disk. Since we’re not really replacing a failed disk but a working one, we need to put that disk into an 'offline' state so that the ‘repair’ function will be enabled.

Figure 4.

Now right-click the disk resource, ‘More actions…’, ‘Repair’. This will launch the ‘Repair a Disk Resource’ window.


Figure 5.

Figure 5 shows the disk that we presented and created in Figure 2. Select that disk, click [OK]/

Now bring the resource online. You’ll see in Figure 8. that the disk now shows as 2GB. We essentially swapped one disk for another without having to worry about resource dependencies. If the drive letter needs to be changed to match the old drive letter, do so now.


Figure 6.

So now that we’ve replaced the 1GB disk with the 2GB disk, what happened to the old disk? When you used the ‘Repair’ function, the old disk got removed from under the control of the cluster. The final step in the replacement is to bring the old disk back into the cluster so that we can bring it online and move the data from the old disk to the new.

To add the disk back in, from Failover Cluster Manager, go to the ‘Storage’ group. In the right-most column, in the ‘Actions’ pane, click on ‘Add a disk’


Figure 7.

Figure 8 shows the disk we just removed from the cluster. Select this disk, click [OK]


Figure 8.

This disk now shows up in ‘Available Storage’. Figure 12.


Figure 9..

The final steps in the replacement are to assign this disk a drive letter so that it’s exposed to the OS to get your data moved from the old disk to the new.


Figure 10.


Now that ‘Cluster Disk 7’ (the old disk) shows as online and has a drive letter (D:) , you can use your favorite data copy method to move the data from the old disk to the new disk. If you are no longer going to use the old LUN, you can simply delete this resource from Failover Cluster Manager and unpresent that LUN from all nodes of the cluster. That finishes up the clean-up process. You can also just leave the disk in ‘Available Storage’, format it, and have it ready for some other ‘Service or application’ cluster group to use in the future.

Hope you find this blog useful especially for those SAN migrations.

Jeff Hughes
Senior Support Escalation Engineer
Microsoft Enterprise Platforms Support