You can use the -s option to tell BRU the capacity of the media you are using. With most modern operating systems and tape devices, this setting is not necessary. However, you may wish to set the media size for devices like removable disks or disk files. NOTE: When you use this option, it overrides any value you may have specified in the brutab file with the size= parameter. If you have two or three different sizes of tape that you use for your backups, but only one tape drive, you can use the -s option each time you run BRU to specify the size of the tape you’ll be using. However, this is tedious, and specifying a size larger than the actual size is a serious error.
A better solution is to create “aliases” for the tape drive, and change your brutal file appropriately. Simply duplicate the basic brutab entry for the device, but change the device name and size= parameter. Here’s an example:
/dev/tinytape size=10M [other parameters]
/dev/medium size=20M [other parameters]
/dev/bigtape size=30M [other parameters]
Now create links for each new device name:
$ cd /dev
$ ln st0 tinytape
$ ln st0 medium
$ ln st0 bigtape
The paths /dev/st0, /dev/tinytape, /dev/medium, and /dev/bigtape all point to the same device, but BRU considers them to be separate devices with the characteristics given in the brutab file.
When the -s option is specified, it overrides any other default value, even that read from the tape header during a read or scan of the archive. The value that you give with the -s option should be an integral multiple of the BRU buffer size. However, BRU does not indicate any error when the value is not a multiple. Instead, BRU calculates the effective media size by silently rounding down to the nearest multiple of the buffer size.
One very handy use of the -s option is to create an archive in a set of normal files, for transfer via modem or email to another system (using mail, ftp, or another file transfer utility) where the receiving system limits the size of incoming attachments. By splitting the archive into several smaller pieces, large archives can be transmitted in small chunks, reducing retransmission overhead in case of errors. For example:
bru -cv -s600K -f bru1 -f bru2 -f bru3 [files]
will cause BRU to write its archive into the files called bru1, bru2, and bru3. Each file would have a maximum size of 600K bytes. These files could then be sent to another system (remote) with the UNIX scp (secure copy) command:
$ scp bru1 user@remote:/usr/spool/uploads
$ scp bru2 user@remote:/usr/spool/uploads
$ scp bru3 user@remote:/usr/spool/uploads
and unpacked on that system with the commands:
$ cd /usr/spool/uploads
$ bru -xv -f bru1 -f bru2 -f bru3