Backing up the file system solves the wrong problem. The real problem is that applications (for example, VMs and databases) don't automatically map onto the fil

Backing up the file system solves the wrong problem. The real problem is that applications (for example, VMs and databases) don't automatically map onto the file system, and even sophisticated users (even sophisticated ones like the Jeff Atwood) don't find this very easy. I can see 3 ways around this: - Applications could register with the back-up utility, so bup (for example) knows to get a hotcopy from the svn repository and a dump from the database. - Applications could be told to dump to a specific locations on the file system on a regular basis. - Unix magic could be used, so reading from certain parts of the file system would trigger a dump from the appropriate applications. I'm not quite sure if this is possible (I'm a Unix weenie). I don't care is best (they would all work). The real solution would have the following features: - Automated nags (SVN-style) about dirty looking locations. - A white-list of locations to suppress nags on (the same way SVN can be set to ignore the /bin directory, and the .pyc files). - A way to resolve the nags (i.e. telling the backup server what commands to run in order to backup certain applications). - A file format for backup hints (left in a hidden file called .bup in the program's main directory), so applications could automatically tell give hints to the backup program on how to get them to dump. A nice GUI that auto-suggests backp-up commands (with shell integration like tortise-SVN) would be cool, but not essential. I've tried to use "applications" consistently in the post. It could mean a database, a repo, website server, or anything. As long as the "application" has some sane way to be back-up up. And yes, I do know that talk is cheap.