13 Feb 2009
TimeVaultNG Structure Document (Draft)
Backups are crucial. If we all know that, then why do few people have a complete and tested backup system? Some people even fail to have any backups at all. A huge part of this has to do with simplicity. Backups need to be easy to set up, painless to maintain, and to work when you need them. This isn’t an easy task, and so far I haven’t seen a good solution for end users on Linux. For the moment, I’m backing up my drives using some scripting foo and the great (command line) utility rdiff-backup. Late last year I played around with a KDE frontend to rdiff-backup, but it was overly complex and ended up not going anywhere. With the results of that in mind, and some helpful discussion with others via email, I’ve come up with a list of qualities and abilities that I think are needed in a good desktop and end user backup system. This can also be considered a draft of a design document for TimeVaultNG, currently hosted at http://launchpad.net/timevaultng
Timevault should provide the following:
1. A single (rdiff-)backup for the entire filesystem. The partition state is saved so that it can be restored if the (advanced) user desires to, but it also supports (and possibly defaults to) just restoring to a single partition.
2. A backup daemon that runs as root/trusted user that does the backups and communicates (via DBus) with…
3. A KDE frontend (and possibly others) to manage where to backup, exclude lists, etc… This frontend has a very simple initial backup setup which consists only of selecting the backup drive and clicking enable. From there the daemon backups up on (for now hourly) interval whenever the backup drive is plugged in.
4. A set of “exclude plugins” which exclude specific parts of the system. For example, there could be an exclude plugin that does not save any of the Firefox cache. Application developers/system integrators could provide other exclude plugins depending on their setup.
5. A restoration utility that is provided on a livecd (and can also be included on a distribution’s livecd) that can restore in the following manner:
a. It wipes the target disk/partition
b. It (optionally) recreates the partition scheme
c. It (optionally) installs the base operating system
d. It installs the backup overlay on top of the disk
e. It ensures that the system is bootable (i.e. fstab matches partition layout, that initrd is correct, that grub is installed)
6. A utility (possibly built on top of dolphin) that lets users browse snapshots. They can see the current version of a directory and then “travel back” to see earlier version. This could be implemented in a kioslave which would allow any KDE application to directly access the (read only) backups.