Ubuntu Wiki

• Launchpad Entry: Safehouse

• Packages affected:

Summary

Safehouse provides users with an automated backup system that can be stored locally as well as copied remotely. This will allow users to quickly roll back to recover deleted, over-written, or corrupted files.

Rationale

Microsoft Windows has "System Recovery" and Apple OSX has "Time Machine", it is time for Linux to step up to the plate. Thanks to many high quality SCM packages (git, bzr, hg,...) this project should be trivial to implement.

Use Cases

• Billy just stayed up all night making last minute adjustments on his thesis when the power dies and his file becomes corrupted.
• John is quickly cleaning up tests results on his project and types rm -rf tests/ * instead of rm -rf tests/*

Assumptions

• The user will not bother with any advanced SCM functions (merge, branch, etc...) only add, delete, and move.
• Safehouse will archive all files except for swap files, trash files, core dumps, or system backups. Should the users really need to specify they don't want to backup?

Design

Below are the separate entities of the total project:

Preference Editor

This will be a simply GTK application that will configure settings per user. Settings will be stored in the root of the users home directory in a file named .safehouse. This program will simply manage the settings store in the file which will be read in by the main program. Currently, the following settings will be stored:

• SCM type (svn, git, bzr,...), this will default to bzr
• Backup server (optional): hostname and username (user may need to set up ssh keys instead of storing a password)
• When to backup
• Possibly files to exclude?
• Possibly backup size limit?

This will be implemented in python.

Nautilus Extension

I believe that I can reuse a great deal of code available from the nautilus plugin of the bzr-gtk project. I believe that adding a new context menu for safehouse that when accessed presents the user with a calendar to choose a date to roll back to (very much in the same way as System Restore on Windows XP).

This will be implemented in python.

Generic SCM Backend

For now I will use the bazaar version control system. After I have successfully created a system that works sufficiently, I will work on creating an abstraction layer so that users have a choice of SCM for their backup system. After completion, this middle-ware can potentially be used for further programs to easily use any SCM.

This will be implemented in python using current libraries when implemented (i.e. bzrlib) and interacting with native binaries when not (i.e. pycvs)

Main Driver/ Daemon

This should be trivial to write after having the generic SCM backend. Basically it will need bindings for rolling back and committing changes. I currently believe that the best method is having the program run as a daemon (which can be added as system service) and will check/commit at a set time (ideally once a day, however this can be controlled via user preferences).

This will be implemented in python.

User Interface Changes

A plugin should be added to the Nautilus file manager to allow users to roll back in time. This could be implemented as a new context menu item that presents the user with a calendar of all available revisions of the selected node. This will then work with the SCM backend to perform rolling back.

Discussion

• Comments welcome

• Presenting it as "a new context menu item", and just in Nautilus rather than in the applications you're actually making the changes in, would likely mean few people would ever find it and benefit from it. And presenting the versions as a calendar, rather than as the actual data with a slider, would make it unnecessarily difficult to tell which date had the version you wanted. The Mac OS X presentation is much more discoverable, but it is also piling on complication to the 1980s GUI framework: use "Edit" > "Undo" to step back through the current session, use "File" > "Revert" to jump back to the last save, use Time Machine to jump back through previous saved versions. A better interface would combine these commands into one. -- MatthewPaulThomas

CategorySpec