Browse KB by category:
Go to KB #:
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 example.com 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.
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:
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.
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:
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:
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:
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 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.