Andrej, Andrej Falout wrote:
> 1) tahoe cp -r ... is in that case not an option for any data that needs > to be secured. Does anyone have a suggesting of what to do so that all > files passed to tahoe client are allready encrypted? Yes, my duplicity tahoe backend [1] can do exactly that if you omit the "--no-encryption" option. > 2) I assume this will remove any chance of using rsync, Unison, or > simmilar to keep local disk and tahoe store in sync, and that the only > strategy for backups will be to do a full backup to a single encrypted > file, and then do differential backups? Which would mean that each file > that was changed will need to be uploaded completely, and not just the > parts that changed? And after restore, all files that where deleted sin > the meantime will reappear on restored file system? And files versioning > is out of the question? Shawn Wilden is currently working on a much better backup implementation which does versioning and much more. Have a look at this maling-list archives. However, the issue of giving your rootcap to allmydata.com is indeed important. According to this post [2] from Brian Warner, creating your own rootcap on the production grid is somewhat "supported" but I cannot find any official information about that. François [1] http://allmydata.org/pipermail/tahoe-dev/2008-November/000890.html [2] http://allmydata.org/pipermail/tahoe-dev/2008-November/000880.html _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
