Ultrium 920 SCSI - 400GB tapes reporting full when only 200GB of data on them

[Gudzy]

I'm having problems with my Ultrium 920 SCSI.

Using Backup Exec 2010 which I've just recently installed, the LTO3 tapes (800GB compressed, 400GB uncompressed) are only fitting anywhere between 200-300GB of data on the tape. I am encrypting the data through backup exec, so the data is uncompressed, but it's still not even getting close to 400GB.

Hopefully I've sucessfully attached a support ticket from LTT.

Thanks

Tom

[thomasr]

I'm not seeing the attachment.

I've seen three common causes of tapes not reaching the native capacity recently.

1) The tape head is getting toward end-of-life.  A worn-out head will require lots of rewrites, chewing up capacity.

2) Media is poor, again requiring lots of rewrites and wasted space

3) Data is not getting to the drive fast enough to keep it streaming.   Your half-height LTO-3 drive has a native full write speed of 60MB/second   There's a buffer in the drive that is a first-in-first-out queue which at first fills up and then during a backup is both read from and written to as the backup progresses.  If the server can't keep up with the tape write speed and the buffer gets less and less full, the tape drive will slow down writes, to as little as 1/3 of the full native write speed.

If even that doesn't help and the buffer gets empty, the drive has to stop, rewind, and start moving forward again -- all while more data is coming in to refill the buffer -- finding the spot it left off writing... but then it has to leave a bit of a gap before it can start writing again.    Those gaps can really add up if you're under a consistent 20MB/second feed speed.  (Note: those whose data is, say, 2:1 compressible need to keep a consistent 40+MB/sec going to the tape drive).

That's a long way of saying that if your server/disk are too slow, it could well be eating your tape capacity.   The fact that you're performing encryption in the backup application is a warning sign; I've seen SW encryption slow backup performance by 50% because of the heavy CPU load it generates.

If your drive is a standalone drive, you might want to check out HP TapeAssure, a free download (see http://www.hp.com/go/tapeassure )  which can monitor a lot of the above in real time.  (Note: TapeAssure is free and works with LTO-3 and above drives that are standalone or in enterprise libraries; it works with LTO-4 and above in MSL libraries)

If you've run a drive test ih HP Library and Tape Tools and it didn't say there was anything wrong with the tape drive, then I suspect it's a feed speed issue.   Check your average throughput by dividing the size of the job by the elapsed time; if it's anywhere close to 20MB/second or less, you've probably got a buffer underrun problem.  And if that's so, there are some ways to fix it, depending on where the bottleneck is.

- Faster source disk: Buy new hardware, use a faster RAID or more spindles, defragment, defragment, defragment.

- If you're CPU bound (check while the encrypted job is in process), get a system with faster CPU.  BE encryption is probably single-threaded, so dual 8-core processors won't help as much as a faster dual-core CPU.

- The Workaround: Maybe your whole disk doesn't need to be encrypted.   Perhaps you have a sensitive database or application files that are really the only things needing encryption.   In that case, a) TURN HW AND SW COMPRESSION OFF for this to work.  b) Set up two backup jobs, where the first has encryption on and only backs up the data that needs encryption (one or a few directories), and the second backs up all the rest, unencrypted.      This may well help, because all those tiny, very slow-to-read windows files won't have the additional overhead of getting encrypted, too.

[Gudzy]

Thanks for that through reply thomasr, that's helped a lot.

The support ticket showed a warning in regards the SCSI bus speed only being 80MB/s and it recommends 320MB/s. I'll see if that can be improved easily.

The network card in the server running the tape drive is only 100Mb whereas all the other servers are 1Gb and use cat6 cabling, so we were looking at upgrading that anyway. I noticed that the network utilization stays at a fairly steady 95% when backing up so this could probably keep the data flow at too slow a rate as you mentioned.

The system that the tape drive is running on is an old Pentium 3 server with 10k SCSI drives (in RAID as far as I'm aware), so I think the CPU is likely to be a bottleneck also...