Would this plugin be possible? (Bucket style Glacier-system)

Status
Not open for further replies.

tofagerl

Contributor
Joined
Aug 26, 2013
Messages
118
So we've all heard of AWS, and most of us have even heard of Glacier. Well, I love Glacier. I'm currently hosting 53gb worth of Aperture backups, and I pay 59 US cents a month for that. Well, Aperture is going away, so I am in the middle of converting all my files to Lightroom. Not a huge problem, though it does take time to upload and verify the tarballs. So for the last week I've been thinking of a plugin that would automate this, and do it very simply.

Basically it would consist of two folders visible to the user, and one config file (placed in one of the folders) which contains all the settings, such as AWS keys, email address in case of errors, how often you want the backup to be run, how large the tarballs should be and so forth and so on.

The automation would then take each subfolder in the first folder, run an initial tarball-backup of that, and place it in the second folder, where it would start uploading it to Glacier, and run verification on each tarball afterwards. (Glacier uses treehash for easy verification, the ruby script I'm using is here: https://rubygems.org/gems/treehash.)
The tricky part comes when the content in the first subfolder changes. The example I'm toying with in my head is a Time Machine backup which gets run every hour from the users machine, but only gets uploaded to Glacier once a day. The backup from FreeNAS to Glacier would have to be differential instead of incremental, which means that there would be one new tarball every day for each subfolder.

The end result would be that the user would have one easy-to-get backup on their FreeNAS, and in case of fire and/or hardware problems one hard-to-get but still cheap backup online.

And no, I have no easy way to get that second backup down, but I would presume a non-FreeNAS solution would be best. For example, a guide for Windows, Mac and Linux with links to scripts and tools to just dump that backup (de-tarballed) into a chosen folder.

Negatives:
1. Each backup would take double the space on the FreeNAS due to both a normal backup and a tarball existing at the same time.
2. Not the easiest backup solution for the user, but we're talking about FreeNAS users here, not your grandmother. (who I'm sure is a lovely lady)
3. Possibly overengineered...?

Anyway, comments wanted. I'm pretty sure I could put this together in Python, but I would love input on the idea and help with the implementation if the idea is considered good enough.
 

tofagerl

Contributor
Joined
Aug 26, 2013
Messages
118
Sure, that's just a matter of piping. The problem comes with Glaciers price structure, which is heavily biased in favor of few large files instead of many small files. Thus the tarballs.
 

Joshua Parker Ruehlig

Hall of Famer
Joined
Dec 5, 2011
Messages
5,949
Sure, that's just a matter of piping. The problem comes with Glaciers price structure, which is heavily biased in favor of few large files instead of many small files. Thus the tarballs.
A snapshot is a single stream of an entire dataset(s). This is one "file".
 

tofagerl

Contributor
Joined
Aug 26, 2013
Messages
118
OK, but that means that the user wouldn't be able to restore to any other filesystem. And that's a big catch for something that adds no useful feature.
 

Joshua Parker Ruehlig

Hall of Famer
Joined
Dec 5, 2011
Messages
5,949
OK, but that means that the user wouldn't be able to restore to any other filesystem. And that's a big catch for something that adds no useful feature.
There's filesystems other than ZFS?! ;)

True, ZFS send/recv isn't flexible, but I just wanted to point out that your previous point was irrelevant.
 

tofagerl

Contributor
Joined
Aug 26, 2013
Messages
118
No good ones, but if your FreeNAS server is broken, you're going to want to use your desktop or laptop to get your files back.
 
Status
Not open for further replies.
Top