Offsite Backup
Rick contacted me recently to propose a mutually beneficially technical configuration: use one another's NSLU2 network storage devices as an offsite backup solution. That is, Rick will send his backups to me, and I'll send my backups to him. I've been exceedingly lax in my backup strategy of late, so this seemed like an excellent opportunity to remedy that situation.
I'm running Debian on my slug, and Rick is running Unslung. We created accounts for one another on our respective slugs, configured port forwarding on our firewalls, and yesterday I sat down with Rick to help him get ssh keys working for passwordless logins. Rick sent over a few dozen photos for storage on my slug, and it all worked perfectly.
When I got home, I set to configuring my backups. My goal was a little more complex, because I want to backup my web / mail server, in addition to my desktop data. I created a daily cron job on my server to dump all the MySQL databases, gzip compress them, and then encrypt them using GnuPG. The script first empties out my backup directory, removing any previous backups, and then dumps all of the above into the backup directory. I created a weekly cron job to archive all my users' mail spools, tar and gzip them, and finally encrypt them with GnuPG. Since the weekly cron task executes after the daily, the mail backups will coexist with the database backups for one day, and will be purged the following morning.
On my slug, I created a cron job to run at 8:15 AM every day (after both the normal daily and weekly tasks execute), in order to make sure that the web server had finished all of its archive tasks. The slug uses scp to grab *.gpg from the backup directory on the server, and stores them in the local backup directory. It then uses the find command to identify files in the backup directory that have not been modified in more than 30 days. These are deleted. Finally, the script invokes rsync to synchronize my slug's backup directory with the backup directory on Rick's slug. Files that were deleted on my slug (due to age) should be deleted from Rick's slug, and new files should be transferred over.
In this way, I have a month's worth of daily database backups, and weekly snapshots of mail, stored in my house, and also stored offsite at Rick's house. Everything is GPG encrypted, so if anyone robs my house (or Rick's house), I won't have to worry too much about any sensitive data that might be contained in the database dumps or in email messages.
While preparing these backup scripts, I was reminded of OfflineIMAP, a utility used to synchronize IMAP folders between multiple computers. It's a pretty interesting package, and it might be a great way to keep more frequent backups of all the mail on my server. I don't know if it offers anything unique over just a plain ol' rsync of my server's maildir, but it's another tool in the toolbox. One of the neat tricks you can do with OfflineIMAP is to use ssh to prepare a "preauth tunnel", so that you don't need to use your IMAP password at all (relying instead on key-based ssh logins) -- that's pretty clever! I am, however, a little leery about keeping an unencrypted copy of all our mail on the slug locally, but I can't adequately articulate why: if it's acceptable to keep the mail on the VPS, on hardware outside my physical control, why should I be worried about a duplicate copy stored on a hard drive in my house? If you're using OfflineIMAP, do please let me know what you think in the comments.
What backup strategies are you using? How have they worked for you so far?
A Little DAAP Will Do Ya
I've been eyeing the Linksys NSLU2 for a little while, contemplating its use as a file server for the house. I'm attracted to the (extremely!) small form factor, the low power consumption, and the fact that Debian is fully supported on it (see Debian on the Linksys NSLU2). I'm not keen on actually buying it, though, especially since I still own a Shuttle XPS small form factor PC. I'm also worried that the NSLU2 will ultimately prove to be underpowered for my goals.
I want a low-profile file server for two basic reasons:
- I want to be able to keep convenient, centralized backups of the various computers in the house
- I want a repository of music files accessible to all computers in the house
The MVix MX-760HD can play music files but its support for playlists is extremely lacking, and it doesn't expose the collection of music to other devices on the network. So I want to move all the music from the MVix to somewhere else. The MVix could still access the music from the network server, though I doubt I'd use it much for audio playback. (Incidentally, I'm still delighted with the MVix: it's been a great addition to our entertainment center: not having to shuffle DVDs to watch some of our favorite programming is a real treat.)
Having the music files in a central location is only one piece of the solution, though. I'd like to allow all our laptops to listen to different playlists in different rooms at the same time. I suppose we could all mount a network share, and simply have our local music clients parse the share contents. That's not quite the solution I'd like to pursue, though.
I looked at the SlimServer, the script that powers the Slim Devices product line. It looks neat, and should be easy to use. There is documentation for the SlimServer on the OpenSlug firmware, so it ought to work on Debian-on-NSLU2 just as well. The comments on that page, and in some Google searches for "nslu2 slimserver" made me a little concerned about whether the NSLU2 would be up to the task of serving media. We have 8000+ MP3 files, with more CDs yet to rip. A slow media solution is probably worse than the current configuration.
A little more investigation suggested a DAAP solution, the protocol used by iTunes. There is a iTunes Server for NSLU2, which uses the mt-daap package. There is a mt-daapd package for Debian, and I quickly found a Linux.com article about mt-daapd. Since Carina has been using iTunes of late to manage and play her media, the mt-daapd solution seemed like a good choice: she could move all her media to the file server, and continue to access all of it through her preferred client. I was pleased to learn that RhythmBox, the default GNOME media player, supports DAAP, too!
So last night I installed Debian Etch onto my Shuttle XPS. I executed apt-get install mt-daapd, and was quite surprised to see "Shuttle" show up in the sidebar of RhythmBox! I moved the collection of music from the MVix to the Shuttle, and restarted the mt-daapd process, which triggered it to re-index the music collection. This took several minutes on the Shuttle -- I can only imagine it would take considerably longer on the NSLU2. Clicking "Shuttle" in my RhythmBox client showed me that more than 8,000 songs were available!
I think my worries about the speed of the NSLU2 are largely misplaced: (re-)indexing the music collection isn't an everyday occurrence, so it's not something that will hamper every day music playing. If you're using the NSLU2 with mt-daapd, do please share your experiences!
