I recently replaced my old 640GB Western Digital Caviar Blue hard drive with a brand-spanking-new 3TB Toshiba P300. The 7-year-old WD contained my Windows data partition for documents/media/games/etc and had served me admirably throughout the years, in several different desktop PCs running Windows Vista all the way to my Windows 10 system; however, it was getting old, and more importantly, full. So I fired up SystemRescueCd -my partitioning and recovery distro of choice now that Parted Magic has become a lame paid product - and got to work.
The first order of business was to start GParted and initialize the new Toshiba drive with a new GPT partition table. Next, I created a single raw/unformatted partitioning spanning the whole disk. With the old NTFS partition on /dev/sda1 and the new partition on /dev/sdb1, I then used ntfsclone to clone the partition to the new disk:
ntfsclone --overwrite /dev/sdb1 /dev/sda1
After ~2 hours the clone finished. After resizing it to take up the entire partition with GParted, I went to boot Windows again - however, the cloned NTFS partition was not detected. Disk Management didn't even recognize it as a valid NTFS partition. How could this be?
It turns out that gparted sets the partition type (GUID) of new GPT data partitions to
0FC63DAF-8483-4772-8E79-3D69D8477DE4, i.e. "Linux filesystem data". Run
sfdisk -l /dev/sdX to see the type of each partition on a disk. However, since this partition is intended to be used by Windows systems, we need to change the partition GUID to
EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, i.e. "Microsoft basic data partition". This can be easily accomplished with sfdisk by passing the device, partition number, and desired GUID to the
--part-type option as follows:
sfdisk --part-type /dev/sdb 1 EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
Once that's done, reboot into Windows, and your data partition should appear again, safe and sound.