Very good this patch...thank you I've been testing this after patching rsync, and works fine to backup...but when I'm restoring the crypted data after a while rsync shows rsync: Failed to close: Bad file descriptor (9) rsync: Failed dup/close: Bad file descriptor (9) rsync error: error in IPC code (code 14) at pipe.c(208) [receiver=3.0.0] rsync error: error in IPC code (code 14) at pipe.c(195) [receiver=3.0.0] rsync: connection unexpectedly closed (55 bytes received so far) [generator] rsync error: error in rsync protocol data stream (code 12) at io.c(600) [generat or=3.0.0]
It's a bit strange. It restores some files before failing, and they are perfectly decrypted...i'm using openssl as command ------------------------------------------------------------------------------------------------------- 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
-- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
