My very naïve suggestions: keep the current backup version just like it is now on the backup volume, but also store in a separate place reverse deltas for each file and the metadata necessary for enumerating, reconstructing and verifying file versions.

In other words, no more than that actually needed for the task. What I would expect from Alex (if I understand his mode of development rightly) is for him to exploit the delta versioning code he has already created and knows inside-out to the more complex task of keeping multiple versions of a file in a space/time efficient format on the backup volume, while making it easy for the user to extract earlier versions when needed. It's almost as if Alex wanted to be permanently subject to headaches and possible episodes of insanity. In that light, while file versioning is certainly something I'd like to see, I just cannot understand the desire to adapt something as complex as the 3rd party Git version management libraries: Git's versioning is made for a whole other order of versioning complexity and strategies. This backup software does exactly one thing extremely and reliably, namely: keep an easily accessible, reliable copy of important files on a separate disk, and do it in the most efficient way possible once the initial copy has been made. Mar 12, 2014New user here (Beta 63), and what chiefly impresses me about Alex's work is the dedication to the 'keep it simple (but not more simple than it needs to be)' principles.

Does dropbox support btrfs