Before I left on vacation, I was using one of CBC‘s cast-off Power Macintoshes (grey G4 tower with 256 MB of RAM) as a build box for creating a MacPorts port of the AMANDA backup system. I tarred up the Portfile and associated patches and have them available – if anyone using a Mac wants to help me test them while I’m away from my regular computer, please drop me a line via the comments and I’ll send it to you!
While on the topic of tape hardware and backups… never mind my little DLT7000 drive at home. How do you back up a 4TB Titan NAS?
We bought one of these servers at work last year; we’re finally getting around to using it for something. Our current challenge is trying to figure out how to back up a 1TB Interwoven content store (we’ve just bought almost the entire product line from Interwoven) without IT screaming at us for taking up their entire tape rotation schedule. This is on top of having to back up a large MediaBin store as well.
I’ll be happy when the Titan is actually up and running, though. We’ve been having some problems getting the CIFS partitions running, because the Titan really needs an Active Directory server in order to enforce permissions, and all we have is a Windows NT 4 domain controller (think again about hacking it; it’s on an internal network). The problem is that we never originally intended the Titan to be used for Windows shares; the unit was purchased long before we decided to go with Interwoven on Windows entirely.
Interesting technical challenges abound…
After my girlfriend‘s Powerbook crashed, taking with it several months of her un-backed-up data, I decided enough was enough with my own antiquated backup hardware (ExaByte 8505 8mm tape drive, 5GB/10GB) and I bought a DLT7000 (35GB/70GB) drive off eBay, thus increasing my backup capability by seven times. With eight tapes, the whole adventure cost me approximately CAD$150.
I started thinking about what the purpose of hardware compression on tape drives is. In principle, it seems like it’s a good idea; offload compression, which is a CPU-intensive activity, onto the drive. The only problem is that it makes the estimation of whether or not a backup will fit onto a tape a virtual impossibility. I want to know, before I even start writing to the tape, whether or not a backup is going to fit. I don’t want to start writing to tape and then, 2 hours later, find I just hit End Of Media. It’s not something that you can recover from.
I don’t see a technical solution around this problem, so what I do is turn off hardware compression and just gzip the data to a holding disk. This is one of the great features of AMANDA; you can stage the entire backup to a temporary disk, and then write the backup to tape from that disk.
So, as far as I can tell, hardware compression is not very useful; it seems like a scenario where solving one technical problem (moving slow compression activities onto hardware) creates another (inability to know a priori if you’re going to run out of tape before you start writing the backup).
Finally got our piece-o’-shit Seagate DDS-4 tape drive back from the shop. The second time. My advice is to not buy DDS-4 drives; not just Seagate ones but any DDS-4 drives. Why? Even though the front says IBM or HP, the inside is still manufactured by Seagrate. The last FRU we got was an IBM brand drive, but reading the label carefully you discover that it’s still a Seagrate.
It’s at times like these that I wish the company had money to buy a decent tape library.