Trouble backing-up with "dd"
 

Hi guys,

I've been running a few comparitive backup tests on my Acer Aspire One netbook between Acronis, Clonezilla and the good ol' "dd" command. Clonezilla came out tops (after I disabled a couple of really DUMB default options that were causing it to fail.) Then Acronis (effective back-up in less than 5 minutes; restore in 32m). Lastly and leastly, "dd" which was *awful*.

Bear in mind this computer's main partition is a tiny 7Gb. dd took 107 minutes to back this up, and a whole THREE HOURS to restore it! Unbelievably slow as I'm sure you'll agree. Plus when the restore finished and I re-booted, the computer reported it had zero free disk space. And I mean ZERO. The command I used (from an external usb Knoppix live CD) was "sudo dd if=/dev/sda5 of=/dev/hdc1" and the backup partition size was 8Gb. I've never had a bum result with "dd" before, so where did it all go wrong?
TIA,

CC.

Keep in mind that dd is REALLY DUMB---it happily copies all the bytes including the empty space.

Also, the speed of dd will depend on the choice of block size. The optimum depends--in turn--on the size of your RAM.

Gosh, that was a swift reply! I was wondering about specifying a block size but didn't and just entered the command without one as shown. Still can't understand why it's filled the disk up, either. :-/

Did you say you copied an 8Gb partition to a 7Gb one? That'll be why.

These are good instructions for backing up partitions with dd. You're better off writing the image to a file rather than directly cloning one partition onto another. I think my 20Gb partition takes about 20-30min to back up and 10 min to restore with those instructions (block size 1k - maybe I can increase this but I'm not sure)

Well this is something I don't quite understand. I'm aware that when you use 'dd' you need to be sure that the volume you're writing to is equal to or greater in size than the one you're copying. That's what I did: source partition=7Gb; destination partition=8Gb. However, when restoring the sizes are reversed, I guess. How can one get around this? Is it essential, then with 'dd' the source and destination partitions be of exactly EQUAL size rather than equal or greater?

Well thinking about it, I might be wrong. The filesystem on your system partition is only 7Gb, and cloning it onto a larger partition shouldn't change that - if you mount the backup partition, you should see only 7Gb total space, I think. But still I think this must have something to do with it. Definitely recommend using a gzipped image file if you just want the copy for backup! bzip gives somewhat better compression but is way too slow for this IMO.

using dd:
if you restore a 10 gb backup to a 5 gb hard drive, the backup will truncate. so any data beyond the 5 gb barrier will be non-existant on the restored hard drive.

if you restore a 5 gb backup to a 10 gb hard drive then the restored harddrive will look like a 5 gb harddrive (essentially half the harddrive will be unusable space).