Most Un*x packages have some form of archival software. Linux is no exception, and the administrator of a system has at his or her disposal such tools as gzip, tar and cpio to rely on. The problem with such programs, in the (paraphrased) words of BRU's authors, is that they provide no intrinsic safeguards against faulty archival media other than the initial read. It is possible, therefore, to maintain a religiously-kept full system backup...for a typical Linux box, potentially 800Mb...which will refuse to be retrieved because of a bad MBR on the first floppy. BRU, on the other hand, verifies all writes automatically, no matter the media. BRU also performs on-the-fly compression, can maintain a directory of the contents of a given media, will do backups across network drives, and can be used to restore files to a new location while keeping the substructure of the directory tree intact.

The test copy of BRU was shipped as two 3.5'' floppy diskettes: one containing the actual BRU package and the other a TCL/TK graphical front end, stored as a BRU archive. Be ready...the users' manual is the better part of an inch thick and is spiral-bound. It probably would not withstand a great deal of use...but once you get the system configured for operation and set up an appropriate crontab file, you can probably put the manual on a shelf for a few weeks at a time.

Installation was a matter of reading Section 2 of the manual, then turning back to the first page of the section and proceeding. The actual BRU software is stored in tar format, so initial installation was a simple command of
tar xvf /dev/mydev
where mydev was the installation floppy. You may wish to prepare a suitable temporary directory for this...I used /usr/tmp with no problems. Once the command prompt returns, simply type
./install
and wait a few minutes while the software installs and self-tests. Eventually you get the shell prompt back and can start the setup process, which consists of telling BRU the specifics of your backup devices. Yes, plural. BRU will use whatever, and however many, devices you wish, as long as they are recognized and configured properly. For sysadmins of file-servers, ISPs, etc., this means comparatively painless usage of juke-box-type tape drives, multiple disks, or whatever.

One thing I did notice was that the install process wanted to put BRU's man page in a usr/contrib/man directory. Not knowing this at first...it's one of the few things not in the manual...I couldn't prepare for it (my Red-Hat Linux does not use such a directory normally), so the man page didn't get installed. In my case, not really that much of a problem...not only do I have this wonderful manual in front of me, but for quick help a simple
bru -h
will give a brief rundown of possible command-line switches.

Installing the graphical interface was a matter of invoking BRU and ``restoring'' it from the second floppy. Another side-note...the package I received contained no documentation on the GUI, other than a single sheet of paper printed like an order form---which it is. EST is providing the printed documentation to registered users free of charge on completion of printing. All you have to do is complete the form, including the serial number for your copy of BRU (it's on the distribution disk) and mail it in. I had not received my copy at the time of this writing, but if it's as well-written as the users' manual, nobody should have any trouble getting it to do whatever you want.

Getting the GUI running was a little trickier, as I did not have wish in my path, so every time I tried to invoke the interface under X, the shell complained. This gave me a few minutes' puzzlement, until I edited the script to explicitly declare the path to wish. Presto... functional graphic interface. Linux users who, like me, are on a budget and can't afford niceties like Motif will be happy to see that the entire interface is written in TCL and TK. Very open, as it should be, for BRU exists in appropriate flavors for not only Linux, but SCO, Solaris, HPUX, Digital UNIX/Alpha, BSD, Unixware, and probably some others I've forgotten about.

The brains of BRU is the configuration file /etc/brutab. Within this file are the definitions for each and every device BRU will utilize for archival. A sample file is included in the book, and the intimal setup at installation time will generate this file, but sometimes there are some options which must be hand-fed to take advantage of.

Also installed are two scripts, fullbru and incbru for making full and incremental backups, respectively. They would probably work best (for me) called from cron at suitable intervals.

Two more scripts are included in the installation: mountcmd and unmountcmd. These are provided for sysadmins to modify with appropriate commands to operate tape stackers or juke-boxes, so that when one tape fills, the next is automatically loaded and mounted for almost seamless operation. It should be noted that these two scripts are useless as provided, for they lack the instructions to make these devices work. It is up to the sysadmin to edit these scripts as needed for full function.

Customization of the actual contents of a backup can be done by wildcard, relative or absolute reference, or by pre-prepared file listings. One drawback I found is that when selecting by prepared file list, BRU will not expand wildcards; this is a feature, not a bug, as the developers felt no need to reinvent the wheel, so included no intrinsic wildcard-handling routines. Besides, if you know what files you want, you can declare them in the referencing file...

I did give BRU a short test run using nothing but good ol' trusty /dev/fd0, my 3.5'' drive. I backed up a sample user's home directory, including about 3Mb of mixed data, onto four disks (I left compression off...) in a matter of about two minutes. The software will dump data as fast as the device can take it, so a lot of the time was spent with me fumbling for the next disk. Restoring the same data took about half as long because part of the backup operation is an AutoVerify mode (which defaults to on) that checks each disk (or whatever) once it's full. File compression, if desired, is accomplished ``on-the-fly'' using standard LZW algorithms...not terribly original or especially efficient, but a de facto standard, and quick. The suite uses no buffer files; all compression is done in memory. Another caveat: BRU provides no file-locking during backup, so the archival of shared files such as database information would best be done in a single-user runlevel to prevent an erroneous error message during verification. Or worse. The brutab file can (and should) include the required commands for formatting disks, tapes or whatever. More esoteric commands go in the mountcmd and unmountcmd scripts.

Certain options which I would, by default, use every time:

AutoVerify always on.

Other than that, proper operation can be completely handled by making the appropriate entries (as root, of course) in the system crontab file. There being an impressive list of options which can be declared as global variables, this suite can be completely customized with little or no effort and placed in operation within an hour.

All in all, I was happily impressed with the package. The manual gives an excellent description of all facets of operation of the package, as well as a brief description of how to use cron. All told, an installation of BRU will only take up about 1.5Mb of space, but can save a sysadmin countless hours of aggravation. And while not ``absolutely essential,'' I would rate this product as ``HIGHLY recommended.''

As an endnote...as I submit this, I note that EST has now released a new product: BRU2000. I wonder how they planned on improving an already excellent product.

For more information on this product, contact Enhanced Software Technologies, Inc., 5016 S. Ash Ave., Suite 109, Tempe, AZ 85282. They are on the 'Net at http://www.estinc.com or email info@estinc.com.

When not tinkering with Linux, TeX or LaTeX, Alan can be found at the wheel of a tractor-trailer rig traveling interstate, or at the hockey rink. He can be contacted by email at awjump@sprintmail.com.

For more information on the Tulsa Computer Society click here

---

This page has been accessed times.
Tulsa Computer Society 11/08/97

Don Singleton, President
tcs@galstar.com