First of all, the tape drive is insanely stupid. My machine gets hung for over a minute at the BIOS level just trying to detect the drive. And I can't boot into Red Hat Linux 9 (it gets stuck in stage 1.5 of grub) if there's a tape in the drive. Furthermore, it's nearly impossible to convince the drive to eject the tape during POST. You have to press the eject button repeatedly, and hope you get lucky. Sometimes it takes 3 reboots to get lucky. So I have to remember eject the tape before shutting down.
There are problems with activity on the IDE bus when trying to write to tape, which can actually cause it to hang (some CD burners have the same problem). Unfortunately, RH ships by default with a process that monitors the IDE bus for new CDs you put in, so it can autoplay them. The solution is to just kill this process with an rpm -e magicdev.
Finally, there are problems getting the tape to store the advertised amount of capacity. High-end tape drives do hardware compression, but this doesn't qualify as high-end. So I tried using a -j flag on dump to get the OS to compress the data on the fly. That also doesn't work, because the tape drive doesn't support a variable block size (which that compression would require). At this point, I gave up. I'm currently dumping my data uncompressed. But if you're really motivated, you could always dump -j to a file, then tar that file to tape. Of course that assumes you have 20 gig (or however large your tape drive stores) of disk space to spare for the compressed dump.
[In case you hadn't guessed, I would NOT recommend this drive to anyone. Their tech support was slow (response time sucked), clueless (didn't know much about unix), and even rude (I was yelled at by one of them). It's not surprising Seagate dumped them into another company (Certance), if only to save their name from embarassment.]
On a vaguely related note....
I also discovered some fairly serious problems with the consistency of
the dumps. Apparently filesystem activity during backups can cause
pretty severe problems (this is a fault of linux/ext3, not of the tape
drive). I tried working around this by using LVM snapshots, but I've
had 2-3 kernel crashes (RH9) as a result of the LVM snapshot code in the
kernel being buggy. I still like the method (as it ensures consistent
backups) but you may not want to use it unless you're on something more
recent than RH9.
I guessed that an outdated firmware might be related, so I downloaded their update utility and the latest firmware. Running it causes the tape drive to rewoffl the current tape, and then the firmware update fails with:
The operation failed during the actual upgrade of firmware. 04/3F/02So I contact them. They decided to send me the firmware update on tape as a way to bypass linux. So now I'm running the latest firmware. Not that it seems to have helped. I still can't compress my backups. I forgot to check whether I can re-apply the firmware update (maybe they fixed the inability to apply firmware updates in the latest firmware?).