Create simple, standard tools making the backup recovery system available to other applications

Registered by Dylan McCall on 2007-11-01

We should move towards an open-ended system to find, read and create backups. For example, a group of simple (GNU-esque) programs could respond to simple requests regarding the recovery of backups, instead of this being stuck to one central recovery tool.

For example, a group of simple (GNU-esque) programs could respond (without too much "magic") to requests regarding the recovery of backups, instead of this being stuck to one central recovery tool. They could individually say where a file may be backed up, what versions of that file may be available, whether that version of said file actually is available, and finally fetch a version of a file (restoring it to a position passed via the command line).

Granted, there isn't an immediately intuitive way (code-wise) to figure out what backups a file exists in and which they don't, but it could be fast enough to just jump through all of them in order; if someone is looking to recover data, he probably won't mind a few second's delay, as long as it works.

With standard tools available in this way, backups or recoveries can be done within many applications, such as F-Spot or Nautilus. In my opinion, that type of openness is key to having a successful backup solution. People don't like using the file systems that applications generate, but backup solutions tend to require them. If backups can be handled intuitively by the applications themselves, the file system can remain abstracted. (As far as I've seen, that is why drag and drop is good, for example: Instead of finding files, people are moving parts of applications).

There are many backup solutions in Linux, but what seems to be missing is a standard way of doing it that applications can safely utilize to achieve that magical undelete or undo function when chances seem grim. A good set of tools should abstract it enough that other backup systems can fill in the blanks, replacing those same tools, thus being implemented transparently across the desktop. The functionality offered here would be very healthy for the Linux desktop, as it has the potential to provide an unusally easy backup system (no need to navigate files; just tell the application to figure out its own darn file tree) accessible from many places on the desktop.
This is one area where I think every similar system goes for the same ultimate output, so it should be possible to have these simple tools working interchangeably.

I believe this would work best as individual applications or a shared library to avoid locking the system to any particular language. Since the function of each tool is quite simple and it would be good to have this available to scripts, the former seems a sensible choice.
The backup tools would need to be a dependency of NSsBackup's packages, so that other backup suites can easily replace them (no idea why they would, of course!) without breaking NSsBackup's functionality.

It would be necessary to have NSsBackup's own recovery tool using its own independent backup applications, since that would provide both a useful test-bed for the system and make the project more manageable with minimal code repetition.

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
None
Definition:
Discussion
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

Wattazoum : I love the idea, but it raises one question I had time ago (when working on a media center solution). We need to have a way for application or library to expose his functionalities to the whole desktop. A concept like a web service over the desktop. this solution should be Desktop Manager free. After getting to this point, we could then make NSsbackup expose backup and restore functionalities as a cross programming language API.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.