HP 9000 DAT 2 & 3 index generation

[Greg Lackore]

Hi,

We have 3 D220: one with a DAT3 tape drive and the other two with DAT 2 tape drives. On the DAT 3 drive we use DDS3 tapes while on our two DAT 2 tape drives we are using DDS1 tapes.
The problem is: index files generated using fbackup from the DAT 3 drives work fine but those of with DAT 2 tape drives don't give any index values. Is there a problem with DAT 2 drives or DDS1 tapes that prevents index generation or is the problem elsewhere.

[Tim Malnati]

This is odd. An index is nothing more than a data stream to be recorded on the tape from the hardware point of view. I would be more inclined to suspect the software driver or the fbackup application. Are you seeing any errors in fbackup output? Are there any tape changes taking place during the backup evolution? To prove out your media theory a bit further, I would suggest that you attempt to perform a backup of one of the DDS2 drives using a DDS2 tape.

[Darrel Louis]

Strange problem, never had problems with DDS1 tapes on a DDS2 Device.
When you perform the following
frecover -I /tmp/back.log, do you get an error message.

If you perform a simple test:
make a graph that only includes /stand for instance and then run fbackup, do you get a error message.

[Greg Lackore]

Hello again,

I tried the second suggestion (I can't try the first until I get a DDS2 tape) but the result was the same. The command:

# fbackup -f /dev/rmt/0mn -g graph -u -v -I index

generated the following index file:
# 1 /
# 1 /stand
# 1 /stand/bootconf
# 1 /stand/build
# 1 /stand/build/conf.SAM.c
# 1 /stand/build/conf.SAM.o
# 1 /stand/build/conf.c
# 1 /stand/build/conf.o
# 1 /stand/build/conf.o.old
# 1 /stand/build/config.SAM.mk
# 1 /stand/build/config.mk
# 1 /stand/build/space.h
# 1 /stand/build/system
# 1 /stand/ioconfig
# 1 /stand/kernrel
# 1 /stand/lost+found
# 1 /stand/rootconf
# 1 /stand/system
# 1 /stand/system.prev
# 1 /stand/vmunix
# 1 /stand/vmunix.prev

The result was the same for all tape devices defined on the system.

[Darrel Louis · Accepted solution]

I've ran a test where I write the backup to a file instead of, see result below.
fbackup -f /var/tmp/0mn -g /tmp/graph -u -v -I /tmp/dar.index

dar.index:
6144 1 /
1024 1 /stand
191 1 /stand/bootconf
1024 1 /stand/build
35978 1 /stand/build/conf.SAM.c
34452 1 /stand/build/conf.SAM.o
35963 1 /stand/build/conf.c
34448 1 /stand/build/conf.o.old
3163 1 /stand/build/config.SAM.mk
3172 1 /stand/build/config.mk
316916 1 /stand/build/core
233 1 /stand/build/space.h
933 1 /stand/build/system.SAM
8483336 1 /stand/build/vmunix_test

When I do a frecover -f /var/tmp/0mn -I test
I get the same result as above.
If you get the same problem as with the tapes, it could be your fbackup, check if you have the latetst fbackup patchs.

[Greg Lackore]

Hi,

The suggestion from Daryl to use a local file instead of the tape device was a good one. The problem definiately seems to be in the fbackup software.
The systems where the indicies don't work are running an fbackup from patch kit PHCO_14176. The system that has a working fbackup is from patchkit PHCO_16031.

Thanks for the help...