[BBLISA] dump instead of dd for imaging?

[Tom Metro]

Eddy Harvey wrote:
> ...when you restore a dd image, it has to go onto the same size hard
> drive as the original...

The target drive or partition can be larger.


> ...and dd has to write the whole disk again.

Unless you backup and restore partitions.

As I mentioned in Scott's thread on the BLU list, you can create a 
simple script to to use dd to backup each partition, dd to copy the MBR, 
and sfdisk to save the partition table. (See 
http://mlf.linux.rulez.org/mlf/ezaz/ntfsresize.html#cli )


> It's recommended to shutdown or mount read-only before beginning the
> dump.

Or boot from a live CD.


> Since the dump/restore programs on the bootable CD are in fact slightly
> different from the ones included with your OS, there are in fact library
> compatibility problems.
...
> Before you install your OS, install the minimal version of your OS.
> That is, create a 2G partition on the drive, and install the OS into
> that.

Again, using a live CD should avoid these problems.

(I have used the mini OS install trick before, but only as a method of 
repairing systems running proprietary file systems (NTFS). These days, 
even those systems have versions of the OS that can boot from CD.)


> Also, [with dd] every byte of the disk will be read during backup,
> while every byte will be written during restore.  This makes the 
> backups easy, but large & slow & inflexible for size.

Imaging drives is a blunt instrument, and restoring from an image file 
should only happen in the event of a disaster, so if it's a bit slow, 
that shouldn't be a problem. (Unless you're cloning a configuration to 
multiple systems.)

A good backup strategy should pair infrequent drive imaging with 
frequent incremental backups of the user generated data.


> While your OS is running, you do this:
> 	dd if=/dev/zero of=zero.fill bs=1024k ; rm zero.fill
> This will fill all unused disk space with
> nfinitely-compressible-zeroes, and then immediately release that disk
> space. ...you end up with the smallest backup filesize...

A little inconvenient (it slows down the overall process), but a good tip.

In theory, one could create a custom Linux boot CD that automated the 
whole process - from zero filling the disks, to mounting a network share 
to store the image and a log of the process, to finally shutting down 
the workstation when done. You could have employees pop the CD into a 
machine and reboot it just as they lave work.

  -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/