Dan Brown wrote:
During a backup, or a flush, the tape drive writes data for 4 seconds, then rewinds for 1 second, then writes for 4 seconds, then rewinds for 1 second, etc. This seems like a good way to wear out a drive.
That's usually a symptom of a too fast tapedrive connected to a too slow server. But before you trow out the server, verify that your configuration does indeed use the holdingdisk!
Not only does that lower the lifetime of the drive, it's also immensly slow.
Amanda does quite a good job to keep the tape streaming, using two processes with a shared memory bufferpool (one that fills the bufferpool from the holdingdisk file, the other one that writes the bufferpool to tape).
This may be a problem then as the IDE holding disk is NFS mounted from a third machine. The server with the backup is a SCSI only system and doesn't support IDE. It was worth neither the cost of an expensive SCSI drive (+$700CDN / 80GB?!) nor even a $60IDE card for that matter. When we get our next server I'll convince the people with the money to move to SATA based servers. A tape library would be nice eventually too.
Will adjusting the tapetype help at all to speed up or slow down the drive or is that only a rated write speed like CDR/RW (the CDs, not the burners) are rated to maximum speeds before data corruption starts to occur?
I adjusted the tapebufs setting from 20 to 128, and the DLT drive now writes for around 10 seconds before stopping and seeking. I've adjusted it to 256 to see what happens once I need to flush the holding disk again. I think because of the fact the holding disk is mounted via NFS I may increase this to 512 (16MB) or higher to see what sort of threshold it has.
Other possibilities I may try include connecting the holding disk server and the tape server directly via ethernet (they both have a spare connection at the moment) to cut out any network lag issues at our switches (and odd hub).
Dan [EMAIL PROTECTED]
