k wrote:

Backup software is hard and thankless. A sizable minority has bad ideas about how backup does/should work, and what their real needs are.

Backup software is an organization’s software-quality acid test. For Apple’s software spread, I would place it only after the file system and Core Data in the ranking of software that absolutely, positively must-work. It requires an engineering backbone of steel, sometimes even saying “no” to data-compromising requests from users, upper-management and marketing.

Interesting article and some of the discussion found on the links is good too. It's made me rethink my use of Backup.

Somewhere in my reading, someone said something like "version control for all files is completely absurd", but I don't understand that. I admit there would be complexity in the UI, but I don't know that it'd be insurmountable. I'm damn near the camp that feels that every single file modification should be transparently and automatically versioned. If I hit "Save" it saves a version. I'm not thinking logistically at this stage... certainly I don't want a Documents folder with 10000000 files in it. But I wouldn't mind being able to control click a file and select "Show versions..." and be presented with a comprehensive list of every mod to that doc, with the ability to diff two or 3 versions.

What I *dont* want is to have to maintain CVS or Subversion and manually issue checkin and checkout commands. Could I run Subversion on my Documents folder? Sure, but it'd be annoying. I want something that abstracts that all away from me. Given that what I describe above is the special case of a version control scenarion in which only one user is modifying files -- e.g. the visible copy is *always* the working copy, so i never have to do a checkout or update -- I don't think it'd be so bloody hard.

The biggest hole I can poke in my own scheme is that to make it storage efficient you'd wanna store diffs, which is a pain to restore, more complicated (esp. on binary files).

I also recognize that this isn't yet a "backup" since it's all on one disk. However, if this scheme is implemented then the backup becomes an rsync since every concieveable version is already captured. Possible ways to reduce storage concerns would be to limit the number of versions stored locally... e.g. versions from the last 2 backup cycles are kept on disk... if you need anything from before that, it's on the backup disk.

I'm just thinking out loud here.

Well, Subersion with Berkley DB is pretty painless. You can have it version certain directories in the filesystem, and there is no manual checking in/checking out. All saves on a document get checked in. And you never have to bother fooling with svn until you want an old version. Its not as integrated with your office apps as is desireable when you have to do that (not at all), but in terms of using it as backup this works quite well. Do regular backups of your svn repository and you've got a pretty seamless setup.

But yeah, this should all be setup for you in a little binary that you download where Subversion or something like it is already setup this way and the only arguements you have to feed it are which directories to version.