NVMe Replacement: Cloning vs. Backup Restore

I’ve been reading and pondering an interesting and lengthy TenForums thread since it first appeared last Thursday (October 1). It’s entitled Is a NVMe Enclosure Required for Cloning? As I considered the post’s title, my immediate response to its query was another question: “Is cloning required at all?” The OP (original poster) addresses a decision that many users, admins, and repair techs face when planning how to (a) remove a smaller NVMe drive and (b) replace it with a larger one, while leaving the boot/system drive and its contents intact. This turns out to be an interesting decision whichever way one decides to go with this. Let’s discuss!

Understanding Drive Cloning

Drive cloning involves a literal sector-by-sector copy from the source drive to the target drive. When this involves going from a smaller drive to a bigger one, this leaves the overage on the target drive more or less completely alone. Thus, it may be necessary to fiddle around with partition management software (for example, our Admin Toolkit item MiniTool Partition Wizard, aka MTPW) to reclaim unused storage space on the target drive after the cloning is done. And when cloning, it’s essential to replace the old drive with the new one before the next boot-up (and to make sure that the new drive is designated in BIOS/UEFI as the primary boot drive) because part of the cloning process perforce results in the target drive and the source drive sharing an identical disk ID for all partitions. If you leave both drives in place, Windows can’t distinguish one from the other, in fact.

Thus, to keep using the old NVMe alongside a cloned one, you must wipe and reformat the old NVMe. Usually, this means replacing the 4 partitions typical on a Windows 10 system/boot drive, with a single partition typical of a data/storage drive. [Note: the lead-in graphic for this story shows a typical such drive with 4 partitions in this order: 1. FAT32 EFI partition, 2. 16 MB Microsoft Reserved, or MSR, partition, 3. C: partition for OS and related files, 4. Windows Recovery, or WinRE, partition].

In fact, it’s a good idea to wipe and reformat the old drive only after you make sure that the cloned drive is working as it should be (system boots properly, OS runs). If it isn’t , you can still revert back to the old drive while you attempt to figure things out with the new one. I’ve used cloning half a dozen times or more on various PCs. Sometimes that meant using tools like the former Paragon Software Migrate OS tool, and sometimes out-and-out cloning tools like those included in Macrium Reflect or Acronis True Image. I’ve only had things go south on me once, and that was because I forgot to make sure the UEFI was targeting the new, cloned drive at boot-up.

Restoring a Backup to the New NVMe

Another way to proceed with this task of switching from an old NVMe to a new one, is to make an image backup from the old drive, create a bootable set of rescue or restore media, then swap out the drives. You can then boot to the rescue or restore media, and target the new NVMe drive for a restore operation. For most backup programs, this takes care of the duplicate disk ID (duplicate GUID) problem that cloning can cause. It may also be faster than cloning (depending on how smart the cloning software is, it may insist on copying all sectors — even empty ones — from source to target, which makes the operation take longer: sometimes MUCH longer). You may still have to adjust partition sizes when the job is done, though (as when cleaning up after drive cloning). YMMV.

Either method will work as long as you take proper precautions. But heck! I figure that because making an image backup of the old NVMe (boot/system drive that it is) before starting the swap is a commonsense precaution against problems, it’s easier to use that image in a restore to the new drive rather than running a separate disk cloning operation anyway.

And there you have my two cents’ worth on the subject. I hope it delivers the value that is needed to help others puzzle their way through this commonly encountered upgrade scenario. ‘Nuff said!

Author: Ed Tittel

Ed Tittel is a 30-plus-year computer industry veteran. He’s a Princeton and multiple University of Texas graduate who’s worked in IT since 1981 when he started his first programming job. Over the past three decades he’s also worked as a manager, technical evangelist, consultant, trainer, and an expert witness. See his professional bio for all the details.