Note I'm cc'ing Glenn, since Nixnet is doing it to me again.
Glenn Eychaner wrote:
I manage a set of CentOS operations workstations which are all clones of each other (3 "live" and 1 "spare" kept powered down); each has a single
drive
with four partitions (/boot, /, /home, swap). I've already set up cron'd
rsync
jobs to copy the operations accounts between the workstations on a daily
basis,
so that when one fails, it is a simple, quick process to swap in the spare, restore the accounts from one of the others, and continue
operations. This
has been successfully tested in practice on more than one occasion.
However, when I perform system updates (about once a month), I like to create a temporary "clone" of the system to an external drive before
running the
update, so that I can simply swap drives or clone back if something goes horribly wrong. I have been using "CloneZilla" to do this, but it can take a while since it blanks each partition before copying, and requires a
system
shutdown.
Question 1: Would it be sufficient to simply use CloneZilla once to initialize the backup drive (or do it manually, but CloneZilla makes it easy-peasy), and then use "rsync -aHx --delete" (let me know if I missed an important rsync option) to update the clone partitions from then on? I am assuming that the MBR typically doesn't get rewritten during system updates, though "/etc/grub.conf" obviously does get changed.
We use rsync -HPavxz.
Suppose I want to store more than one workstation on a single drive (easy), and be able to boot into any of the stored configurations (hard). Here's what I thought of:
- Create a small "master" partition which contains a bootloader
(such as a CentOS rescue disk), and a single "swap" partition. 2) Create one partition "set" per workstation (/boot, /, /home, excluding swap). Obviously, these will all likely be logical, and each workstation must use unique labels for mounting partitions. 3) On the "master" partition, modify the bootloader menu to allow one to chainload the /boot partitions for each configuration. (This is the "Voila!" step that I haven't fully figured out.)
How 'bout setting up a pxeboot, with a kickstart file?
Or, alternatively, the way we prefer to do upgrades when we can. Using this, you could just get a minimally running system up - say, have that on a spare drive, then do this procedure. If you were careful, you might even do it using a Linux rescue.
Anyway, On a running system, mkdir /new /boot/new rsync -HPavzx --exclude=/old --exclude=/var/log/wtmp $machine:/. /new/. rsync -HPavzx $machine:/boot/. /boot/new/.
rsync -HPavzx /etc/sysconfig/network-scripts/ifcfg-eth* /new/etc/sysconfig/network-scripts rsync -HPavzx /etc/sysconfig/hwconf /new/etc/sysconfig rsync -HPavzx /boot/grub/device.map /boot/new/grub/ rsync -HPavzx /etc/udev/rules.d/70-persistent-net.rules /new/etc/udev/rules.d/
find /new/var/log/ -type f -exec cp /dev/null {} ;
<apache, cluster, other special stuff> rsync -HPavzx /etc/ssh/ssh_host* /new/etc/ssh Then, the rotation: zsh zmodload zsh/files
cd /boot mkdir old mv * old mv old/lost+found . mv old/new/* .
# Root partition. cd / mkdir old mv * old mv old/lost+found . #mv old/root . -- WHY? mv old/scratch . mv old/new/* .
sync sync
If the other hardware's different than the copied-from, mount --bind /dev /new/dev mount --bind /sys /new/sys mount --bind /proc /new/proc mount --bind /boot/new /new/boot chroot /new cd /lib/modules
VER=$(ls -rt1 | tail -1) echo $VER
mkinitrd X $VER mv X /boot/initrd-$VER.img
exit umount /new/dev /new/sys /new/proc /new/boot
And reboot.