[Discuss] How do you backup "/" with rsync?

[Alan W. Irwin]

On 2007-11-10 00:51-0800 Alan W. Irwin wrote:

> Ultimately, I would like to be able to boot off the external drive in case
> there is some emergency for my internal drive.  Thus, earlier this evening I
> fired up the external drive, did all the fdisk, pvcreate, vgcreate,
> lvcreate, and mke2fs commands to logically partition it and create
> filesystems on it that are of identical pattern with my internal drive. I
> then proceeded to use rsync to backup some of the internal drive's
> partitions with what appears to be good results for /boot, /home, and
> /backup (where I keep my dump backups).  (At least a repeat rsync for all of
> these partitions/filesystems found no differences other than from expected
> updates to the filesystems.)
>
> [...]Once I proved to my satisfaction that rsync to the external drive was
> working fine, I then wanted to do one overall backup of "/", but I don't
> know how to specify the correct exclude option. Could someone help with
> that please?

Today, I finally had a chance to get back to this problem and found the
following cookbook works well.

1) Turn on external drive:

2) reinitialize lvm taking account of the volume group on the external drive

/etc/init.d/lvm2 start

This is equivalent to

/sbin/vgscan --ignorelockingfailure --mknodes || true
/sbin/vgchange -a y --ignorelockingfailure

3) Make sure /etc/fstab is organized properly.  In my case the relevant
lines are

/dev/mapper/raven-root   /       ext3 errors=remount-ro 0 1
/dev/sda1                /boot   ext3 defaults          0 2
/dev/mapper/raven-home   /home   ext3 defaults          0 2
/dev/mapper/raven-backup /backup ext3 defaults          0 2
/dev/mapper/raven-swap_1 none    swap sw                0 0
/dev/mapper/raven_backup-root   /external_backup_root        ext3 rw,noauto 0 0
/dev/sdb1                       /external_backup_root/boot   ext3 rw,noauto 0 0
/dev/mapper/raven_backup-home   /external_backup_root/home   ext3 rw,noauto 0 0
/dev/mapper/raven_backup-backup /external_backup_root/backup ext3 rw,noauto 0 0

I have a /boot filesystem outside of lvm control and a root, home, and
backup filesystem under lvm control, with exactly the same arrangement on
the external drive.  The noauto option makes sure the external filesystem is
not automatically mounted on boot (since the external drive will normally be
turned off), and the last 0 number means no filesystem check will be done at
boot time (again because the external drive will normally be turned off).

4) Mount filesystems on external drive

mount /external_backup_root
# first time: create some mount points and some directories that the "mount"
# command mentions that are specifically excluded below.
cd /external_backup_root
mkdir boot home backup tmp proc sys dev lib/init/rw
# end of first time.
mount /external_backup_root/boot
mount /external_backup_root/home
mount /external_backup_root/backup

5) Partial mirror of the internal disk on the external disk.
rsync -av --delete \
--filter='- /external_backup_root/' \
--filter='- /proc/' \
--filter='- /sys/' \
--filter='- /dev/' \
--filter='- /tmp/' \
--filter='- /lib/init/rw' \
/ /external_backup_root \
2>&1 > 20071209_root

20071209_root (and also the corresponding --dry-run result initially) showed
no problems.

The filtering options exclude external_backup_root for obvious reasons, some
dynamically generated filesystems, and also /tmp (which is emptied for
reboots in any case).  I assumed that the dynamically generated filesystems
would not be required for booting from the external drive, but note I
did create mountpoints above for those dynamically generated filesystems
although I am not sure that is necessary.

6) Put a stanza in /boot/grub/menu.lst corresponding to the external disk.

In my case, that stanza was a copy of the usual stanza I use to boot, but
with some changes from (hd0,0) (corresponding to /dev/sda1) to (hd1,0)
(corresponding to /dev/sdb1) and from volume group raven to raven_backup

Original stanza:

title           Debian GNU/Linux, kernel 2.6.22-3-amd64
root            (hd0,0)
kernel          /vmlinuz-2.6.22-3-amd64 root=/dev/mapper/raven-root ro quiet 
initrd          /initrd.img-2.6.22-3-amd64
savedefault

Added stanza:

title           WATCHOUT! EXTERNAL DISK Debian GNU/Linux, kernel 2.6.22-3-amd64
root            (hd1,0)
kernel          /vmlinuz-2.6.22-3-amd64 root=/dev/mapper/raven_backup-root ro quiet 
initrd          /initrd.img-2.6.22-3-amd64
savedefault

7) edit /external_backup_root to swap raven for raven_backup everywhere
and also swap sda for sdb everywhere.

8) Use grub to update the MBR of the external drive.  (I haven't done that
yet because I am still figuring out the necessary grub command-line syntax.)

9) unmount filesystems on external drive.  Order is important

umount /external_backup_root/boot
umount /external_backup_root/home
umount /external_backup_root/backup
umount /external_backup_root

10) Optionally power down external drive.

End of cookbook.

The result of this cookbook is I am able to boot off of the external drive
by picking the appropriate stanza from the grub menu (currently obtained
from /boot/grub/menu.lst pointed to by the MBR of /dev/sda, see point 8
above). Once I have the MBR stuff straightened out, this external drive
should provide an ideal way to continue work for the case when the internal
drive fails and there is some delay in getting a replacement.

I should also say that because of the tremendous speed of the internal and
external SATA drives, rsync powers through the 60GB of OS + dump/restore
backups in /backup + personal files in /home in just a few minutes when
there are just a few files that have been changed.  So to my mind an
external SATA drive is the ideal backup system for an internal SATA drive
since you get tremendous speed, reliability, capacity, AND bootability for a
price tag of only $200. The only reason I am continuing with a parallel
dump/restore backup at the moment is (a) I am used to it, and (b) you get
efficient snapshots both in terms of the time required to create them and
the disk-space consumed by them. However, apparently there is a way to get
efficient snapshots with rsync as well (using the --link-dest option) so
once I have that figured out, I plan to drop dump/restore altogether.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________