KB Logo

TOLIS Group Knowledge Base

Browse KB by category:
Go to KB #:
Glossary
Email   Bookmark



How do I utilize Quick File Access (QFA) with BRU 17.0?

Views: 14326
Votes: 1
Posted: 02 Oct, 2007

Performing QFA With BRU 17.0, 16.0 or 15.1

ATTENTION: Although the information contained herein is believed to be accurate at time of writing, TOLIS Group, Inc. neither guarantees nor warrants that this information will be useful or correct. User should determine the usefulness of the information presented.


While indexing, cataloging, and QFA (Quick File Access) are being worked on for an upcoming release of BRU for some platforms, it is also possible to do QFA with the current release of BRU, with a little advance planning.

Also, while we've tested this under Linux 2.0.x kernels with DDS and TR-4 SCSI drives, it may not work for your particular installation and OS. Please check the capabilities of your particular tape control software (mt, tape, tctl, tapecntl, etc.) and tape drive to determine the usefulness of the information presented.


What We Need

There are certain requirements for being able to do QFA. Primarily, we need a drive that supports the SEEK command for tape positioning. Most SCSI-II tape drives satisfy this requirement. Second, we need a SCSI subsystem and a tape manipulation command that allows us to issue the SEEK to the drive. An example for Linux to verify that you can SEEK/TELL on a particular drive:

[root@work /]# bru -cf /dev/st0 /etc
[root@work /]# mt -f /dev/nst0 seek 200
[root@work /]# mt -f /dev/nst0 tell
At block 200.

Remember to use the non-rewinding device for the mt commands. For other systems, please consult your tape/tctl/tapectl/mt man pages for details on how to seek/tell with your tape drive.

Please also note that you will need to use BRU from the command line to create backups compatible with QFA. The 15.x/16.x version (XBRU v1.23) of the X11 Interface for BRU is not currently capable of creating a QFA compatible backup. However, 17.x supports QFA from the X11 interface (XBRU v2.1.x).


Performing the Backup

The following is an example of how to produce a backup that will work for QFA. Please note the change to a fixed block size of 512-bytes.

#!/bin/sh
# Script to perform backup of entire system
# and create a compressed index file
#
BRUEXECLOG=/tmp/bruexeclog.$$ ; export BRUEXECLOG
MAILTO=you@yourhost.yourdomain
DATE=`date "+%m/%d/%Y %H:%M:%p"`
mt -f /dev/st0 setblk 512
# This command must contain the "V" and at least 2 "v"'s
bru -cZVvvf /dev/st0 / | gzip >/tmp/bruindex.$$
id=`zcat /tmp/bruindex.$$ | grep "Archive id:" | cut -f 2 -d :`
id=`echo $id`
mv /tmp/bruindex.$$ /bru/logs/$id.gz
mail -s "Backup results for `hostname` on $DATE" $MAILTO < $BRUEXECLOG


Testing

There is a slight difference between the way BRU 16.x and 15.1 report the file location. While most of the logic is the same, BRU 16.x is easier in that the number needed for the seek calculation is on the same line as the file you're looking for whereas, with 15.1, the number needed is contained on the previous line. Both examples will be shown below.

Let's make sure things are working right. Here is an example of a test with a backup of /etc:

[root@work /]# bru -gf /dev/st0
[stuff deleted...]
archive_id: 366839d0021b
[stuff deleted...]

For our example, let's attempt to extract /etc/passwd. Due to the differences between 16.x and 15.1, we must use different grep commands.

For 16.x, use:

[root@work /root]# zcat /bru/logs/366839d0021b.gz | grep /etc/passwd
c 22k [1] /etc/passwd
c 2792k [1] /etc/passwd-

For 15.1, use:

[root@work /root]# zcat /bru/logs/366839d0021b.gz | grep -1 /etc/passwd
c 2k of 22k [1] /etc/motd
c 2k of 24k [1] /etc/passwd
c 2k of 26k [1] /etc/printcap
--
c 2k of 2792k [1] /etc/issue.net
c 2k of 2794k [1] /etc/passwd-
c 2k of 2796k [1] /etc/redhat-release

Let's try both of the password files. Extraction may vary, we'll show 15.1:

[root@work /root]# mt -f /dev/nst0 seek `expr 22 \* 2 - 4`
[root@work /root]# bru -ivvf /dev/nst0 -QV | head -5
buffer size = 32k bytes
media size = 11718720 Kilobytes (11.71 Gigabytes) usable
i 2k of 4k [1] /etc/passwd
i 2k of 6k [1] /etc/printcap
i 2k of 8k [1] /etc/profile
[root@work /root]# mt -f /dev/nst0 seek `expr 2792 \* 2 - 4`
[root@work /root]# bru -ivvf /dev/nst0 -QV | head -5
buffer size = 32k bytes
media size = 11718720 Kilobytes (11.71 Gigabytes) usable
i 2k of 4k [1] /etc/passwd-
i 2k of 6k [1] /etc/redhat-release
i 2k of 8k [1] /etc/backuptab

If your display agrees with the above (numbers may be different), it worked!

For BRU 16.x, the block calculation is based on the location of the desired file where 15.1 is based upon the end of the previous file. We take that location (indicated by the "of Xk" field in 15.1), multiply that by 2 to get the number of blocks to that location, and subtract 4 to make sure we end up one BRU data block before the file we are looking for. Thus, in your tests, the "Xk" of the file you are looking for should be 2k more than the size of the file (in BRU data blocks).

Notice that the numbers DON'T match what is in the catalog, since the counting starts where BRU begins reading.

Also, we need the -QV to tell BRU to ignore the fact that it won't find a header block, and we use the non-rewinding device for the mt/bru commands. You should also verify that the rewinding/non-rewinding device nodes are setup to use the same bufsize in /etc/brutab.

What if it's not working?
There are several reasons why the above might fail. If:

  • The 'mt seek' command fails.
    Then your drive or SCSI subsystem may not support QFA. Consult your system documentation.
  • You see:

bru: [A118] rerun with "-b ?k" argument
bru: [I117] don't know how to rewind archive device

  • Then you have a mismatch in bufsize settings between your rewinding and non-rewinding devices.
  • BRU doesn't list the correct files
  • Your backup was not done in 512-byte fixed block mode, or
  • You may need to disable hardware compression, or
  • Your drive/SCSI subsystem may not fully support QFA.

Restoring with QFA

Assuming the verification tests above work as expected, we can take the next step to restore a file using QFA with BRU.

[root@work /root]# mt -f /dev/nst0 seek `expr 22 \* 2 - 4`
[root@work /root]# bru -xvvvvvf /dev/nst0 -QV /etc/passwd

Now, here is a sample script to automate some of the drudgery of the above. By default, this script will work with BRU 16.x. For BRU 15.1, be sure to change the "LINE=" line as indicated within the script.

#!/bin/sh
#
# QFA recovery script for BRU (/bru/brestore)
#
# Copyright 1998-2001 by The TOLIS Group, Inc.
#
# rewinding and non-rewinding devices - edit for your devices
RDEV=/dev/st0
NRDEV=/dev/nst0

# Check to make sure filenames were entered
if [ $@missing = "missing" ]
then
echo "Usage: brestore filename [filename] [filename] ...."
fi

AINFO=`bru -gf $RDEV`
if [ $? != 0 ]
then
echo "Not a BRU tape!"
exit 1
fi

done=0
for x in $AINFO
do
if [ $done = 1 ]; then
AID=$x
break
fi
if [ $x = "archive_id:" ]
then
done=1
fi
done

AID=`echo $AID`
if [ ! -f /bru/logs/$AID.gz ]
then
echo "Didn't find catalogue for archive id: $AID"
exit 1
fi

for arg in $@
do
######################################
# Code change needed for 16.x or 15.1
######################################
#
# This following line is for BRU 16.x
LINE=`zcat /bru/logs/$AID.gz | grep "] $arg"`
#
# Change this script to use the line below
# instead if using this script with BRU 15.1
#
#LINE=`zcat /bru/logs/$AID.gz | grep --before-context=1 "] $arg"`
#

if [ $? != 0 ]
then
echo "$arg: not in catalog"
continue
fi

LINE=`echo $LINE`
BLOCK=`echo $LINE | cut -f 4 -d " "`
# in compressed backups, we actually need field 5
if [ $BLOCK = "of" ]
then
BLOCK=`echo $LINE | cut -f 5 -d " "`
fi
# trim "k", and convert to 512-byte blocks
BLOCK=`echo $BLOCK | cut -f 1 -d "k"`
BLOCK=`expr $BLOCK \* 2 - 4`

echo "Extracting $arg at block $BLOCK..."
mt -f $NRDEV seek $BLOCK
if [ $? != 0 ] ; then
echo "failed command: mt -f $NRDEV seek $BLOCK"
continue
fi

bru -xvvf $NRDEV -QV $arg
done

mt -f $RDEV rewind
#
# End of brestore script
#
######################################################

This combination will allow you to access files in a more more direct manner and speed up single file restores dramatically on those devices that support this type of operation.

Others in this Category
document How do I use BRU with CRON?
document Disable/Enable Hardware Compression When Using BRU
document Important changes made to the 'bruxpat' file declaration in version 17.0.1.4.6 and higher.
document Sample BRUTAB Settings
document Setting up an Autoloader to work with BRU - Method 2
» More Articles



RSS
Powered by KnowledgebasePublisher
Page Load Time: 0.039919 seconds / 39.919 milliseconds.
Page File Size: 33338 bytes.