tape backups not holding enough

[Matt Harrell]

A customer has an HP K250 server with a DDS3 backup. We're using fbackup configured in SAM to run system backups. The tape drive is only several months old, as the original was recently replaced when it failed.

For some unknown reason, about two weeks ago, the backups stopped fitting on one tape. There's actually currently *less* data being backed up than before, too (we're migrating Windows home directories off of this server and on to an NT one).

I've done quite a bit of testing, including tar backups, and the drive seems to be functioning fine, other than it's not holding what it should be. Currently, there is about 7.9 GB of data selected to be backed up, and it's asking for a second tape.

I experimented with recreating the backup, and only selecting certain directories. Here's what I had initially in my testing late last week:

/etc
/stand
/opt/samba (for config info)

This worked, fitting on one tape. Then I added /home (about 6.5 GB). It still fit on one tape. I then added one online Progress database backup (about 710 MB). This worked. Then, when I added another online backup of a different DB (about 610 MB), it started asking for a second tape.

The onsite sys admin says he's using the same DDS3 tapes (12/24 GB) he always has. We've also tried brand new DDS3 tapes (same results). What could be wrong? Is it time to replace another tape drive?

[Steve Steel]

Hi

You probably have a lot of open files during the backup.
The tape steps on while the maximum 5 retries are done.This can lose a lot of tape.

see man fbackup.

Make fbackup a config file with 2 retries and then see
.
Fbackup man page

+ Create a suitable configuration file called config in the
directory /var/adm/fbackupfiles call with -c in fbackup.

Options
-c config config is the name of the configuration file, and can
contain values for the following parameters:

o Number of 1024-byte blocks per record.
o Number of records of shared memory to allocate.
o Number of records between checkpoints. Since the
EOF marks between checkpoints are also used for
fast searching on DLT-format drives, changing the
checkpoint frequency may also affect selective
recovery speed (see WARNINGS section).
o Number of file-reader processes.
o Maximum number of times fbackup is to retry an
active file.
o Maximum number of bytes of media to use while
retrying the backup of an active file.
o Maximum number of times a magnetic tape volume
can be used.
o Name of a file to be executed when a volume
change occurs. This file must exist and be
executable.
o Name of a file to be executed when a fatal error
occurs. This file must exist and be executable.
o The number of files between the fast search marks
on DDS-format tapes. The cost of these marks are
negligible in terms of space on the DDS-format
tape. Not all DDS-format devices support fast
search marks.



steve Steel

[Frank Slootweg]

If this is HP-UX 11.0 or higher, then run fbackup with the "-v" option. This will tell how much data is written to the tape *drive*.
If that is 12GigaByte (Native Mode (is uncompressed) capacity of a (*125* meter) DDS3 tape) or more, then all is well.

[Rodney Hills]

If you go to the software archive and porting centre, their is a utility called "ddsinfo" that can get actual amount of data transfered and compressed. ddsinfo queries the hardware of your dds drive. The drive needs to be one of the newer (like dds3).

-- Rod Hills

[Carlos Fernandez Riera]

DDS3 tapes are 12 GB native, so it is very strange it can not fit in your tape.

I can imagine some reasons:

The tape drive is not perfectly ok. Try to mount a cleaning tape 2 o 3 times.

The speed of transfer is not too high... ?? there are more tapes or disks in that scsi channel?

the data is compressed on disk.

A missconfiguration on fbackup parameters like tape capacity or something like this.


Anyway see http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x8d51a22831ebd5118ff40090279cd0f9,00.html


Compile my program and see if there are retrys, errors .....


Good luck.

[Nick Wickens]

Have you checked the device files that are being used for the tape. I was thinking along the lines of is a device file configured for DDS2 being used ? or is the default device file being used.

man page for mksf might be worth looking at or you could try removing the device files that the tape is using under /dev/rmt and running insf -e to recreate them (you might want to do some more research on this first though)