Diary of a geek

August 2008
Mon Tue Wed Thu Fri Sat Sun
       
11

Andrew Pollock

Categories

Other people's blogs

Subscribe

RSS feed

Contact me

JavaScript required


Monday, 11 August 2008

Amanda, tar, and Debian Etch

Somehow (thankfully) I've managed to avoid much to do with backups in my career as a sysadmin. It's always been someone else's responsibility, that's been fine by me.

For some reason, I've been more paranoid lately, and with all of the crazy shit I've been doing to daedalus, I wanted to have a backup, just in case. Maybe it's old age.

So a while ago, I went and had a stab at setting up Amanda, since pretty much whenever I've been near a bunch of sysadmins and someone asks for a recommendation on what to use, "Amanda" is the answer.

I jumped through all of the hoops to have caesar be the backup server, and daedalus be a client. I set up a virtual tape library on caesar. I think I then lost interest for a while, until I was going to upgrade daedalus to Etch, and I wanted to have a successful backup first.

I had the holding disk and the virtual tape library on the same filesystem, and it was nice and big, yet I kept running into this error about insufficient space. "dump larger than available tape space" was the complaint.

I tried making the filesystem larger. I tried adding more virtual tapes. Nothing would placate it. After another round of Googling, I discovered that the problem was because Amanda would only only span a maximum of four tapes, and the filesystem I was trying to backup was way bigger than that. So I told it to use up to 10 tapes in a run (runtapes 10) and then lo and behold, I got a successful backup out of the sucker.

So that was mostly all good, but occasionally a backup would fail, or fail once an succeed on a retry, because tar exited non-zero, with "file changed as we read it". I did some more Googling tonight, and discovered this Amanda/GNU tar compatibility matrix.

It turns out that the version of tar and the version of Amanda shipped in Debian Etch aren't compatible with each other. Suck! Oh wait, they're maintained by the same person! Argh!

So aside from the occasional backup failing due to a file being written to at the time of the backup, it's working fairly well. My DSL link isn't the fastest, so a full backup of daedalus can take over 48 hours to complete, but I'm not paying for inbound bandwidth at home, so it's not a big deal.

I initially thought that to do a restore, I'd have to run amrecover on daedalus, and then I'd have to stream the contents of multiple tapes back to it at the appalling uplink speed of my DSL connection, but fortunately amrecover has a sethost command, so I can restore just the files I need on another machine local to caesar at LAN speeds, and just transfer the files I restore to daedalus. So that's all pretty neat.

I quite like the FTP-client-like interface of amrecover. It's cool how you can use setdate and just go back in time.

I had the opportunity to do a test restore recently when one of my users nuked his Maildir directory by accident. Unfortunately I was unable to recover the needed files in that case, and I'm not entirely sure what the problem was, so there's some more testing to be done before I'll be fully confident that I can rely on it.

There's a lot of configuration options available as well, and I think I got the config I'm currently using from a template or something, so there's probably a fair bit of tweaking I can do.

Oh, and I'm constantly reminded of this quote from a previous life, where technical details bubbled too far up non-technical management:

"Who is Amanda, and what is her role in the backups?"

[22:59] [tech] [permalink]

QoTD: You know the bar's been lowered when you're excited about being able to install packages like less

Spoken by a co-worker, fighting with nano, when all he wanted was less to browse the installer log to diagnose why an installation with d-i failed.

[11:20] [debian] [permalink]