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
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 (
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).
- Copy files to an archive with
tar piped to
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:
- Clear unused space with
zerofree or similar
- Copy the drive to a compressed image with
count!) piped through
Use a tool that backs up used blocks only, e.g.
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.