I'd mount the filesystem and copy it at a file level rather than trying to disk image it. I suspect it'll end up being faster for you and you won't have to contend with disk partitioning issues.
The built-in (at least in Windows Vista and newer) robocopy
command can copy all the files, metadata, and ACLs pretty easily.
You could use a Linux distro with GPT support and the ntfsprogs ntfsclone
to close the filesytem.
I wouldn't copy the filesystem raw at a block level, though. I'd have a hard time trusting it after doing that.
mdadm doesn't recognize partitions, the Linux kernel does. A software RAID array doesn't need to know or care what type of partitions the disk uses, because it just uses the block devices that the kernel provides for the partitions. I'm using mdadm arrays on GPT disks on several computers and they work fine.
The partition layout you described doesn't make sense:
/dev/sda
/dev/sda1 <- GPT type partition
/dev/sda1 <- exists within the GPT part, member of md127
/dev/sda2 <- exists within the GPT part, empty
/dev/sdb
/dev/sdb1 <- GPT type partition
/dev/sdb1 <- exists within the GPT part, member of md127
In particular, it looks like you're saying that sda2
is located within sda1
. Partitions don't exist within other partitions, and GPT is a characteristic of the whole-disk device, not a partition. I think what you actually mean is:
/dev/sda <- GPT disk
/dev/sda1 <- member of md127
/dev/sda2 <- empty
/dev/sdb <- GPT disk
/dev/sdb1 <- member of md127
However, your blkid
output says that /dev/sda1
currently contains an Ext4 filesystem, not a RAID superblock — it's not a member of md127
. It's not clear how that filesystem got there, since you said that you were using it as a RAID component, but since your story is long and full of twists, I suspect there may have been points where things happened that you didn't realize had happened. My suggestion at this point is:
- Assemble the array in degraded mode using just
/dev/sdb1
. Check that it contains your data; if not, check whether /dev/sda1
somehow contains an intact filesystem with your data, otherwise I hope you have a backup.
- Make a backup of all your data, if you don't have one already.
- Completely wipe
/dev/sda
: dd if=/dev/zero of=/dev/sda bs=1M
. Then use gdisk
to recreate the partition(s).
- Create a new degraded array using only a partition on
sda
. Make a filesystem in it, and copy your data into it.
- Disassemble the array that's using
sdb1
, and completely wipe /dev/sdb
: dd if=/dev/zero of=/dev/sdb bs=1M
. Then use gdisk
to recreate the partition.
- Add
/dev/sdb1
to the new array and let it sync.
As for installing GRUB, it depends on whether your machine supports EFI (and whether you're using it for booting). If you're using EFI, you need to make an EFI system partition somewhere; it should be roughly 100MB, formatted FAT32. Then you'd install the EFI version of GRUB. I won't go into too much detail on this; EFI booting is a topic for a separate question.
If you're not using EFI to boot, you need to make a "BIOS Boot" partition somewhere on the disk that you'll be installing GRUB on. (This is partition type code ef02
in gdisk
.) The partition can be tiny; 1MB is plenty. GRUB will use this to store the boot code that it would have written to sectors 1 through 62 on an MBR disk. (On an MBR disk, those sectors are typically unallocated since the first partition typically begins at sector 63, but on a GPT disk, the partition table is located in that area.) GRUB should automatically notice that the disk you're installing it to contains a BIOS Boot partition, and put its boot code there instead of in sectors 1-62.
Best Answer
For starters, I'd disconnect the disk with the remaining good mirror of the old "C:" volume and set it aside. If you don't have a backup of that disk I'd make a backup immediately. You don't want to do anything to the remaining copy of the "C:" volume accidentally, so I'd keep it disconnected from the machine until you're absolutely ready for it.
I'd install Windows to the new disk to get the basic partitions recreated. (You could accomplish this other ways but, personally, I'd find it easier to let the Windows installer just do this for me.)
Then I'd boot a Windows setup DVD and use
diskpart
to delete the "C:" volume created during the new Windows installation (SELECT DISK 0
,LIST PARTITION
,DELETE PARTITION x
). I'd convert the new disk to a dynamic disk (SELECT DISK 0
,CONVERT DYNAMIC
).At this point, being done with deleting partitions, I'd be comfortable reattaching the disk with the mirror of the old "C:" volume. I'd boot the Windows setup DVD again and create a mirror of the old "C:" volume using the free space in the new disk as the destination. You'll probably need to
BREAK
the old mirror first. Then you can create a new mirror (SELECT DISK 1
,LIST PARTITION
,SELECT PARTITION x
,ADD DISK=0
).I'd allow the mirror to completely synchronize and then I'd attempt booting.
Obviously, double and triple-check the disk numbers, partition numbers, etc, in the commands before you run them. If you have any doubts install a test machine in a hypervisor and try all of this out "under glass" before you try it on the real hardware.
Oh, and make a backup of the disk with the still-good mirror of the "C:" volume.