I took a backup of my server's OS disk through a live USB. Using the command:

dd if=/dev/sda bs=512 count=(30 gb worth of sectors) conv=noerror,sync status=progress | gzip -c > /path/to/removable/media

The command completed with no errors and the image was created. The img.gz is 16 GB

(The server's OS takes up ~15gb of storage) but when I open the .gz in winrar it tells me that the contents are only 2.21 GB and yet the archive is 16 GB.

Does this mean there was an error in the backup process or is it normal for the archive to be larger than the image inside it?


  • This is a bug in winrar. – Ipor Sircer Sep 16 '18 at 23:53
  • So would it be safe for me to assume that I can use this backup in the event of a disk failure? – Scu11y Sep 16 '18 at 23:54
  • Extract it then check with rsync. – Ipor Sircer Sep 17 '18 at 0:02
  • The only backup safe to use useuse one you've successfully tested a restore from. So, try that. Restore somewhere (a VM?) and see if it works. Side note, I wouldn't specify a count if I wanted a full disk. How big is your server's drive? Not space used but full size. – Bob Sep 17 '18 at 0:08
  • @Bob The drive is 500gb and I gave my last spare HDD to a friend so I didn't have anywhere to dump the file that could accommodate a 500gb image. Since the os is only ~15 gb of space, I specified a count that would equal 30gb of sectors just to be safe – Scu11y Sep 17 '18 at 0:10


Firstly, some advice on backups in general: you cannot rely on a backup until you have tested and verified that your restore process works. There are a few methods for testing backups:

  • A full restore to physical hardware, if you have the hardware handy and it's a critical backup.
  • A full restore to a virtual machine, if you're lacking spare hardware.
  • Extracting data and verifying correctness and completeness, if you don't care about restoring a bootable OS.

I generally would not consider checking uncompressed size with WinZip to be particularly useful. However, the results you obtained could indicate that you have supplied an incorrect count , which brings us to...

Issues with your dd command

count=(30 gb worth of sectors)

My first thought on seeing this is that you should never be specifying a count when backing up a drive. If you wanted to back up a specific partition, you should use a partition block device (/dev/sdXN where N is a number). Otherwise, you should just let dd take the whole drive; by specifying a count you risk (in fact, almost guarantee) that you'll be discarding data and possibly corrupting the filesystem.

In a comment, you supplied the reasoning:

The drive is 500gb and I gave my last spare HDD to a friend so I didn't have anywhere to dump the file that could accommodate a 500gb image. Since the os is only ~15 gb of space, I specified a count that would equal 30gb of sectors just to be safe

Unfortunately, that's not how filesystems work. Most filesystems do not guarantee that all data will be stored towards the beginning of the drive.


There's a few other ways to do what you want.

Archiving files/data only

If you only want a data backup and don't care too much about being able to restore a bootable OS, you can back up files only with the tar command. This means you'll still have your data, but you'll have to reinstall an OS from scratch and manually recover the data (and any installed applications).

  1. Copy files to an archive with tar piped to gzip.

Compressed backups with zeroed free space

This is more or less what you have already attempted. You have the right idea with gzip: hopefully it'll compress any unused space (very compressible) to nothing. You just need to drop the count from your command.

Unfortunately, this will not necessarily work out because deleted files may still exist on disk and will not appear as empty to gzip. Therefore, you should clear unused space first. Your backup process becomes:

  1. Clear unused space with zerofree or similar
  2. Copy the drive to a compressed image with dd (without count!) piped through gzip

Use a tool that backs up used blocks only, e.g. partclone

Some tools exist, like partclone, that are smart enough to recognise and only back up used blocks. The Arch wiki has some examples on usage with gzip, and the manual has some examples down the bottom. This effectively replaces dd in your pipeline.

You will need to use the same tool again when restoring data.

  • Thank you. I overlooked this aspect of filesystems completely. I have confirmed that there is a fault in the image as when it is loaded into Virtualbox I get a grub rescue prompt and trying to ls the /boot directory results in a "Read/Write outside of HD0" error. I appreciate your well written response to my question and I'll redo the backup tomorrow after a night of good sleep. – Scu11y Sep 17 '18 at 1:01

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.