HP-UX 11.0 fbackup question | Is my DLT streaming?

[Chris Elmore]

Aloha Good Folks,

Recently my backup windows went down from ~10 hours to ~2 hours. I am wondering if I have somehow magically engaged the streaming mode on my HP's DLT tape drive. I would like to verify this with someone out there who has some experience within this arena. I have included more details below and I am also attaching a copy of my fbackup shell script.

I have a (A5589A) HP Surestore E DLT8000 tape drive HVDS and (A5584A) DLT library 2/20 SA HVDS. I am not currently using the Surestore robotics at all (manual loading/unloading of tapes via front control panel) and I am running my backups through the fbackup program.

I used to run it entirely via the (cron) automated backup option within SAM, but I have recently changed over to running it from within a very simple shell script that I have written. At first our backup window was about 10 hours a week ago, but for the past three days I've noticed this curious behaviour of the backup running in only about 2 hours.

The only way I can explain this is if the streaming mode was engaged, or if the backup is skipping massive portions of the system. Any ideas folks? Thanks in advance.

FBACKUP STATS:
[Time] [Blocks Read] [Blocks Written]
39,188 64,355,809 *
34,265 61,941,002 62,652,298
5,874 61,191,345 61,897,079
5,844 61,208,813 61,913,984
5,891 61,237,181 61,942,499

Last Backup Results:
fbackup(1004): session begins on Mon May 9 18:30:01 2005
fbackup(3203): volume 1 has been used 29 time(s)
fbackup(3024): writing volume 1 to the output file /dev/rmt/0m
fbackup(1005): run time: 5891 seconds
fbackup(1030): warnings encountered during backup
fbackup(3055): total file blocks read for backup: 61237181
fbackup(3056): total blocks written to output file /dev/rmt/0m: 61942499


Very Respectfully,
Chris Elmore

[A. Clay Stephenson · Accepted solution]

I assume you have bumped up you blocksperrecord and readerprocess values in your fbackup config files. The best method, I have found to determine if the tape drive is straming most of the time, is to use glance. glance -> Process List -> Process Open Files. You then determine how rapidly the file offset for the tape drive is changing over a given sampling interval. IF that values compares well (> 60% or so) or the maximum rated throughput for your drive then you are streaming. If not, it will be a very small fraction of the rated throughput. I suspect what has happened is that the fbackup config file has been changed.

[Patrick Wallek]

You can't engage/disengage streaming mode on the tape drive.

What you can do, as Clay mentioned, is tweak your fbackup config file so that it can read data from disk and write it to tape much more efficiently.

You could always have a look at the contents of the tape. If you generate an index file when you run your fbackup, have a look at it. If you don't generate the file, have a look at frecover and use it to look at what files are on the tape.

[Chris Elmore]

Aloha Clay,

Thanks for your rapid response, I've always appreciated your knowledgeable help in the past. I haven't made any changes to my fbackup procedures other than to run it via the command line option from within a shell script, and I didn't invoke the -c option to specify a config file, so what files can I check to see if this is the case? Thanks in advance.

Very Respectfully,
Chris Elmore

[Chris Elmore]

Is it true that the default blocksperrecord is set to 16? What numbers have you folks tweaked your drives to? I am reading from Marty Poniatowski's HP-UX 11i System Administration tome and it has some basic info on pg. 334 about common maximum block sizes for differing media. If I have been running with only 16 before, I think I should be able to bump it up somewhat for a DLT8000 drive? Thoughts anyone?

Very Respectfully,
Chris Elmore

[Patrick Wallek]

Before you go much further you need to see what exactly is on your fbackup tape. You need to verify that all that you expect is on the tape. If it is not, you will need to tweak your fbackup command line in your script.

What is the fbackup command line that you are running in your script?

Here is a sample fbackup config file that is highly recommended:

# cat fbackup.conf
blocksperrecord 512
records 64
checkpointfreq 1024
readerprocesses 6
maxretries 5
retrylimit 5000000
maxvoluses 200
filesperfsm 2000

Here is the fbackup command line that calls it (I also use a graph file - and everything in my script is defined as variables):
/usr/sbin/fbackup -v -f ${TAPE} -c fbackup.conf -g ${GRAPH} -V ${VOL} -I ${INDEX} > ${LOG} 2>&1

[A. Clay Stephenson]

If you are not using a config file then the default values are those listed in the config file in the fbackup man page. For a DLT7000/8000, the defaults are really lousy and are probably a decade out of date.

I would setup a config file with values very similar to this:

blocksperrecord 256
records 32
checkpointfreq 1024
readerprocesses 6
maxretries 5
retrylimit 5000000
maxvoluses 500
filesperfsm 2000

Essentially, the trick is to feed data fast enough to your tape drive to keep it streaming. Also, anything above a DLT7000 must be on a dedicated SCSI bus.

[Chris Elmore]

Aloha Patrick,

I really appreciate the extra info you've posted. I do plan to read back the index files on the 3 DLT tapes in question to validate and verify that all of our files are still being backed up. As for my shell script, it is attached to my initial post, by I have included it below for your convenience. I am also parsing through your settings and I am considering updating the standard default settings I have been running with to better optimize my backups. Thanks.

Very Respectfully,
Chris Elmore

x-----------x cut here x-----------x

clear

# Declared program variables for timestamp.
date>xxx
cc=`date +%c`

# Section 1
cd /
fbackup -f /dev/rmt/0m -i / -v
# > /export/chris/fbackup_logs/fbackup_$cc.txt
mailx -s"fbackup has finished" user@mail.com < /export/chris/email/fbackup_email.txt

[Chris Elmore]

Thanks again folks, I think I have the right tools at hand now to tackle this problem. I will definitely start tweaking the config defaults and make sure to test and verify the old indexes to be safe. Please take care and keep up the good work you folks do for the HP community.

Very Respectfully,
Chris Elmore