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.
[...] Chatonka « TimeVaultNG Structure Document (Draft) [...]
Chatonka » Blog Archive » And sometimes it’s not my bug
February 18th, 2009 at 5:44 pmpermalink
Hi,
I think a lot of the ideas you describe are excellent and I feel that a user-friendly backup tool for KDE would be a tremendous addition. I thought I would just mention one previous effort (now defunct?) led by Ivan Cukic, which was focused more on backing up and porting application configurations: Kamion. You might find some of the ideas from this project interesting.
http://kamion2.sourceforge.net/
Alex
February 18th, 2009 at 6:14 pmpermalink
Are you planning to support only backups of entire disks or entire partitions or maybe also selected folders?
Bruno Bigras
February 18th, 2009 at 9:32 pmpermalink
I see that your planning on using rdiff-backup.
Is there a reason for abandoning the snapshot-based architecture used in timevault?
David Mills
February 19th, 2009 at 1:43 ampermalink
OK, Just seen your post from a while back.
I’m not sure if the awnser isn’t to do what apple did and insert directory hard links with recursion detection into the fs layer though.
David Mills
February 19th, 2009 at 4:10 ampermalink
Sounds like a great idea, I’d love a tool like this!
Mike Arthur
February 19th, 2009 at 6:45 ampermalink
@David
Yes, it would be nice to have some core features at the fs layer. Something similar to zfs or btfs would be the best in my opinion, but both of those are not an option on linux in the near future. And 2 benefits of rdiff-backup (over HFS+) are that it works on any filesystem and that it only saves binary deltas rather than complete files when something changes, therefore saving a lot of space if a small portion of a 10gb file changes.
@Bruno
Right now the prototype daemon I have does support changing the root of the backup, as well as specifying include and exclude folders, so yes. However, it would not be in the simple interface, it would require some navigation into an advanced mode.
@Alex
Looks interesting, I hadn’t heard of that project before. You’re right, it seems to be more focused on backing up settings for migration. While that has its place, I don’t think that’s what TimeVault should strive to be.
astromme
February 19th, 2009 at 8:01 ampermalink
another similar application also covering the backup problem: http://backintime.le-web.org/category/news/
Dominik
April 29th, 2009 at 6:44 pmpermalink