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:
> 1) 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.