Best Way to Change RAID Configuration on Windows Server and Restore with More Space

clonezillagpartedntfsraidwindows-server-2008-r2

I have a Dell Server with 6 1TB Drives in it. Currently the drives are configured into two RAID groups:

Existing

Group 1: 2 x 1TB in RAID 1 (1TB Usable) C: Drive (Windows 2008 r2 Boot Partition NTFS)

Group 2: 4 x 1TB in RAID 10 (2TB Usable) E: Drive (NTFS)

I would like to change the RAID Configuration to

After

Group 1: 6 x 1TB in RAID 5 (5TB Usable) with 2 NTFS partitions on it.

What is the best way to do this?

I am currently thinking of this:

Use clonezilla to image each of the partitions separately.
Reconfigure the RAID
Use GParted to create the partitions
Use Clonezilla to restore the partitions

Is this the best way? Or is there an easier way?

Best Answer

Using 3rd party tools to write NTFS filesystems scares me, personally.

I'd copy the contents of the RAID-10 partition to another machine (probably two machines, actually) using something like ROBOCOPY or XCOPY to preserve the permissions and metadata. I'd also make sure I had a good backup.

Then I'd take two backups of the RAID-1 boot volume using the built-in Windows Backup. I'd probably test restore one of the backups to another machine (using the restore functionality built into the W2K8 installation media) just to make sure it's good.

Then I'd reconfigure the RAID on the server and restore the Windows Backup of the boot volume (partitioning as I'd see fit... personally I wouldn't make two partitions but you can do what you want).

Finally, I'd copy back over the data from the backup copy I made of the RAID-10 volume using the same tools to preserve the permissions and metadata.

That can all be accomplished using Microsoft tools only and doesn't use any unsupported NTFS implementations. Call me paranoid if you will.

As an aside: I'd create a RAID-6 volume on those disks but not a RAID-5. That's just too big to trust to RAID-5 and bit-error rates.

Related Solutions

Split RAID array at controller, or at LVM

If the controller will allow you to provision a 10-disk raid 10 (rather than 2 8-disk units with 2 disks left over) that would probably be the best bet. It's simple to manage, you get good write performance with battery backed cache and the RAID card does all the heavy lifting, monitoring, management. Just install the RAID card's agent in the OS so you can reconfigure and monitor status from within the OS and you should be set.

Putting everything in the care of the RAID card makes the quality of the software on the card the most important factor. I have had RAID cards which have crashed causing the whole IO subsystem to "go away" and requiring a server reboot, I've even had instances of a card completely losing the array configuration requiring either it to be carefully reconfigured from the console or the whole thing to be restored from backups. The chances that you, with your one server, would see any particular problem are low, but if you had hundreds or thousands of servers you would probably see these kinds of problems periodically. Maybe newer hardware is better, I haven't had these kinds of problems in a while.

On the other hand it is possible and even probable that the IO scheduling in Linux is better than what's on the RAID card so either presenting each disk individually or as 5 RAID 1 units and using LVM to stripe across them might give the best read performance. Battery backed write cache is critical for good write performance though so I wouldn't suggest any configuration that doesn't have that feature. Even if you can present the disks as a JBOD and have battery backed write cache enabled at the same time there is additional management overhead and complexity to using Linux software raid and smartd hardware monitoring. It's easy enough to get set up but you need to work through the procedure to handle drive failures, including the boot drive. It's not as simple as pop out the disk with the yellow blinky light and replace. Extra complexity can create room for error.

So I recommend a 10-disk RAID 10 if your controller can do it or 5 RAID 1s with LVM striping if it can't. If you test out your hardware and find that JBOD and Linux RAID works better than use that but you should specifically test for good random write performance across a large portion of the disk using something like sysbench rather than just sequential reads using dd.

Prepare a disk to be imaged by Clonezilla for use on smaller disks

Inside every clonezilla image, there is a file called sda-pt.parted. You can edit the sector size of /dev/sda to be smaller than your target hard drive.

Here is how we do it:

Install OS and programs
Shrink partition in OS to lowest possible value (we find under 80 works best)
Sysprep and clone
Edit image/sda-pt.parted

Below is a sample of an edited sda-pt.parted file

Model: ATA ST31000524AS (scsi)
Disk /dev/sda: 78200000s
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start    End        Size       Type     File system  Flags
1      2048s    206847s    204800s    primary  ntfs         boot
2      206848s  78135295s  77928448s  primary  ntfs

Original:

Model: ATA ST31000524AS (scsi)
Disk /dev/sda: 1953525168s

Best Answer

Related Solutions

Split RAID array at controller, or at LVM

Prepare a disk to be imaged by Clonezilla for use on smaller disks

Related Topic