Copying GPT SSDs

30Dec15

TL;DR

Copying the contents of one SSD to a larger one (and making use of the extra space) should be simple, but there are a few gotchas. A combination of AOMEI Partition Assistant Standard and some command line tools got the job done though.

Background

SSDs have been reasonably cheap for some time, but now they’re really cheap. In the run up to Christmas I got a Sandisk Ultra II 960GB SSD for less than £150 (and right after Christmas they were on sale at Amazon for even less, so I got a couple for the in laws).

Copying rig

I used one of my old NL40 HP Microservers running Windows 7 to do the copying as it’s easy to get disks in and out of it. To put 2.5″ drives into the 3.5″ bays I got a couple of Icydock adaptors, and to get mSATA drives in place I used an existing mSATA to 2.5″ adaptor, and bought a new one[1], which is uncased – but fine for the job.



Right tool for the job

That new SSD became the base of the pyramid for a drive shuffle that rippled through a bunch of my PCs. For the older systems I could have easily used my trusty old version 11 copy of Paragon Partition Manager[2], but for the newer systems using GUID partition tables (GPT) I needed something else. I found AOMEI Partition Assistant Standard did the job (mostly).

Almost there

AOMEI works pretty much the same as the Paragon Partition Manager I was used to, though if anything the copy disk function was easier to use (and offered a means to resize the main partition as part of the operation, which was the whole point of the exercise). The problem that I found with AOMEI is that it didn’t copy over the partition types and attributes, meaning that I had to fix things up with the DISKPART utility.

Fixing type and attributes

I launched two CMD windows using ‘Run As Administrator’, and then compared the source disk (e.g. disk 1) with the destination dist (e.g. disk 2) e.g. this is what I see on the source disk:


DISKPART> select disk 1

Disk 1 is now the selected disk.

DISKPART> list partition

Partition ### Type Size Offset
------------- ---------------- ------- -------
Partition 1 Recovery 300 MB 1024 KB
Partition 2 System 99 MB 301 MB
Partition 3 Reserved 128 MB 400 MB
Partition 4 Primary 930 GB 528 MB

DISKPART> select partition 1

Partition 1 is now the selected partition.

DISKPART> detail partition

Partition 1
Type : de94bba4-06d1-4d40-a16a-bfd50179d6ac
Hidden : Yes
Required: Yes
Attrib : 0X8000000000000001
Offset in Bytes: 1048576

Volume ### Ltr Label Fs Type Size Status Info
---------- --- ----------- ----- ---------- ------- --------- --------
* Volume 3 Recovery NTFS Partition 300 MB Healthy Hidden

DISKPART>

To make the partition on the target disk have the same attributes (in my second CMD window running DISKPART):


DISKPART> select disk 2

Disk 2 is now the selected disk.

DISKPART> select partition 1

Partition 1 is now the selected partition.

DISKPART> gpt attributes=0X8000000000000001

DiskPart successfully assigned the attributes to the selected GPT partition.

DISKPART> set id=de94bba4-06d1-4d40-a16a-bfd50179d6ac

DiskPart successfully set the partition ID.

DISKPART>

and then work through the other partitions ensuring that the type and attributes are set accordingly.

Fixing boot

Even after all of that I ended up with disks that wouldn’t boot. In each case I needed to boot from a Windows install USB (for the correct version of Windows[3]) and run the following on the repair command line (automatic repair never worked):


bootrec /fixmbr
bootrec /fixboot
bootrec /rebuildbcd

Notes

[1] I knew I’d be copying from mSATA to mSATA at various stages, which is why I needed two adaptors. I could have introduced an intermediate drive, but that would have just added time and risk, which wasn’t worth it for the sake of a less than £10.
[2] A little while ago I gave version 12 a try, but it seemed to be lacking all of the features I found useful in version 11.
[3] My father in law’s recent upgrade to Windows 10 (when I thought he was still on 8.1) caused a small degree of anxiety when the /scanos and /rebuildbcd commands kept returning “Total identified Windows installations: 0”



3 Responses to “Copying GPT SSDs”

  1. 1 Andrew Hardie

    Wot! No Clonezilla…?

  2. 3 John O'Hara

    Very nice! Over Christmas I popped a 512GB PCI-E SSD in my aging X58 machine. Its SATA2 subsystem wasn’t up to the 105,000 IOPS of goodness that Plextor had arranged to be boot compatible with my antique mobo! Windows 10 replaces Window 7 after 5 years and looks just the same. Beware NTFS ACLS and CHKDSK… much pain.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: