There is work to be done! There's a war to be won!

Thursday, 2 December 2010

Howto: NetBackup BMR for Windows / Linux / Solaris 6.5.6

The last time I played around with NetBackup BMR (Bare Metal Restore) was with NetBackup 3.4. I always found it a pain to setup and dismissed it because it didn't work as advertised on the tin.
The idea is building a box from a complete disaster using NetBackup in something like 20-25 minutes. The places I've worked in the past haven't really used BMR, but I've always dug the idea of getting a box up and running in 25 minutes. Its way cool and almost as good as watching old Star Trek re-runs.

'What do you mean you're able to get these computers talking to one-another through the air?! Are you insane, man? That's mad talk!'

Anyway, I like documents. I respect the way a good document is written and love testing/breaking things - call me whatever you want, but I get a kick out of dissecting and learning.  Here's a doc I've written which I'm hoping will help someone out. I'm also writing it down here because I've come to the realisation over the years that if I don't write it down somewhere I'll forget it.

In the following example, I installed/configured BMR and created a Boot Server for Linux/Windows and Solaris(x86) and emulated a disaster of a media server (with Dell PowerVault 120T directly connected), and a few clients. Unfortunately I don't have the luxuries of clustering software on my home network else I would've played with it too. In-fact I wanted to throw completely dissimilar hardware into the mix, but with x86 you're limited with whatever you've got, but I did mess about with NIC cards and played around with HBA's a little in order to make it as difficult as I could with what I've got.

BMR

Basic components of BMR is the BMR package itself and the Bare Metal Boot Server installation. The idea is you install the BMR package on the master server. This is found on the NetBackup Add-On Products Software for BMR CD (for UNIX/Linux and Windows). The Boot Server can actually be installed on master or media servers or even a client, but the BMR package itself must be installed 1st. There is nothing additional needed on the client, its installed there by default. The rule behind a Boot Server is that for each type of client you want to protect, you'll need to have a Boot Server.

Windows BMR:

- Setup BMR Master Server. On Windows you'll need to run bmrmss.exe which will setup the BMR database. You can also do this via start -> programs -> veritas netbackup -> bare metal restore master server setup.
- Turn on BMR in a backup policy; "ALL_LOCAL_DRIVES" (this includes the SYSTEM_STATE) is what you need to take a backup of, with "collect disaster recovery for bare metal restore" checked. You'll then see the client and its config in the BMR node in your NetBackup Admin Console.
- Boot Server is only needed when you actually want to restore a client; you'll then use the boot server assistant (or bmrsrtadm on UNIX) to create your SRTs (Shared Resource Tree). SRTs contains the funky things like the OS itself, NetBackup client software, and anything else you might like or perhaps need to include from the file system or volume management layers.

More details on the creation of the SRTs on Boot Server for Windows:

- NetBackup client Software (this is the installation media from the client which is a *.msi file) and is found on the installation media for that particular client.
- As mentioned, you can include file system or volume management layers in the SRT too, and/or you can create different SRTs for the same OS (i.e. maybe you have different drivers or different volume management versions etc)
- Some resources like NIC drivers and Mass Storage Devices (MSD) must be in the BMR package pool and made available for restore
- You can use media or network boot for restore depending on your needs. Network is way cooler.

The way you do all this is following the Bare Metal Restore Boot Server Assistant (Programs -> Veritas NetBackup ...). You then use the Shared Resource Tree Administration Wizard, and create a shared resource tree, giving the SRT a name / description / location and path to NetBackup client software image.

After SRT was created, PXE (Preboot Execution Env) was started on Boot Server (Via PXE Service Configuration Wizard) - this launched a daemon I noticed which was used later to find out what was going on behind the picture. The client was then booted off its PXE (setup this in the clients BIOS) and was then able to contact the boot server (this works via DHCP which I installed separately on an old Vmware box or a host entry in the Boot Server host file). The rest of the BMR process just worked to plan perfectly; network environment was setup, drives were partitioned, formatted and files were restored to the C and D drives on the client in about 25 minutes. I was as satisfied as I am after eating a good piece of biltong.

UNIX BMR

After you install the BMR stuff on UNIX/Linux, it creates the Bare Metal Restore Server DB for you in /usr/openv/netbackup/baremetal/server/data and loads data into the DB. It then creates /usr/openv/netbackup/bin/bmrconfig, bmrd (actual BMR daemon) bmrepadm, bmrovradm, bmrpan, bmrprep, bmrs, bmrsetupmaster, install_bmr and rc.bmrd. I tried finding out more about all these daemons, but no surprise to find that I couldn't find out exactly what they all did.

The Boot Server part of the install creates in /usr/openv/netbackup/baremetal/server/data and netbackup/bin/bm* (bmrbd = actual boot server daemon), bmrsetupboot, bmrsrtadm, installbmrboot, mkfifo, rc.bmrdb). Installation of the boot server tries to update /etc/dhcp.conf which didn't exist and it also warns about tftpd server not being active. These were all needed on my installation (Linux Redhat Boot Server), including compat-libstdc++ and nfsd packages installed.

The tftp-server binary (I installed from source and built it, old hang-up I have from configuring/making an installing kernels from my FreeBSD days!). All you need to do is modify the /etc/xinetd.d/tftp file and change disable=yes to disable=no. Restart xinetd and you're on your way.

The dhcp.conf file was modified to:
log-facility= local7;
ddns-update-style none;
ignore unknown-clients;
subnet <ip_address_subnet> netmask <mask_of_subnet> {
default-lease-time 600;
max-lease-time 7200;
option routes <ip_address_of_gateway>;
}

nfsd server was then installed (/export/srt was used by the recovery to house the actual SRT which is used to do the restore)

Again, make any changes to services above, remember to HUP inetd / xinetd.

On UNIX / Linux use bmrsrtadm to create your shared resource tree on your Boot Server. Default location to create the SRT is /export/srt. You then create your SRT by mounting the image locally or from a share. I also downloaded the ISO according to technote:
http://www.symantec.com/business/support/index?page=content&id=TECH37875
This is a BMR 3rd-party product not included in Linux distribution.

Again, I made a backup using the BMR details above for windows (ALL_LOCAL_DRIVES etc) and then emulated a DR by ripping up my root partition and generally destroying it. Within 25 minutes my client was up and running. Later I did the same on one of my Solaris Media servers, and played around with getting the tape drive online. Worked like a charm.

No comments:

Post a Comment