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

[Alan W. Irwin]

On 2007-12-11 11:31-0800 Steven Kurylo wrote:

>> irwin at raven> ls -l /dev/disk/by-id/
>> total 0
>> lrwxrwxrwx 1 root root  9 2007-12-09 21:21 ata-ST3500630AS-9QG3XJPX-part1 ->
>> ../../sdb1
>
> You can just use /dev/disk/by-id/ata-ST3500630AS-9QG3XJPX-part1 in
> your fstab, instead of /dev/sdb1.  udev guaranties this id to be
> unique.  http://www.reactivated.net/writing_udev_rules.html#builtin
[...]
> You use udevinfo to find out what information is available to udev
> when identifying drives:
> http://www.reactivated.net/writing_udev_rules.html#udevinfo

Thanks for the links to various parts of
http://www.reactivated.net/writing_udev_rules.html.  That's a useful
resource.

My previous results were somewhat obfuscated by non-persistent id's.  For
example, the above ls result pointed to ../../sdb1, and "vgdisplay
--verbose" indicated only the raven volume group was defined and associated
with the /dev/sdb1 physical volume.  In contrast, the "mount" command output
said the /boot partition was actually on sda1.  I believe this inconsistency
resulted from booting with the external drive on.  I think for that
situation /dev/sda was associated with the external drive and /dev/sdb
associated with the internal drive.  (IOW, the jmicron eSATA controller was
being loaded and used before the ICH9 SATA controller.) Currently the
external drive has no MBR so I have no idea how it found the correct grub
menu.  However, that boot with external drive on did work.

Currently, I am not using a non-persistent drive identity for /boot in
/etc/fstab which reads

/dev/sda1       /boot           ext3    defaults        0       2

Thus, with the external disk turne on for booting, it must have mounted that
filesystem for the external drive.  After I turned off the external drive I
never attempted to look at /boot, but if I had I presume I would have gotten
i/o errors.

I wanted to reboot in any case because of the /dev/sd[ab] confusion so this
time I made sure the external drive was off, and only turned it on once the
system was up and then executed "/etc/init.d/lvm2 start".  For that case, I
now get reasonable looking results for /dev/disk/by-id/

irwin at raven> ls -l /dev/disk/by-id
total 0
lrwxrwxrwx 1 root root  9 2007-12-11 17:45 ata-ST3500630AS-6QG16YA9 ->
../../sdb
lrwxrwxrwx 1 root root 10 2007-12-11 17:45 ata-ST3500630AS-6QG16YA9-part1 ->
../../sdb1
lrwxrwxrwx 1 root root 10 2007-12-11 17:45 ata-ST3500630AS-6QG16YA9-part2 ->
../../sdb2
lrwxrwxrwx 1 root root 10 2007-12-11 17:45 ata-ST3500630AS-6QG16YA9-part5 ->
../../sdb5
lrwxrwxrwx 1 root root  9 2007-12-11 17:33 ata-ST3500630AS-9QG3XJPX ->
../../sda
lrwxrwxrwx 1 root root 10 2007-12-11 17:33 ata-ST3500630AS-9QG3XJPX-part1 ->
../../sda1
lrwxrwxrwx 1 root root 10 2007-12-11 17:33 ata-ST3500630AS-9QG3XJPX-part2 ->
../../sda2
lrwxrwxrwx 1 root root 10 2007-12-11 17:33 ata-ST3500630AS-9QG3XJPX-part5 ->
../../sda5
lrwxrwxrwx 1 root root  9 2007-12-11 17:45 scsi-S_6QG16YA9 -> ../../sdb
lrwxrwxrwx 1 root root 10 2007-12-11 17:45 scsi-S_6QG16YA9-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 2007-12-11 17:45 scsi-S_6QG16YA9-part2 -> ../../sdb2
lrwxrwxrwx 1 root root 10 2007-12-11 17:45 scsi-S_6QG16YA9-part5 -> ../../sdb5
lrwxrwxrwx 1 root root  9 2007-12-11 17:33 scsi-S_9QG3XJPX -> ../../sda
lrwxrwxrwx 1 root root 10 2007-12-11 17:33 scsi-S_9QG3XJPX-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 2007-12-11 17:33 scsi-S_9QG3XJPX-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 2007-12-11 17:33 scsi-S_9QG3XJPX-part5 -> ../../sda5

If I use vgdisplay --verbose to find the physical volumes assocated with
my raven and raven_backup, the former is /dev/sda5 while the latter
is /dev/sdb5 as expected.

Now if I turn off the external drive (note, I did not mount any filesystems
on that drive for this session) and re-run /etc/init/lvm2, all continues to
be well.  The raven_backup volume group is gone, and the raven volume group
is associated with /dev/sda5.  All the /dev/sdb devices are gone, but the
/dev/sda devices are still there.  mounted (as expected, but I believe this
was wrong in the previous case since /dev/sda1 did not exist), and "ls -l
/dev/disk/by-id" continues to show all the ../../sda* results but the
corresponding ../../sdb* results are dropped as expected. Finally, "mount"
says /boot is mounted on /dev/sda1 (as expected, and also correct this time
since sda is associated with the internal drive because the boot occurred
without the external drive turned on).

I have just replaced /dev/sda1 and /dev/sdb1 by the appropriate persistent
id's in /etc/fstab (the /dev/mapper/ ones seem to be persistent from the
above inadvertent experiments so I will leave those as is).  As a result of
this change, it should no longer matter whether the external drive is off or
on when I boot.

Thanks, Steven, for helping me understand the importance of persistent disk
id's, and thanks again for pointing me to the above udev rule reference.

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
__________________________