emacsen's journal - My ideal backup solution
[Recent Entries][Archive][Friends][User Info]
|
06:28 am
[Link] |
My ideal backup solution
This is in response to ressu's post about backup software. The answer to the question is that No backup software is the best backup software and we should aspire to get rid of all backup software.
Really, there are three reasons to do backups. The first reason is when you screw up. You say "Ooops", and you wish you could undo an action. The second is when you're preparing for hardware failure, and the third is when you need to archive the state of some data as it was at a certain time.
Since the original discussion was about PC backups, let's put the third issue aside and focus on the first two.
Ideally, we want to be able to do a rollback to a known good state. In the case of the "Ooops" scenario, that's right before the mistake was made. In the case of the hardware loss or failure, it's the last time the system was able to backup successfully.
But instead of using backup software, I see this as a core OS function. The OS should be able to do some kind of snapshotting. Right now ZFS has the best constant snapshotting system. In ZFS, I can mount a directory as it appeared a few minutes ago, or if the space allows, a week ago. Similar functionality exists in ext3cow.
That takes care of my "ooops" issues, since it's my experience that most of those problems arise within the first 5 minutes of the mistake.
Once the host which is taking the snapshots is connected to the network, it could connect to the backup server and transmit those snapshots to it. In the case of ZFS, it could reply the logs to the server. In the case of another filesystem, the snapshots could be rsynced.
In the case of the backup server being unavailable or space filling up, the backup client could be intelligent about which snapshots it keeps, probably using a logarithmic algorithm (keeping every 5 minutes for the first hour, keeping every hour for the first day, and then keeping every day up until a week, etc. If the backup server has lots of space, it could keep many snapshots indefinitely, and if space becomes tight, it could use a similar algorithm to recover space.
To allow for backups to be as simple as possible, I'd envision backups offered on the network to be a ZeroConf service. A host with the ability to be a backup client looks for a backup server on the network. If it finds one, it checks a cryptographic signature against a list of known signatures, or asks the user if they trust the backup server, similarly to how SSH does a key exchange during the first session. Then with NetworkManager, when the host goes on the right network, it can opportunistically try to connect to the backup server.
During a restore, the user would be presented with any snapshots available on the local system, as well as any available from remote resources if they're available.
Of course the real question is why do we need any of this backup stuff at all? Why can't we do like Linus says and upload all our data to an FTP server?
After all, all this constant snapshotting and "diff"ing above sounds a heck of a lot like a distributed version control system. Then I could simply tie my filesystems together, synchronizing them as needed. So, going back to ZeroConf and NetworkManager, when two hosts that belong to me see each other, they would begin to synchronize their filesystems. If one of them had more space than the other, say a desktop vs a laptop, it could even be used as a backup server, storing older versions of the laptop's backups. Second class devices like cell phones could use a system like Conduit to synchronize the data.
This is my ideal PC backup solution.
Tags: computers
|
|
| |
| | From: | ![[info]](http://l-stat.livejournal.com/img/userinfo.gif) emacsen |
|---|
| Date: | June 13th, 2007 10:33 am (UTC) |
|---|
| | | (Link) |
|
|
|
