Re: Clone root partition

T wrote:
Hi,

I'm trying to compile a comprehensive document on cloning root partitions.
My immediate goal is to clone my current working Linux to external USB HD,
so that I can use it wherever I go.

By comprehensive I mean it should not be as simple minded as

dd if=/dev/hda2 of=/dev/sda2

or

cp -a / /mnt/point

See my comment below.


or

tar -p -m cf - / | (cd /mnt/point; tar xf - )

I know they work, but there are so many things have been left out. By
comprehensive, I mean I want to know all relevant things that need to be
considered.

For example for dd, let alone its rigid limitation, if you use it, at least
the 'conv=sync,noerror bs=4k' options should be used: sync,noerror just
means continue and zero fill any error blocks, bs=4k just writes 4k at a
time which will speed things up a lot. For cp, at least 'cp -ax' should be
used.

I've never used option flags for this purpose, and I'm not sure what the -ax options could mean in this context, since copying from device to device ignores not only the filesystem but partition data as well. Used in this way, cp streams data in byte order from device to device, copying partition tables, boot loaders and filesystem indexing tables as well as the filesystems, regardless of the target device geometry. Since I am unsure of the implications of this, I use this method only between identical devices, and only when there are no bad blocks on either device. In practice this means that I only rarely use this approach, but I have been considering it for cloning backuppc archives.

But there are still much more to it.

First, directories that don't need to copy over, like /tmp, /proc. With
modern Linux that uses udev, the /dev and /sys don't need to be copied
either. Anything else (besides distro specifics like /var/cache/apt/archives)?

2nd, the clone partition should be made bootable, by grub or lilo.

Anything else? Like the concerns of /etc/fstab...

Last, with all the above concerns, how to achieve them with various tools?

Keywords: tar rsync find cpio dd

thanks

PS. If you come across this message late, be it a week or even a month
late, please do comment, I hope this thread can be a one stop place for
people looking for concerns over cloning root partitions.

You don't mention rsync, which is currently my preferred method. It's simpler to use than tar, provides the option of incremental updates, and unlike cp -a it works around linux' lack of an "lutimes" system call, taking care of time stamps of symbolic links. For cloning root filesystem drives I use a small script that performs an rsync backup followed up by fixups to the /dev directory, /etc/fstab, and /etc/lilo.conf and then runs lilo -r to make the backup bootable. (A similar approach could be used for grub.) The script runs in a few minutes if I disable rsync checksumming.

Here is the entire script, which uses /dev/hda1 as my backup root drive:

mount /dev/hda1 /mnt/hda1
time rsync -vxaHD --delete / /mnt/hda1/
rsync -xaHD --delete /dev/ /mnt/hda1/dev/
cp -a /etc/fstab.hda1 /mnt/hda1/etc/fstab
cp -a /etc/lilo.conf.hda1 /mnt/hda1/etc/lilo.conf
rm -rf /mnt/hda1/dev/.udevdb
lilo -r /mnt/hda1
umount /dev/hda1

This script presumes that udev is installed. For it to work, I have to manually maintain /etc/fstab.hda1 and /etc/lilo.conf.hda1.

Disclaimer for newbies: please do not use this script unless you completely understand how it works, and are not using /dev/hda1 as your root filesytem!

The backup drive can be selected through the BIOS boot menu if the main root drive craps out. The only complication is that one my applications (mythtv) uses mysql to keep track of files on an non-root filesystem, which creates the possibility that the database could be out of sync with the mythtv data files in the event of a main filesystem crash.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@xxxxxxxxxxxxxxxx with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx