BRU fails self-consistancy check when installing.
Before BRU attempts to install XBRU (BRU's GUI), it checks to see that the BRU binary operates correctly. If the BRU binary fails this check, you may see something like:
Cannot execute bru ... problem with installation
Failed self consistancy check
This is usually caused by one of the following:
Incorrect libraries
You can try using BRU's statically linked binary
This process is outlined in the /bru/README on your system
It is also covered in the ftp file BRU.README under "Older Systems"
Incorrect BRU
You may have the wrong BRU for your OS
BRU is compiled specifically for the OS you're using. If you've tried bru.static (as outlined above) and are still getting errors, contact your reseller.
Why does the bruexeclog show an incorrect year in BRU 15.0?
While BRU 15.0 is Y2K, we have found that our execution log, bruexeclog, logs the year incorrectly. This log is typically located in /var/log.
A fix for this is available at http://www.estinc.com/downloads/bru/brulog_update
Please note that this issue does not affect BRU's operational ability or its Y2K functionality. Only the output log, bruexeclog, is affected. All files within the archive are being saved with the correct four-digit year and all files backup and restore properly.
Why doesn't XBRU see my tape drive?
XBRU only recognizes non-rewinding tape drive entries in the BRU configuration file, /etc/brutab.
If you have not properly configured /etc/brutab with a non-rewinding entry you will only see items such as "/dev/null" and "file:" as your choices to write to.
The solution is to correct your current non-rewinding entry in /etc/brutab or to add a new entry to the /etc/brutab file for a non-rewinding device. We have sample brutabs on our site.
The differences between a rewinding and non-rewinding device within brutab are:
- The device name. Use a non-rewinding device name.
- nst0 instead of st0
- nrStp0 instead of rStp0
- 0n instead of 0
- rmt0.1 instead of rmt0
- The word norewind replaces the word rewind
- The word noautoscan replaces the word autoscan. In the event you do not have the word autoscan, add noautoscan following norewind
Why do I get rewind failures using XBRU on Linux?
There may be a couple of issues here:
The first is that mt version 0.5 is broken! If you're using this version ( mt -v ), a fix is located on our ftp site, /pub/linux/mt-st*
The second may be that you do not have the correct tape movement commands attached to your non-rewinding device within the file /etc/brutab. The example below is of a non-rewinding SCSI tape on Linux:
/dev/nst0 devname="SCSI tape drive, no-rewind" \
size=0 bufsize=32k \
shmseg=7 shmmax=256k \
reopen rawtape shmcopy tape norewind noautoscan \
fmtcmd="mt -f /dev/nst0 erase" \
rfmcmd="mt -f /dev/nst0 fsf" \
retencmd="mt -f /dev/nst0 reten" \
rewindcmd="mt -f /dev/nst0 rewind" \
eodcmd="mt -f /dev/nst0 seod"
Notice the last five lines. These are the tape movement commands. You can adjust them to match your system. Use your man pages to determine the best commands.
Are you running the latest version of XBRU? Click here
If XBRU still fails to rewind when trying to verify your backups, you can download our TapeTest.txt file. This file shows you how to determine what tape movement commands your system needs to work properly.
We also have several brutab examples shown at http://www.estinc.com/brutabs.html
Red Hat 6.0 Demo
The BRU demo provided with Red Hat 6.0 has a small problem. Most users find that the demo gets into an endless loop. A working demo is, of course, available:
Documentation for the demo is available is two formats:
Support for any Demo is only provided through the BRU mailing list. For information on joining, please visit:
We hope you enjoy using the most reliable backup and restore application available for Linux!
Does BRU work with the "XXX" brand tape drive?
BRU is totally "device independent." If the device that you wish to use to perform your backups is supported by your operating system, BRU will work with it. BRU will read and write to files on disk (i.e.: /tmp/mybackup.bru), floppy disks (i.e.: /dev/fd0) and tape drives that your OS supports. Additionally, BRU can read and write from/to standard out and standard in, allowing operations like this:
bru -cf - . | (cd /newdirpath ; bru -xvf -)
When I try to 'mount' the BRU distribution disk, I receive an error
The BRU distribution media is a 'tar' format floppy. It is not supposed to be mounted. The error occurs because mount can't find a valid filesystem on the diskette.
To install, use the following steps (Sun Solaris users see specific FAQ for Solaris systems):
cd /tmp
# the device fd0 may be different on your system
tar -xvf /dev/fd0
./install
rm install
Bru will install properly.
I can't seem to install BRU on my Sun Solaris system!
If you keep getting "device busy" or some other error while trying to read your BRU installation diskette, read the following....
Solaris has a Volume Manager which attempts to mount any diskette placed in the drive. You can use the following to install BRU:
# remove diskette from drive
./etc/init.d/volmgt stop
# insert diskette at this time
cd /tmp
tar xvf /dev/floppy0
# You may have to use another device name such as "diskette"
# as long as you see the files extract, it's working
#
# remove diskette and restart volmgt
./etc/init.d/volmgt start
./install
rm install
What kind of interface does BRU use?
BRU is a robust utility that can be used from the command line, within a script, or from our easy-to-use X11 GUI.
If you already have a legacy of tar-based backup scripts, you can simply replace all instances of 'tar' in your script with 'bru' and continue using the same scripts. Then, as you become more comfortable with the many optional features that BRU provides over standard tar, you can upgrade the scripts to take advantage of features like labeling, on-tape file directories, compression and other features.
Our X11 interface is available for all systems supporting the X11 Window Systems and Tcl 7.6/Tk 4.2 or the newer 8.0 version. For more information, refer to http://www.estinc.com/X11.html.
Is BRU faster than other backup tools?
BRU is designed to make the most of the system resources that are available. BRU can use whatever bandwidth is available on a system. If you are using a Quantum DLT on a SparcServer 2000, you could actually see BRU perform backups in the 1800 kilobytes per second range. However, if you're using a QIC-150 tape drive on an Intel 386 based system, you'll be more likely to see rates of 100KB/sec.
For more details, view "How Fast is my Backup" in the tips and tricks section.
Will BRU speed up the restoration of files from tape?
Because of BRU's device independent nature, there isn't anything that BRU can do to get to a file in a backup set beyond reading the tape until it locates the file or files to be restored. There are methods of backup that you can use that WILL improve the speeds with which restores are performed. See the examples in our "Guide to Easier Restores" in the tips and tricks section for details.
I Have Microsoft Windows (3.11 | WG | 95 | NT) and IBM OS/2 systems on my network. Can I back them up using BRU on a UNIX system?
*
YES!
Using a freely available tool called "SAMBA," you can provide full support for your Microsoft-based systems with some very simple configuration steps. What is SAMBA? Here's the answer from the SAMBA FAQ:
Samba is a suite of programs which
work together to allow clients to access Unix filespace and printers via
the SMB (Session Message Block) protocol.
In practice, this means that you
can redirect disks and printers to Unix disks and printers from Lan Manager
clients, Windows for Workgroups 3.11 clients, Windows NT clients and OS/2
clients. There is also a Unix client program supplied as part of the suite
which allows Unix users to use an ftp-like interface to access filespace
and printers on any other SMB servers.
SAMBA offers full smb server and client support for the UNIX environment. You can use it to configure your UNIX system as a file and print server for your non-UNIX systems.
Under Linux you can use the smbmount tool to access any "SHARE" enabled devices on the Microsoft systems from your UNIX environment by simply creating appropriate SHARE volumes on the Microsoft systems. With this setup, your server running BRU can properly backup and restore those DOS and Windows clients.
For other UNIX flavors and/or for more specific information look at the SAMBA page <http://www.samba.org/> and documentation as well as the Microsoft documentation concerning SHARE volumes. Once you have the Microsoft SHARE volumes mounted on your UNIX server, BRU will provide full backup and restore for your "SHARED" non-UNIX workstations.
I use NetATalk to provide server services for Apple Macintosh systems on my network. Other programs fail when trying to backup files with names containing spaces. Can BRU help me? *
BRU will handle filenames containing spaces whether they are from a Macintosh or just because a user did something like: touch "A File With Spaces". BRU will properly backup, verify AND restore files with spaces in the names
Is BRU Client/Server? *
BRU is client/server in the sense that we provide mechanisms that allow you to backup client workstations to a centralized backup server via either a "Server Pull" mechanism, where the server mounts the clients under NFS, or "Client Push" where the clients push their data up to the server using the RPC/RMT interface. Since UNIX itself is relatively Client/Server (meaning that you can login to a remote station and perform management operations without the need for special applications), you can remotely manage your BRU operations from anywhere on your UNIX network. Look here for an example of a Client-Server script.
Is the BRU tape format like tar or cpio?
NO! In fact, it is the tape format used that ensures you that your data is properly backed up. When Fred Fish created BRU in 1985, he realized that 'tar' "the application" was a good tool, but 'tar' "the format" was susceptible to errors that would not be uncovered until you tried to restore your data. BRU's proprietary format allows us to ensure that every byte of data written to tape was written successfully.
Some other tools provide you with "difference" or "comparison" verification in an attempt to get beyond this limitation and it provides a relatively safe mechanism on systems where the backup takes place on quiet systems where files are not being accessed. On real-world systems, however, the differences, or errors, reported by this type of verification would reduce the usefulness of the backup. Because BRU uses a 32 bit CRC with every block written, we are able to fully verify a tape's contents at any time after the backup occurs, whether immediately following the backup or 3 weeks afterward.
What makes BRU better than its competition?
BRU was designed with one purpose in mind: Reliable Backups! Instead of spending many years of development on a fancy frontend and then depending on a weak backup format as a foundation, BRU was designed with reliability at the tape format level as its formost requirement. As a result, BRU provides a foundation upon which simple system backup or full enterprise data backup can be built.
Also, BRU is very frugal when it comes to system resources. On an average system, BRU will require less than 1 MB of disk space and can be run in under 2 MB of memory with full performance.
Since BRU is device independent, we do not dictate what backup devices you can use. Your choices are limited only by operating system support and your budget.
Can BRU write more than one backup on a tape?
By using the norewind device (usually /dev/nrst0, /dev/nst0 or your normal tape device with an 'n' on the front end), you can use BRU to write multiple backups to a single tape. For example:
bru -cvf /dev/nst0 -L "First Backup Set" /etc
bru -cvf /dev/nst0 -L "Second Backup Set" /usr/X11R6
bru -cvf /dev/nst0 -L "Third Backup Set" /home
mt -f /dev/nst0 rewind
bru -ivf /dev/nst0
bru -ivf /dev/nst0
bru -ivf /dev/nst0
This would write, then verify, three backup sets on the tape device nst0 and then rewind
the tape. You would then use the 'mt' command to position the tape for
restoring from the proper backup set. To restore from the /usr/X11R6 backup
set in the previous example, you could use a command sequence like:
mt -f /dev/nst0 fsf 1
bru -xvf /dev/nst0 /usr/X11R6/bin/xxgdb
mt -f /dev/st0 rewind
The only thing that you need to keep track of is what backup set the specific files were placed into. Refer to the "Guide to Easier Restores" in the tips and tricks section for more details.
Does BRU work with autoloaders or jukeboxes?
Yes. BRU provides a mechanism that allows you to automatically load a new tape when the current tape is filled when using Sequential autoloaders. By configuring the UNMOUNTCMD variable to point to a script or executable, BRU will pass control to the script and wait for the operation to complete. Once completed, control returns to BRU and we continue where we left off. We show two methods of setting up autoloaders on our site at http://www.estinc.com/autoloader.html
Note that the current X11 interface for BRU, XBRU, doesn't work with autoloaders.
I Have multiple tape drives on my system. Can BRU use them all?
If you have more than one tape drive, you can tell BRU to start on one and then automatically "spill-over" to each of the reminaing drives in turn. Once the last device is filled, BRU will prompt the operator to change tapes and then it will start the process where it left off.
Additionally, you can actually start multiple instances of BRU, segmenting your backup into the number of devices you have available, reducing your total backup time dramatically!
My tape drive has ECC, why is BRU's CRC so important?
In creating a system backup, your backup software copies your data from your file system into a buffer in memory. From there, the data is transferred through your system and across the system backplane to the backup device controller. From the controller, the data is passed over a cable to the backup device. Once in the backup device's input buffer, the data is then processed and drive-based ECC is added. BRU's CRC is added when the data is copied from the fixed disk to the memory buffer. This way, if the buffer is corrupted on its way to the backup device, BRU will realize this and inform you. The drive would have just provided error correction code for the bad data.
Can I read tapes written on a friend's (SUN|DEC|HP|C64...) on my (CRAY|VIC20...) if they were written using BRU?
BRU is designed to be compatible over all of the supported systems. While the Commodore 64 and VIC20's may have been a bit over the edge, BRU will automatically detect byte-swapped environments and make changes transparantly to ensure that the data restores as you would expect. Additionally, the current version of BRU will always read any backup created with an earlier version.
I've heard BRU will allow me to backup data to a remote "tape server." How is this done?
*
BRU provides builtin support for the 'rmt' device as defined in 4.3BSD and outlined in Richard Stevens' book, "UNIX Network Programming" from Prentice Hall.
This requires that you have all normal network security operations properly configured between the system being backed-up (the client) and the system with the tape device (the server). Also, the rmt server daemon must be present on the server system. To test this, try to perform an rsh (or rcmd for SCO systems) FROM the client TO the server. For example, 'rsh server ls -l' should return a listing of the files on the server for the user account which you are logged in as. Once this works, you need to locate the 'rmt' daemon on the server so that BRU will know what command to execute. It is usually in /etc, but you may need to perform a 'find / -name rmt -print' to get the proper path. Finally, you make an entry in your /etc/brutab file on the client machine that would look something like this:
# remote 4mm DAT drive
server:/dev/nst0 devname="Remote DAT on Server" \
size=0 bufsize=32k tape rawtape noautoscan norewind \
ignoreclose minrewindtime=90 maxrewindtime=360 \
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" \
rmtsh="/usr/bin/rsh" rmtsvr="/etc/rmt"
This tells BRU that you will be using "/dev/nst0" on the machine "server:" and that it should use "/usr/bin/rsh" to communicate with "/etc/rmt" on server.
Of course, you will need a licensed copy of BRU on each CLIENT machine that you wish to backup in this manner.
The numbers at the end of my backup don't seem to match.
The reported size information for blocks and kbytes written at the end of a backup will include any final buffer padding that occurs. If you have set your bufsize to 20K, BRU will always pad the end of the LAST file written with nulls to fill out an entire nuffer. Therefore, if the last file ended 2K into the last I/O buffer, BRU will add 18K of nulls to the backup. This would make the report seem 9 blocks larger than the reported backup. While this it not so problematic if you are using small bufsize settings. In the event of using 200K for your bufsize, you could end up with a 198K difference in the amount of data written in comparison with the amount of tape actually used.
I have a tool called BRU on my SGI system. Is this the same product?
Yes. Silicon Graphics licensed BRU release 9.11 which they ship on every SGI system delivered.
EST will be happy to upgrade your BRU version to our latest release (currently BRU, v15.1). BRU for SGI is available for $499 per license up to 4 licenses. Call (800) 998-8649 to order your upgrades or for more information.
Please Note: EST does NOT provide support for the version of BRU included with the IRIX operating system. Please contact SGI for support on this version.
Does EST offer BRU demos?
* NOTE: All FAQs marked with "*" indicate a feature that is only available on Commercial BRU. These particular items are not available on our Personal Edition (see BRU-PE).
|
