Ubuntu Wiki

Current Methodology

Currently, there is one snapshot for the entire filesystem at a time. This is handled by rsync'ing to a current-snapshot directory and then hard-linking to an appropriate timestamp directory. If a file has changed, it is deleted from the current-snapshots, but a link remains in each snapshot that was taken during the file's existence. The allows for simple, relatively efficient versioning.

Problems

Every time a snapshot is taken, a copy command has to be executed to duplicate the current-snapshot directory to the appropriate timestamp. Depending on the number of files and directories, this can take some time (on the order of seconds, usually). During this time, the machine is less responsive.

Another problem is that each directory in the new folder must actually be created and cannot be linked, taking a block in the filesystem. For filesystems which use 4KB blocks, a 1000 folder backup will waste 4MB each time. This may be acceptable if the frequency is low enough (say, once a day), however it won't work well if more frequent snapshots are taken (for example, every hour, or each time a file is changed).

Proposed Solution

Record deltas by themselves (i.e. without copying the whole current-snapshot directory).

Event-driven Versions

A snapshot delay is set for each directory to be watched (say, 1 min.). When a file changes in that directory, a snapshot is taken after the configured delay time. If the file changes before the snapshot is taken, then the timer is reset repeatedly until you're done fiddling with the file, or some other specified time runs out (say, 60 min.) and a snapshot is forced. This mini-snapshot is called a delta. It only involves the file in question and so should be relatively fast (my benchmarks put it at around 50-150ms for a 1MB file, less for smaller files), and can be done in the background.

So, if we discover, through using the inotify feature in current kernels, that some files have changed in /etc/apache2, we rsync them to the current-snapshot, and then proceed to copy only those files into the correct location of the current timestamp we've just created.

For this methodology to be possible, a server process has to be running, which monitors files using the inotify interface. Clients can interact with the TimeVault server through DBus and subscribe to signals to monitor things like when a file timer starts or a snapshot is taken. They can also request a snapshot image for some time in the past.

User Interaction with a Snapshot

Will post some screenshots soon; for now, try here: http://ubuntuforums.org/showpost.php?p=2945524&postcount=108

Completed

• Notifier

• FileWatcher

• DBusServer

• MsgHandler

• ConfigFile

• Snapshotter

• SnapshotPicker

• GUI Configurator

• Install Scripts (+.deb)

• TimeVault

• Nautilus

To Do

• TimeVault: Automatically clean out old snapshots

• TimeVault: Dump pending snapshots so they can be resumed on restart

• Notifier: Allow a mechanism to flush snapshot queues
• Notifier: Provide a timeline of upcoming snapshots in the tooltip

Interaction Diagram