A while ago I made a backup of an entire disk using

dd if=/dev/nvme0n1 conv=sync,noerror bs=64K | gzip -c > backup.img.gz

Today I restored this backup to the same disk using

gunzip -c backup.img.gz | dd of=/dev/nvme0n1

dd exited with the following error message:

dd: writing to '/dev/nvme0n1': No space left on device
1000215217+0 records in
1000215216+0 records out
512110190592 bytes (512 GB, 477 GiB) copied, 5769.06 s, 88.8 MB/s

Do I have to assume that the restore process failed? If so, what can I do to restore my disk?

I also have a backup of fdisk -l /dev/nvme0n1, and now after the restore operation, the output of fdisk -l is the same like before, but I don't know if that is any guarantee of success.

  • Sparse files, perhaps? (no, I guess that's not possible with a block device; forget I asked) – Toby Speight Feb 11 '20 at 16:10
  • 1
    What does gzip -l backup.img.gz show as the uncompressed size? – Mark Plotnick Feb 11 '20 at 16:16
  • @MarkPlotnick, it shows 1009123328 as uncompressed and 22275182836 as compressed as well as a ratio of -2107.4% which seem to be wrong informations. – pato Feb 11 '20 at 17:35
  • it's limited to 32bit number. 512110231552 % (2**32) = 1009123328. Even for smaller files you can not entirely trust this value, you have to unpack it and do a bytecount to be sure. – frostschutz Feb 11 '20 at 18:50

It's possible for dd conv=sync,noerror (or dd conv=noerror,sync) to corrupt data in some cases.

However in your case it's probably simply surplus zeroes at the end of file. If your device is not exact multiple of 64K, your dd command would have filled the last 64K block with zeroes in the image file. And those additional zeroes can't be restored. Which would be harmless.

To verify that theory, you could run some commands:

# blockdev --getsize64 /dev/nvme0n1
expected result: 512110190592
# gunzip < backup.img.gz | wc --bytes
expected result: 512110231552 (next multiple of 64K)

If that is correct then you're probably okay here.

  • 2
    conv=sync will pad a short read to a full block. Don't do it when reading from a compressed stream. – roaima Feb 11 '20 at 16:54
  • 1
    Your expected results are the exact numbers I get using the suggested commands. Thanks. – pato Feb 11 '20 at 17:22

I have seen instances in which writing a compressed stream to dd can cause data to get lost. Try this

zcat backup.img.gz >/dev/nvme0n1

Or, if you must use dd, use this pipeline instead

gunzip -c backup.img.gz | dd iflag=fullblock bs=64K of=/dev/nvme0n1

If both of these fail then I would say that your replacement disk is smaller than the original.

  • Thank you, I will keep this commands in mind for future needs! – pato Feb 11 '20 at 17:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.