Is it possible to use BRU for client-push backups?

Using BRU for Client Push Client-Server Backups

Because of BRU's architecture, it can be utilized as a client application, providing Unix-based systems with the ability to store data on tape drives located on a centralized backup server. This enables both centralized storage of data and, when properly configured, centralized management of the backup operation. This document will describe the steps necessary to implement such a centralized strategy.

In accordance with our License Agreement, you must purchase a copy of BRU for each computer it's used/loaded on. So, of course, this method requires that you purchase BRU Client for each Client you wish to back up. Client packs are available through our sales department at a significant discount.

Configuring The Clients

The first step is to define the relationship that exists between the client systems and the tape server. There are a few ways that this can be done, but we are going to discuss a simple, rsh-based method from which others can be built.

For this example, we will assume the following systems in the domain are to be processed:

For each of the client systems, we must provide a user that will have privileges sufficient to perform the backup operations. For our example shown here, we will use the root user.

If you are of a high security conscience nature we would suggest that you use the ssh secure remote shell suite of tools. While the setup of ssh is beyond the scope of this article, you should be able to simply change "rsh" for "ssh" as long as you configure ssh so that it does not prompt for a password when invoked.

Let's continue...
To start with, each client's root user should have a .rhosts file in the root user home directory. This may be / or /root, depending on the operating system used. To create the file, use your favorite text editor and add a single entry consisting of the full machine name and the name of the user logged in on that machine to access this system remotely: root

This means that anyone logged in as root on the system can rsh to this machine with no requirements for password authentication.

Once saved, chmod the file to 600 (rw-------).

To test the results on client1, for example, issue the following command from server while logged in as root:

rsh client1 ls

You should receive a listing of files in root's home directory on client1. If you receive a permission denied or a password prompt, double check the permissions on the .rhosts file and also check to make sure that client1 has appropriate routing information (either in NIS, DNS, or /etc/hosts) for and vice versa.

Configuring The Server

Once you have the .rhosts file configured on each of the client systems, you will need to reverse the link by configuring a root .rhosts file on server. This .rhosts file will contain each of the client system names in the same format as the one created on each of the client systems. root root root root root root root

This setup will allow each of the client systems to rsh back to server to perform the actual backup process. This file should also be chmod'd 600 as above. Test this using the ls command test that we used to ensure that the server could talk to the clients. This test should be run on each client system as root.

Install BRU on each of the client systems and make changes to the /etc/brutab file on each system to include the following device definition:

server:/dev/nst0 \
bufsize=32k size=0 tape rawtape seek=0 norewind noautoscan \
maxrewindtime=300 minrewindtime=30 \
rmtsvr="/etc/rmt" rmtsh="/usr/bin/rsh" \
fmtcmd="/usr/bin/rsh server mt -f /dev/nst0 erase" \
rfmcmd="/usr/bin/rsh server mt -f /dev/nst0 fsf" \
retencmd="/usr/bin/rsh server mt -f /dev/nst0 reten" \
rewindcmd="/usr/bin/rsh server mt -f /dev/nst0 rewind" \
eodcmd="/usr/bin/rsh server mt -f /dev/nst0 eod"

Note that we use the non-rewinding version of the device. On half of the client systems, use nst0. On the other half, use nst1. This allows us to have two backup streams in operation and make full use of the available tape drives.

For simplicity sake, create a small backup script on each of the client systems that runs BRU backing up files deemed important to continued operations. For example, we backup the /var/spool and /export/home directories on each of our systems with the following:

bru -cvvvf server:/dev/nst0 -Z -X /export/home /var/spool
if [ $BRUERR -ne 0 ]
exit 1
exit 0

Note that we use BRU's software compression on each client machine as this option reduces the amount of physical data that we transmit across the network. While we normally recommend that users with tape drives that support hardware compression not use software compression, this is one of the few instances that BRU's software compression can help.

Faster compression for BRU15.1. There is a method by which you can have BRU compress the data much faster. The cost is a slight increase in overall size; however, that should be acceptable for most when taking into account the increase in tmie. This is with BRU's compression flag, -N. By default, BRU uses 16-bit compression (-N 16). For faster compression, try -N12. Simply add the "-N12" into your existing command line and see if it makes a difference for you. In BRU 16, compression was changed and speed is the default (see man bru for -N entry).

Place this script in an available path (/usr/bin is our choice) and chmod its permissions with:

chmod 700 /usr/bin/

The next step is to create the management script (or scripts, in this case since we have 2 tape drives) on the backup server. This is the script that we use:

# This is script one - it backs up to /dev/nst0
# This script will backup the server and clients
MAIL=1 # if you don't want mail, set this to 0
LOGS=/var/log # set directory to send log files
REWIND="mt -f /dev/nst0 rewind"
# most OS/tapes allow mt to rewind nst0
# use st0 if nst0 refuses to rewind


# rewind tape for first backup - overwrites existing tape

# Backup Server
bru -cvvvf /dev/nst0 -X / > $LOGS/server.log 2> $LOGS/server.err
count=`expr $count + 1`

# Backup Clients
for x in client1 client2 client3 client4
  rsh $ /usr/bin/ > $LOGS/$x.log 2> $LOGS/$x.err
  count=`expr $count + 1`
  if [ $ERR -ne 0 ]
    echo "Check $x's backup log and err files. Something went wrong."
    echo "Error in $x's backup" >> /var/log/rmtoperation.err

# Rewind tape and begin verifications
echo "Verification of server, client1, client2, client3 and client4" \
  > $LOGS/drive1.vfy
while [ $count -gt 1 ]
  bru -iVf /dev/nst0 >> $LOGS/drive1.vfy 2>&1
  count=`expr $count - 1`

if [ $MAIL -gt 0 ]
  mail -s "Backup report for server, client1, client2, client3, client4" \
    < $LOGS/drive1.vfy root

This script will step through each of the systems, running the script that we created, log the file traffic, catch most errors and (optionally) send mail to root on server with the results of the operation. For the remaining systems, we would duplicate this script making appropriate changes.

Once created and tested, each of the two server scripts should be kicked off under cron control at a low point in operation of your network. We recommend that you start them with a 5 minute delay between start times to make it easier to determine what process is doing what operation when reviewing the backup or system logs.