Relax and Recovery (ReaR) is great. It does exactly what it needs to do with the minimum of fuss.
I’ll start by explaining what ReaR does and does not do. The “does not” part is important as many people I’ve spoken with about ReaR have been confused about exactly what it does.
The main purpose of ReaR is to create a bootable image, based on what is currently installed on a Linux host, that can be used to partition disks and retrieve a backup of the system. There are options for where to create the bootable image and what to do with it after it has been created.
The bootable image can be a USB device, an ISO file or a number of other options.
If you create a bootable image on a USB device then you may also wish to create a backup of your system on the same device, which ReaR will support.
When creating a bootable image as an ISO file you have a multitude of options for what do to with the file in order to get it off the box so that it can be used for recovery. The two options I have used are rsync and TSM.
The misconception I mentioned earlier is the belief that ReaR will backup your system. It can do that, but it is not a given and depends on your configuration.
If ReaR isn’t backing up the system, what will?
ReaR will work with tar, rsync and a number of 3rd party commercial backup solutions. Again, I have used rsync and TSM.
You might be asking yourself why this is important/useful.
Imagine your beloved machine has suffered a death by file system corruption. You have a backup of the system, but what next? You need a way of getting the backup data back on disk. I know a number of places that do not restore full systems, but rather rebuild them if something goes horribly wrong with the operating system. I can see the value in the approach, however, it relies on you knowing what the state of the system was. For example:
- What configuration changes have been made since the installation?
- What additional software has been installed?
- What scripts have been put in place?
The list goes on.
It is totally possible to manage all that, but you have to be proactive. It’s a problem that won’t solve itself.
If you don’t have details of all the customisations then wouldn’t it be really nice to be able to run a command to pull back the contents of all your local file systems as they were at the point of the last backup, allowing you to simply reboot and be back in business? That’s what ReaR will do for you 🙂
The following is an example of the produce to protect a system with ReaR and TSM during some operating system patching activities (assumes TSM is already installed):
- Install ReaR (rpms are available here).
- Configure ReaR to use TSM and to create an ISO file by updating /etc/rear/local.conf with a line of OUTPUT=ISO and another with BACKUP=TSM.
- Run “rear -v mkrescue” to create the bootable ISO and send it to TSM (mkbackup would have the same effect in this case as TSM will be handling the file system backups independently – I feel mkrescue makes it clearer what you’re doing).
- Perform a incremental backup of your file systems with TSM using “dsmc inc …”.
- Do your patching activity.
If all goes well then you don’t need to boot from the ReaR ISO and restore you operating system. But, let’s say it didn’t go well. Your system will no longer boot and there’s no immediately obvious way forward. You decide to restore. The procedure is:
- Restore the ReaR ISO to a location that will allow you to present it to the server. This is most likely to be your desktop so you can present the ISO file as a virtual CD-ROM over the ILOM interface.
- Present the ISO to the host to be recovered.
- Boot the host from the ISO – It is highly likely that you’ll need to change the boot order or get a pop-up menu to select the ISO as the boot media.
- Select “Recover <hostname>” at the grub prompt.
- Log in as root (password not required).
- Run “rear -v recover” and answer the interactive prompts.
Since starting to use ReaR I have encountered two problems:
- When recovering a host that used an ext4 file system for /boot I found myself facing at message of “Error 16: Inconsistent filesystem structure.” from grub. After a bit of digging around and trying to understand what the issue was I ended up modifying the /var/lib/rear/layout/disklayout.conf ReaR file to change the file system type for /boot from ext4 to ext2. I initially tried ext3, but as the system did not use ext3 for any of the file systems the module was not available.
- The version of ReaR that I was using had a bug (tracked on GitHub) that affected systems that do not have a separate /boot partition. There is a patch for the bug available, but if like me you’re happy to have a manual workaround, you need to perform the following actions after the restore completes:
# chroot /mnt/local # PATH=/bin:/sbin:/usr/bin # grub-install <disk path> # exit # reboot
Finally, it’s worth mentioning that ReaR is written in shell and is open source.