Shawn Willden wrote: > There is another possible issue, a serious one. If the file changes between > the calculation of the rdiff signature and generation of the delta the chain > of forward deltas will be broken. To avoid that, the uploader will check the > In my own case, I can guarantee a frozen filesystem for you to back up because my files are under ZFS. Obviously not everyone can make such a snapshot, so your algorithm is still valuable.
> I'm still thinking about how to structure the directories into which all this > stuff gets uploaded. I think it'll probably be a single tree structure that > mirrors the backed-up filesystem structure, but each file will become a > subdirectory, into which the original plus deltas will be placed. The > backupdb and its deltas will go just above the three. Oh, and all of the > various uploads mentioned are immutable. > > The downside of using forward deltas is that you have to have all of them, in > a complete unbroken chain, in order to get from the original to any other > version including the most recent. This means that the longer the chain of > Even worse, I can't share my files by giving people tahoe readcaps! That was going to be the big bonus of using tahoe for backup, for me. For discussion purposes, here are some other layouts that store the current version intact: Whole-file history tree: current/a/b/c.txt (a link to version2, perhaps?) history/a/b/c.txt/version1 history/a/b/c.txt/version2 Reverse deltas tree: current/a/b/c.txt history/a/b/c.txt/delta1 history/a/b/c.txt/delta2 _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
