I now know that in order to get automated offsite backups from my NSLU2 to Amazon S3, I have to get it to run Ruby so that it can run s3sync. I want to back everything up first, which is going to take some time -- so while that's happening, I'll get both Ruby and s3sync installed on an Ubuntu Linux machine as a dry run.
As I noted earlier, the standard firmware will not support Ruby, so the first step is going to have to be to install new firmware. The matrix of possibilities on the NSLU2-Linux site lists a bunch. My gut instinct is to stay as close to the original firmware -- to the left of the matrix -- as possible. I've been using Linux for a long time now - on and off since 1992 -- but I've never really got to a serious kernel-recompiling porting-it-to-a-ZX81 level with it. So let's keep things as simple as possible.
I am trying to get my NSLU2 to back itself up automatically to Amazon S3. I currently know that in order to get this to work, the "slug" (as it's affectionally known) will need to be upgraded with new firmware -- basically, a new version of Linux. Just which of the many competing firmwares is appropriate will depend on the software I use to do the sync, and so it's time to work through the various options presented in Jeremy Zawodny's post and the comments people have left there.
I am trying to get my NSLU2 to back itself up automatically to Amazon S3. At the end of the last post, I noted that the device would need new software to make it do so; and while it's Linux-based, it's really not designed to be extended like this. Time to go online.
Previously in this series: Part 1.
In the last post, I explained that I was going to work out some way of getting an NSLU2 backed up to some kind of offsite data storage without any intervention from a fully-fledged computer.
Let's look at the easy bit first; how do I get some cheap storage online? Sadly, Google has yet to announce its 100Gb free GDrive, so for now I'm going to assume that I will use the Amazon Simple Storage Service, widely known as S3; this is cheap -- from their webpage,
- Pay only for what you use. There is no minimum fee, and no start-up cost.
- $0.15 per GB-Month of storage used.
- $0.20 per GB of data transferred.
It's also meant to be highly reliable; Amazon use it themselves internally, so presumably it's at least good enough to store the mission-critical data of a multi-billion dollar business. My data will probably be safe enough.
So that's the storage - next, how do I get it there? This is likely to be harder. Although - as I noted in my first post in this series -- the NSLU2 has an automated backup feature, it's really designed to allow the device to back itself up to a drive shared by another machine on the same LAN, or to allow it to back up directories shared by other machines. Useful for protecting yourself against disk failure, useless for protecting against burglars.
So, getting this working will require getting the NSLU2 to do something it was never designed for. This would be a daunting task, but conveniently, the NSLU2 uses a cut-down version of Linux -- and while the manufacturer does not support any kind of modification, a few Google searches suggest that there's an active community of people devoted to hacking it into doing things it's not designed for.
I can now refine the aims of this project; initially I wanted to get an NSLU2 to back itself up to some offsite system. I now know that I want to somehow persuade the NSLU2 to run non-standard software that synchronises its contents with Amazon S3.
Next: Hacking the NSLU2
I have a Linksys NSLU2 on my home network, and I'm very pleased with it. It is almost silent, was not too tricky to set up, cost very little (and is even cheaper on Dabs these days), and it happily serves the contents of a 200Gb USB-connected hard disk to all of my PCs. But there's one problem; it would be easy for someone to steal. I was burgled a couple of years back, and while (thankfully) they missed the disk, I realised that while almost everything else in my flat is insured and replaceable, the data on that drive is not. I decided that I needed it backed up offsite automatically, so that even if my home was completely cleared out, my data at least would be safe.1
Shortly after the burglary, I set up a temporary solution, which - like all these things - has lasted for somewhat longer than intended. My media-centre PC is always on, and it runs IBackup, which synchronises the contents of the NSLU2 (mapped as several network drives) every night.
This approach has three problems:
- Cost of the service. IBackup charge $10/mo per 5Gb, which isn't bad by the standards of their competition, but is more than I really want to spend - especially given that my usage is getting pretty much near that 5Gb limit now. Costs go up in 5Gb increments.
- Cost of electricity. Leaving a PC on all the time costs more than you'd think. Our electricity bill at work comes to something like GBP 7 -- say, $12 -- per computer per month; domestic electricity is a bit cheaper, but that's still about as expensive as the storage. I don't know what the NSLU2's power requirements are precisely, but it's probably safe to say that it uses less than a full PC... (Update - It looks like it uses about 2.5W - see the table at the bottom of this page -- which is a couple of percent of a PC's power consumption.)
- Elegance. There's just something fundamentally wrong with getting a clever little NAS device to handle all of your shared disk space and then keeping a fully-blown PC running just so that the NAS disks are backed up. The server should handle its own backups - otherwise you might as well just share space out from the PC.
So, I need something better - cheaper, more power-efficient, and more elegant. Here's the plan: I want to find a decent supplier of offsite backup space, and to somehow put in place software to keep the contents of the NSLU2 synchronised with that space. I suspect getting this all sorted may take a while, and I'll keep detailed notes here.
Next: Where and how?
The NSLU2 does have the ability to automatically back itself up to another network drive - presumably it accesses the other drive using the same Windows SMB protocol it uses to share its own disks. If I wasn't looking for offsite backup specifically, this would have been quite useful -- good enough, at least, to protect against hard disk failures. ↩
I knew that these odd random colon-separated thingies in my
IPv6 addresses of some sort, but it was good to find something that
explains them clearly
(update: link now sadly dead).
This is a new technical blog to replace the personal/political blog I've been keeping for a while - which latter shall remain nameless... A fresh start -- somewhere to keep "lab notes" as I play with the various techie toys I have at home, to store links to sites and articles I find interesting, and perhaps somewhere to sound off about tech-related ideas coming from work. I think it'll be fun.