Replicating partitioning setup on a new SSD

Question

I am trying to clone a failing SSD in my laptop to a new one. Because the current drive is failing, I was unable to use any of the standard Windows cloning software (Macrium, etc.) as they were throwing errors saying certain sectors were unreadable.

My setup is as follows:

• Laptop: Asus Zenbook UX31A
• OS: Windows 8.1
• Current drive: ADATA XM11 256 GB (inside the laptop)
• New Drive: Samsung EVO M.2 850 256 GB (connected through an M.2 -> SATA USB adapter)
• SystemRescueCD booted from a USB drive

I was planning on using GParted to recreate the partition setup on the new drive, and then use ddrescue to clone each partition from the old SSD onto its respective twin on the new drive. Here is the screenshot / description of the GParted view of the old drive:

• partition / name / file system / label / size / flags
• sda1 / EFI system partition / fat32 / SYSTEM / 300 Mb / boot, esp
• sda2 / Basic data partition / ntfs / Recovery / 900 Mb / hidden, diag
• sda3 / Microsoft reserved partition / unknown / Microsoft reserved partition / 128 Mb / msftres
• sda4 / Basic data partition / ntfs / OS / 102.2 GB / msftdata
• sda5 / -- / ntfs / -- / 350 Mb / hidden, diag
• sda6 / Basic data partition / ntfs / Data / 110.62 GB / msftdata
• sda7 / Basic data partition / unknown / Basic data partition / 4 GB / hidden, irst
• sda8 / Basic data partition / ntfs / Restore / 20.01 GB / hidden, diag

I don't have a lot of experience in partitioning, however, and am a bit puzzled by what sda3, sda5, sda7 and sda8 are (especially sda3 and sda7 that has the "irst" flag that I think is the Intel Rapid Start Technology partition)

After some monkeying around with GParted in an effort to recreate the setup of the old drive on the new one, this is as far as I got and how my new drive partitions currently look:

• partition / name / file system / label / size / flags
• sdc1 / Microsoft reserved partition / unknown / Microsoft reserved partition / 128 Mb / msftres
• sdc2 / EFI system partition / fat32 / SYSTEM / 300 Mb / boot, esp
• sdc6 / -- / ntfs / Recovery / 300 Mb / msftdata
• sdc3 / EFI system partition / fat32 / -- / 600 Mb / boot, esp
• sdc4 / Basic data partition / ntfs / -- / 102.2 GB / msftdata
• sdc7 / -- / ntfs / -- / 350 Mb / msftdata
• sdc5 / Data / ntfs / -- / 110.62 GB / msftdata
• unallocated / 18.42 GB

Now, these are not identical. Even though both drives are nominally 256 GB, it appears that my new drive has smaller available capacity than the old one (232.89 GB vs. 238.47 GB, as seen in the screenshots), so I assume I wouldn't be able to replicate the setup fully.

My question is, in order to minimize the disruption and maximize easiness of cloning of the old drive to the new one, how should I partition the new drive? Should I continue to try to replicate all of the partitions on the old one? If so, how do I do that for the "unknown" partitions and the "irst" one? Which partition should I make smaller than its equivalent on the old drive, since my new drive has less space?

Any and all help would me much appreciated.

Answer 1

If your drive is failing any data on those failing parts my be lost. If you want an exact clone of the disk I would try to use CloneZilla

CloneZilla

You can create a bootable USB and then do a clone of the disk using a filesystem independent copy. The choice in clonezilla is -q1 Priotirty: only dd. You'll see it in the menu, but you'll have to go into Expert Mode.

I've used CloneZilla to image Macs with Bootcamp installed and it made an extact replication of the partitions on the destination hard drives.

Answer 2

My first recommendation is that you consider returning the disk you bought in favor of one that's a little bit bigger. That will simplify the cloning process. OTOH, that may not be worth the hassle, particularly if it will take you much time -- as your current disk is failing, a delay could mean more lost data.

My second recommendation is that you verify that your USB adapter is not changing the logical sector size of the disk. Some do that, and if yours does, you'll end up with a disk that's unusable when you plug it in directly. Type sudo parted /dev/sda print | grep logical to see the logical and physical sector sizes of /dev/sda. Check the source and target disks. If they aren't identical, you can check the target disk again after you connect it directly to the computer (even if you must swap out something else to do so). If the logical sector size changes depending on how it's connected, it's IMPERATIVE that you fix that problem before you proceed. (You'd fix it by using a different USB adapter or by plugging the target disk into a free SATA port, not via a USB adapter.) Note that I have no specific reason to think this is a problem for you, but it is often a problem when moving between direct connections and connections via USB adapters, so it's something you should check.

My third recommendation is that you pay attention to disk and partition GUIDs. By cloning the disk as you are, your GUIDs will change, which means that your EFI boot entries will be rendered invalid after you clone the disk. You can adjust the partition GUIDs with gdisk on a partition-by-partition basis. An easier option may be to use gdisk's partition table cloning feature. This is available from the experts' menu (type x in the main menu) as u. The trouble with this feature is that it will not work when the partitions are too big for the target disk. Thus, you'd need to resize or delete your last partition, at least in memory, to clone the partitions. That brings me to the next point....

Your final partition seems to be a system restore partition. Given your slightly-too-small destination disk, you'll need to deal with this partition in one way or another. Some options that spring to mind are:

• You may be able to use a utility in Windows to move the restore partition to a USB flash drive (it'd need to be at least 12 GiB). You could then omit the restore partition from the cloning operation.
• It looks like there's free space on the restore partition, so you might be able to shrink it by about 7 GiB to make it small enough for everything to fit on the new disk. Windows can be finicky about boot partitions, though, so trying to shrink it runs the risk that it would stop working. Also, resizing a partition is especially risky if your disk is malfunctioning, as yours is, so you could end up trashing it if you try this.
• You could try replicating everything except that last partition and then try replicating it in some other way -- maybe a Windows backup tool that permits copying a bootable installation to a smaller partition.
• You could replicate everything but the last partition, then shrink the new sixth partition by a bit, move the seventh partition (with an "unknown" filesystem), and replicate the restore partition in the now-big-enough free space.
• It's possible that your current /dev/sda7 is useless. If you can verify this, you could omit it from the copy. That wouldn't clear up quite enough space to make room for the restore partition, but it would be close, so you'd need to resize the preceding or following partition by less.

One final point: Since this is an SSD, doing a dd copy (or ddrescue) will cause the target SSD to register every sector as being in use. This will degrade performance. Thus, you should look into TRIM utilities that will tell the SSD that unused sectors are actually unused. I'd run such tools after replicating each partition, if possible. Alternatively, or in addition to this, you could use CloneZilla, ntfsclone, or other tools that will not copy unused sectors whenever possible, and use ddrescue only on partitions that give read errors.