Friday 3 June 2016

Backing Up My Hypervisor

So following on from my last post on Backing Up My Virtual Guests here's a long overdue post on how I'm backing up my hypervisor.

The hypervisor is KVM running on a USB stick with Centos 6.8 and I'm making use of Relax and Recover, which the good folks at the upstream vendor have chosen to add into version 6.8.

Setup is straight forward, install the rear rpm and edit the configuration file /etc/rear/local.conf
OUTPUT=ISO
OUTPUT_URL=file:///backup
BACKUP=NETFS
BACKUP_URL=file:///backup
BACKUP_PROG_EXCLUDE=("${BACKUP_PROG_EXCLUDE[@]}" '/media' '/var/tmp' '/var/crash')
EXCLUDE_RECREATE=( "${EXCLUDE_RECREATE[@]}" "fs:/isos" )
So this will create a backup of the OS installed on the USB stick to my backup drive in /backup/einstein. It won't touch the RAID volume with the LVMs containing my guests but their configuration will be saved as part of backup so they will be available again on restore.
The exclude options stop it backing up some temporary areas to save space and also the isos directory as that's on the RAID volume.

The output will be an  ISO (/backup/einstein/rear-einstein.iso) which can be used to boot the machine for restoration and a large tar ball in the same directory containing the files.

And that's it.
I additionally removed the daily cron job in /etc/cron.d/rear and replaced with the following to perform a backup twice a month as this is sufficient for my needs and matches what I do for my guests.

30 3 2,16 * *   /usr/sbin/rear mkbackup > /dev/null 2>&1

So how do I restore then?

The USB stick has gone pop and if I've put another same sized one in then restoration is easy.
Boot off the ISO, select the Recover einstein.at.home option, mount up the backup drive and run the recover command.
# mkdir /backup
# mount /dev/sdd1 /backup
# rear recover

Once completed (and it will take quite a while!!) recreate the isos mount point (mkdir /mnt/local/isos) and remove any erroneous blank lines that may have got inserted into /etc/fstab (I don't know why this happens but it will generate warnings during boot if you don't fix).

Reboot and bingo you have a working system again.

I used a larger USB stick, it wont recover?

Yes it will, you just need to do a little bit more work. Rear can't find an identical disk to recover to so asks whether you want to map the recovery to another disk. If you pick option 6 (do not map disks) and then option 2 (edit disk layout) you can tell it to force partition the new stick the same way as the old one by uncommenting these lines.

    • disk /dev/sde 7864320000 msdos
    • part /dev/sde 524288000 1048576 primary boot /dev/sde1
    • part /dev/sde 7338983424 525336576 primary lvm /dev/sde2
    • lvmdev /dev/vg_einstein /dev/sde2 EC1aq1-z2Sv-8ARK-IrvJ-cGVv-eLFp-JvwXLe 14333952
    • lvmgrp /dev/vg_einstein 4096 1749 7163904
    • lvmvol /dev/vg_einstein lv_root 1562 12795904
    • lvmvol /dev/vg_einstein lv_swap 187 1531904
    • fs /dev/mapper/vg_einstein-lv_root / ext4 uuid=c2c66e88-641a-484f-b574-3e0de6170d4b label= blocksize=4096 reserved_blocks=4% max_mounts=-1 check_interval=0d bytes_per_inode=16353 default_mount_options=user_xattr,acl options=rw,relatime,barrier=1,data=ordered
    • fs /dev/sde1 /boot ext4 uuid=c5e1b99c-e039-4f76-8947-67ec8e728f6a label= blocksize=1024 reserved_blocks=5% max_mounts=-1 check_interval=0d bytes_per_inode=4095 default_mount_options=user_xattr,acl options=rw,relatime,barrier=1,data=ordered
    • swap /dev/mapper/vg_einstein-lv_swap uuid=e4e02117-935e-43d3-a7fc-fae005581f68 label=

Now you could get clever here and amend the partition sizes to make use of the extra space but in my situation there isn't any point!!

Next select option 5 (continue recovery) twice and the recovery should then continue as above.