Joe Dog Software

Your JoeDog still likes rear.

He uses it for bare metal recovery and system cloning. Recently he had to clone one server onto older hardware as part of a disaster recovery exercise. It was problematic.

Problem one: The rear recovery disk could not connect to the network.

This system had bonded NICs and Your JoeDog started to suspect they were causing an issue. When the recovery disk booted, he brought down all the network interfaces and tried to assign a new address to the server. The routing table looked fine. The eth0 config looked fine, but the network was unreachable.

Acting on a hunch that bonded NICs were giving him fits, Your JoeDog did a recursive grep of the rear directory …

… wait a minute, what’s a recursive grep?
You can do it like this:

$ find /usr/share/rear -print | xargs egrep -i bond

Cool, thanks …

Anyway, as a result of that search, he found this feature: SIMPLIFY_BONDING With a little more digging, he discovered that it takes ‘y’ or ‘n’ so Your JoeDog set it to y and re-archived the server. He added that directive to local.conf

SIMPLIFY_BONDING=y

When the server booted from the new recovery disk, the only network interface was eth0. Your JoeDog reset that address with ifconfig and he was able to clone the server from his rear archive. SUCCESS!!!!

Problem two: No success! After the rear recovery, the kernel panic’d and the server wouldn’t boot. Unhappy sad time. 

Your JoeDog was all, “Hmmm I’ll bet I need to rebuild the kernel for new hardware….”

So he restored again from rear. This time, when the recovery was complete, he chroot’d the mount point and rebuilt the kernel.

… wait a minute! How do you do that?
Glad you asked. Here’s my command history:

$ chroot /mnt/local
$ export PATH=/sbin:/bin:/usr/sbin:/usr/bin
$ cd /boot
$ mkinitrd -f -v initrd-2.6.32-431.20.3.el6.x86_64kdump.img 
                 2.6.32-431.20.3.el6.x86_64

NOTE: Whatever you call the kernel, i.e., whatever you use for the second argument of mkinitrd, make sure you have a directory by the same name in /lib/modules, i.e., /lib/modules/2.6.32-431.20.3.el6.x86_64

DOUBLE NOTE: Once you’re inside /boot, do an ls to find available kernel images. They’ll begin with initrd- and end in .img

Now get yourself some rear.

Your JoeDog loves rear! And who doesn’t, amirite?

Except it’s not that rear. It’s an acronym for Relax and Recover, a Linux bare metal recovery tool.

Your JoeDog has been using Mondo for cloning systems. It’s good software that served him well despite difficulties moving from one hardware set to another. If Your JoeDog archived sd disks and recovered to cciss, then he was knee deep in i-want-my-lvm hell.

Rear makes those type of migrations much easier. If you archive a server using one type of disk driver and recover it to one that requires another, rear reworks the disk layout for you. It’s also configured to ignore external disks. If you archive a server connected to a SAN, rear simply ignores those multipath devices.

Like Mondo, you can archive and recover from an NFS server. Here’s a suggested configuration for NFS archiving. Place these directives inside /etc/rear/local.conf

OUTPUT=ISO
BACKUP=NETFS
NETFS_URL=nfs://10.37.72.44/export
NETFS_OPTIONS=rw,nolock,noatime
OUTPUT_URL=file:///export

To archive the system, run ‘rear -v mkbackup’

This configuration creates an ISO image called ‘rear-hostname.iso’ inside 10.37.72.44/export/hostname. To recover the server, burn that ISO onto a CD and boot the system with it. Select the Recover option then run ‘rear recover’ at the command prompt.

“It’s that simple,” Your JoeDog said with the zeal of a recent convert. He’ll be back to bitch about rear in a couple weeks but for now it’s nothing but love….