crypting remote data

[Matt McCutchen]

On Sat, 2008-03-08 at 18:33 +0100, david reinares wrote:
> rsyncrypto looks fine, but still not which we're looking for.
> 
> Having a complete file updated if a little change happens doesn't
> bother me. We're performing daily rsync, so not many files can be
> changed in a day.
> 
> The real problem is about space and performance. If you want good
> performance yo have to sacrifice space, and vice versa.
> 
> We decided to save space for client. so we copy file by file, crypt
> it, rsync it, and then delete...a hell for performance, starting a
> rsync connection for each file.
> And worst of all, we loose -b functionality, that was really good
> (having not just a copy of the day before but an extra day)...having a
> previous version of destination data 
> in a file by file basis is not a god idea.

I don't understand what problem you are having with -b; could you please
clarify?  Suffixed backups should work exactly the same way when
rsyncing one file at a time as they did when you rsynced all the files
at once.  The same is true of backups with --backup-dir, provided that
you use --relative so you can specify the same destination argument for
every run.

> Any idea to get the -b funcionality back again and obtain a compromise
> between space and performance?

To fix the performance while keeping the space usage low, look into the
"source-filter_dest-filter" branch of rsync:

http://rsync.samba.org/ftp/rsync/dev/patches/source-filter_dest-filter.diff

You could run rsync once for all the files and specify your encryption
program as the --source-filter, and rsync would call your encryption
program once per file as needed.

Matt