Monday, July 26, 2010

Installing Backup Exec System Restore on CentOS 5.5 and First backup / restore

As I said in my review I would telling you how to install this on CentOS 5.5, so here it is.

Normally one would simply run the Symantec_Backup_Exec_System_Recovery.bin with ./Symantec_Backup_Exec_System_Recovery.bin. But on a non-supported distribution / kernel that won't work.

However all is not lost! You can install this with a little shell-fu.
Instead of ./Symantec_Backup_Exec_System_Recovery.bin run
./Symantec_Backup_Exec_System_Recovery.bin --noexec --target .

This will extract the contents of the binary to the current directory. Next you need to install a few RPM packages, but you need to know what version of kernel you are running (for me it was either PAE or non-PAE). So I ran uname -a to see what version of the kernel that machine was running.

rpm -Uhv SymSnap/symbdsnap-1.0.1-36146.2.6.18_8.el5PAE.i686.rpm
rpm -Uhv symmount-1.0.1-36352.i686.rpm
rpm -Uhv besr-1.0.1-36352.i686.rpm

Once all of these packages are installed I was able to do my first backup. And by first backup I mean first three (/boot, /, and SWAP). While I probably don't need to do all three (/boot and /) I don't want to have to create a SWAP system after a restore. So I ran all three.

besr -b/dev/sda1 -d /Storage/backups/hostname/boot.v2i -use-aes-encryption standard -p SoM3SupErSecureP@ssW0rd -compress Standard
besr -b /dev/mapper/VolGroup00-LogVol00 -d /Storage/backups/hostname/Vol00Log00.v2i -use-aes-encryption standard -p SoM3SupErSecureP@ssW0rd -compress Standard
besr -b /dev/mapper/VolGroup00-LogVol01 -d /Storage/backups/hostname/Vol00Log01.v2i -use-aes-encryption standard -p SoM3SupErSecureP@ssW0rd -compress Standard

Now in /Storage/backups/hostname I have three files
boot.v2i
Vol00Log00.v2i
Vol00Log01.v2i

If I needed to restore these I would use the Backup Exec System Recovery Windows based LiveCD. During the restore I would choose all three of these in the order shown above.

After the restore process was finished I need to boot using the gparted LiveCD. Once in I would open up a terminal and install grub on to my sda hard drive.

#grub
#root (hd0,0)
#setup (hd0)
#quit

Once grub is installed on sda I needed to update fstab to no longer look for / on the /dev/mapper/VolGroup00-LogVol00 and swap to not be on /dev/mapper/VolGroup00-LogVol01.

Backup Exec System Recovery Review


I asked a question over on Serverfault about backup software that supported Windows and Linux and did Bare-Metal Recovery and the response I got was to try Backup Exec System Recovery, which so far has been pretty good.

The bad stuff:

1) Restore CD creation on CentOS is impossible from what I have tried and can tell. They really do mean Redhat Enterprise Linux only.
2) Bare-metal recovery with MBR restore doesn't work. Which means I have to install grub after a restore.
3) LVM support is once again not there or well hidden.
4) Centralized management. It is a separate 1GB download as an Addon. I did the download and install, but now I can't find the Management console. Setting up each of our servers isn't too big of a problem, but I really wanted one window to view for backups.
5) There is no built in scheduler with Linux.
6) There is no incremental backup in Linux.

The good stuff:
1) It works on CentOS with a little bit of hacker-y to install (more on that in another post).
2) It is easy to install and configure on Windows, even though it requires a reboot. (BOO!)
3) It is pretty quick to get a backup started.
4) The backup procedure is different on Windows than on Linux. Windows is GUI based 100%. (I haven't looked to see if I can configure a backup from the command line.) While Linux is 100% CLI.
5) The Windows based restore CD is a pretty useful tool with out limits (unlike the Acronis Boot Disk).
6)Restores are quick and pretty simple to do.

All in all after trying three different products and looking at half a dozen I think this may be the winner.

CHECK_NRPE: Error - Could not complete SSL handshake

Recently I have been auditing our servers versus what we check in nagios versus what we need to do when a system is rebooted during routine maintenance. I found that two of our servers have been left out of nagios monitoring even though they are on my maintenance checklist, and they have software that I still start by hand (I KNOW IT'S NOT A BEST PRACTICE!).

Both servers had NRPE installed and configured (mostly), one of them even had a configuration file on the nagios server but it wasn't enabled (hostname.disabled instead of hostname.cfg). The other server needed a configuration file, but even then it wasn't working, so here are my troubleshooting steps:

1) Check to see that NRPE is compiled and installed. [It was]
2) Check that NRPE was listening (netstat -an | grep 5666) [It was]
3) Check that NRPE was listed in /etc/services [It wasn't]
4) Check the NRPE config file (/etc/xinetd.d/nrpe) for "only_from = 127.0.0.1 192.168.100.31" [It wasn't]

So I added the service definition to /etc/services and the nagios server IP to the only from line and restarted xinetd (service xinetd restart) and I was finally able to connect from my nagios server.

All of this is on CentOS 5.5 for both the server and the client.