 |
|
| HOME | PRODUCTS | KNOWLEDGE BASE | SUPPORT | DOCUMENTATION | DOWNLOADS | REGISTRATION | WHERE TO BUY | ABOUT US | CONTACT US |
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:
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. 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. You may also want to review our Quick File Access (QFA) document: Performing QFA with BRU 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 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 tape 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 more reliable than its competition? BRU was designed with one purpose in mind: Reliable Restores! 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 foremost 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:
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:
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. If you have access to the mtx utility, you may expand the library support to actually allow BRU to use the random slot access supported by larger libraries. We show two methods of setting up autoloaders on our site. Note that the current X11 interface for BRU, XBRU, doesn't work with autoloaders. Since XBRU is released as Open Source under the QPL, please feel free to extend the existing functionality to include features that you may find missing. 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 remaining 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 relying on the ECC alone. Additionally, you can read Reliable Verification - The Facts 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 transparently 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 built-in 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:
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. 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 buffer. 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. TOLIS Group will be happy to upgrade your BRU version to our latest release (currently BRU, v17.0). BRU for SGI is available for $499 per license up to 4 licenses. Call to order your upgrades or for more information. Please Note: TOLIS Group does NOT provide support for the version of BRU included with the IRIX operating system. Please contact SGI for support on this version. Does TOLIS Group offer BRU demos? |
|
Copyright © 1995-2010 TOLIS Group, Inc. All rights reserved.
Terms of Use | Privacy Policy | Press | Site Map TOLIS Group, Inc. US GSA contract # GS-35F-0492N |