Eric, Sorry for the slow response.
On Tue, 2007-12-25 at 11:18 -0500, Eric S. Johansson wrote: > as for encryption, I think it would be possible (assuming mods to rsync) to > do > rsync encrypted copies. if you assume symmetrical encryption and that the > key > and plaintext is managed by one side, specified by command line args, it > becomes easier (not easy, only easier :-) > > [[ related thought. if rsync had a plugin architecture allowing per file > transformation (pre and post transfer) one could build encryption in as an > addon]] There is an experimental branch "source-filter_dest-filter" of rsync that supports such transformation: http://gitweb.samba.org/?p=rsync.git;a=shortlog;h=patch/source-filter_dest-filter > the idea of the encryption extension is that when a file is ready for block > by > block checking, it is copied (replicating TOP (time, ownership and > permissions) > and encrypted using the given symmetrical key. this should yield an > identical > file if they are the same. if you get the key wrong, tough noogies, you copy > your entire dataset. Yes, encryption done with --source-filter would work essentially that way. The downside compared to something like duplicity is that the backup host gets to see everything except the file data (i.e., file names, sizes, times, and attributes) and, unless you take additional precautions, can manipulate the stored data by mixing and matching different encrypted versions of files. > rsync/snapshot to trusted host and backing up encfs image of backup directory > may be a better solution Well, if you have the Linux intermediary that would be necessary for EncFS, you might prefer duplicity instead. > so matt, lets go for the rsnapshot push to a benign host for now. OK, I will address this soon... Matt -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
