Backing up a Windows system using DD from NVME 512 GB to SSD 500 GB

Question

I used to have two identical 500 GB SSD drives: one inside a laptop, one outside. I would make regular backups using dd from the internal HDD to the external one, as their capacity matched.

I now have a new laptop, which has an NVME drive with (drum roll) 512GB. I am slightly worried about this cosmetic capacity increase crippling my ability to use my perfectly good 500GB SSDs for backups.

I have checked, and dd doesn't seem to care much if it runs out of space in the target file at some point in the copy process - it just stops.

To ensure that I don't end up losing data from the OS drive, I have re-partitioned it to only use 500GB (to match the size of my external drives), leaving 12 GB of unpartitioned space on the NVME.

Question: Will there be any low-level UEFI confusion happening when trying to boot a Windows 10 system image restored to a 512GB NVME from the smaller 500GB SSD drive using dd, if I partition the aforementioned system image to only use 500GB of space on the NVME?

---

EDIT: Following the advice I have been given, I have reduced my partitions on the source disk (512 GB NVME) to be around 499 GB in total, allowing some space for the partition table. Then I have performed a dd backup to an SSD:

dd if=/dev/nvme of=/dev/sda ibs=8192 obs=8912 status=progress

Once completed, gdisk has complained about finding 5 problems. I have issued a gdisk e command (load main partition table from disk (rebuilding backup)) and then w (write table to disk and exit)

After this the disk would pass verification (v) but I could no longer boot Windows from it. How can I troubleshoot this further and figure out what has gone wrong? I will try to compare gdisk p output for the source NVME drive and the resulting clone SSD to get some clues.

---

EDIT 2:

Here is comparison of the two partition tables (they match):

Disk /dev/nvme0n1: 477 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: PC401 NVMe SK hynix 512GB               
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 4610F6E8-FE3A-4E46-AD07-2CA1F0EE3F0A

Device             Start       End   Sectors   Size Type
/dev/nvme0n1p1      2048   1023999   1021952   499M Windows recovery environment
/dev/nvme0n1p2   1024000   1228799    204800   100M EFI System
/dev/nvme0n1p3   1228800   1261567     32768    16M Microsoft reserved
/dev/nvme0n1p4   1261568 356517887 355256320 169.4G Microsoft basic data
/dev/nvme0n1p5 356517888 972947455 616429568   294G Microsoft basic data
/dev/nvme0n1p6 972949504 975046655   2097152     1G Microsoft basic data


Disk /dev/sdb: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Disk model: SSD 750 EVO 500G
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 33553920 bytes
Disklabel type: gpt
Disk identifier: 4610F6E8-FE3A-4E46-AD07-2CA1F0EE3F0A

Device         Start       End   Sectors   Size Type
/dev/sdb1       2048   1023999   1021952   499M Windows recovery environment
/dev/sdb2    1024000   1228799    204800   100M EFI System
/dev/sdb3    1228800   1261567     32768    16M Microsoft reserved
/dev/sdb4    1261568 356517887 355256320 169.4G Microsoft basic data
/dev/sdb5  356517888 972947455 616429568   294G Microsoft basic data
/dev/sdb6  972949504 975046655   2097152     1G Microsoft basic data

However, I am unable to boot from the external drive. When launching gdisk on the healthy bootable source disk I get:

The protective MBR's 0xEE partition is oversized! Auto-repairing.

I don't get this message when running gdisk on the clone. Could it be that in reading the partition table incorrectly gdisk is somehow corrupting it?

Could it be the use of Bitlocker that is making the GPT table 'odd'? I had no issues with Truecrypt previously..

---

EDIT 3:

I am typing this from an OS running on a successfully cloned drive! The recommendation from the accepted answer has worked. To summarise:

• Reduce the used space on the 512 GB source media, by shrinking the last partition by a bit more than 12 GB (to allow for the partition table copy to reside at the end of the disk)
• Perform a dd clone from 512 GB source media to the smaller 500 GB disk.
• Run fdisk (i.e. fdisk /dev/sdb) and select w option to rebuild the backup header (fdisk will offer this action to be performed by default whe changes are written to disk)

After these manipulations I have been able to successfully use the drive.

Answer 1

Partition size vs disk size

You should make the partition slightly smaller than 500 GB, just like it was slightly smaller than 512 GB originally. I would shrink it to ~495 GB just to keep a safe buffer.

(Reason: Partitions don't occupy 100.000% of the entire disk – they need to leave a few kilobytes (a few sectors) for the partition table itself. So if your disk is exactly 500 GB, it can't actually fit a 500 GB partition – it's more like ~499.999 GB.)

Secondary partition table

Other than that, the truncated image should boot and work just fine, but the OS might complain about the "backup" GPT partition table being missing, as it was located at the last sector of the disk and you chopped it off. (The primary partition table starts at sector 1 for GPT and will survive the clone, as will the protective MBR in sector 0.)

After restoring, let a partitioning tool update the GPT somehow (e.g. run gdisk or fdisk on Linux and just ask it to write the table) so that the backup GPT will be recreated.

"Usable LBA" range

The GPT also specifies the range of "usable" sectors, which is usually set to the whole disk (minus the areas used by partitioning). When imaging to a larger disk, that range doesn't magically auto-update; again a partitioning tool needs to write the new values.

This won't be a problem for normal use, as the OS won't try to write any data outside partition boundaries anyway. However, some partitioning tools use only the GPT-specified range ignoring the actual disk size; e.g. when imaging a 128GB disk to a 512GB one, those tools might refuse to put any partitions beyond the original 128GB size. However, it is usually enough to use a different partitioning tool (e.g. Linux gdisk will usually fix the mess).

Finally, if the original source and the final destination are the exact same 512GB, you don't need to fix it twice – the sector range will end up being correct again in the end anyway.

---

$ fallocate --length=10G test.img

$ fdisk test.img
...
Created a new GPT disklabel (GUID: F3936D7A-D5D9-ED43-950F-5CF3B37E0FAA).
Created a new partition 1 of type 'Linux filesystem' and of size 8 GiB.
...

$ truncate --size=9G test.img

$ fdisk test.img
...
GPT PMBR size mismatch (20971519 != 18874367) will be corrected by write.
...

$ gdisk test.img
GPT fdisk (gdisk) version 1.0.4

Warning! Disk size is smaller than the main header indicates! Loading
secondary header from the last sector of the disk! You should use 'v' to
verify disk integrity, and perhaps options on the experts' menu to repair
the disk.
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.

Warning! Error 25 reading partition table for CRC check!
Warning! One or more CRCs don't match. You should repair the disk!
Main header: OK
Backup header: ERROR
Main partition table: OK
Backup partition table: ERROR
...

However, I am unable to boot from the external drive

You've moved from a NVMe disk to either a SATA/AHCI disk or even to USB Storage; it's probable that the system just doesn't have USB drivers active at that point. (This is similar to the frequent "I switched from IDE to AHCI mode" problem; the new drivers have to be enabled manually beforehand.)

So if the disk is connected via SATA to an AHCI controller, use sc qc storahci to make sure the driver is set to BOOT_START, likewise for iaStorA. I'm not sure which driver is needed for USB Mass Storage.

In any case, the system should boot again once it's been written to another NVMe disk.

Here is comparison of the two partition tables (they match):

They do (because you cloned the actual bytes), but just for the record, there's a bit more data in the GPT that isn't shown in normal mode. For example, partition GUIDs and flags are only visible in "expert" mode, and the UEFI boot menu uses partition GUIDs to match the boot partition.

The protective MBR's 0xEE partition is oversized! Auto-repairing.

The protective MBR isn't involved in the boot process; it's a dummy partition table that only has a single massive partition covering the whole disk. (It protects the disk from being corrupted by old MBR-only partitioning tools.) Systems which understand the GPT will usually just ignore the protective MBR.