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/
_______________________________________________
bblisa mailing list
[email protected]
http://www.bblisa.org/mailman/listinfo/bblisa
