Pushing hard-linked backups

Matt McCutchen matt at mattmccutchen.net
Sat Dec 29 23:42:07 GMT 2007


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



More information about the rsync mailing list