KB Logo

TOLIS Group Knowledge Base

Browse KB by category:
Go to KB #:
Glossary
Email   Bookmark



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

Views: 10734
Posted: 02 Oct, 2007

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 example.com domain are to be processed:

  • server
    System with 24MM DDS -3 loader drives (/dev/st0 & /dev/st1) - Our "Backup Server"
  • client1, client2, client3, client4,client5, client6, client7
    These are our specified client systems

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:


server.example.com root
 

This means that anyone logged in as root on the system server.example.com 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 server.example.com 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.

client1.example.com root
client2.example.com root
client3.example.com root
client4.example.com root
client5.example.com root
client6.example.com root
client7.example.com 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"

  • server is your server's domain name where rmtsvr is the location of rmt on remote server and rmtsh is location of rsh (or ssh) on the local system
  • CAUTION: be sure you use the same bufsize on all clients AND servers. Failure to do so may cause verification issues from the server unless you add "-b N" to your scripts where "N" is your bufsize

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:

#!/bin/sh
bru -cvvvf server:/dev/nst0 -Z -X /export/home /var/spool
BRUERR=$?
if [ $BRUERR -ne 0 ]
then
exit 1
else
exit 0
fi

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/rmtbackup.sh
 

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:

#!/bin/sh
# 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

count=1

# rewind tape for first backup - overwrites existing tape
$REWIND

# 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
do
  rsh $x.example.com /usr/bin/rmtbackup.sh > $LOGS/$x.log 2> $LOGS/$x.err
  ERR=$?
  count=`expr $count + 1`
  if [ $ERR -ne 0 ]
  then
    echo "Check $x's backup log and err files. Something went wrong."
    echo "Error in $x's backup" >> /var/log/rmtoperation.err
  fi
done

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

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

This script will step through each of the systems, running the rmtbackup.sh 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.

Others in this Category
document The BRU Server hardware scan hangs
document I have multiple tape drives but only one gets used, can BRU Server use multiple drives?
document How do I move my BRU Server Environment from one server to another?
document My Library or drive is not seen by BRU Server During the Hardware Scan, why not?
document My backup stalls shortly after starting, why?
» More Articles



RSS
Powered by KnowledgebasePublisher
Page Load Time: 0.038384 seconds / 38.384 milliseconds.
Page File Size: 31439 bytes.