[sf-lug] New Open Source Software Proposal
darose at darose.net
Tue Mar 16 07:37:10 PDT 2010
On 03/15/2010 06:36 PM, Alex Kleider wrote:
> My suggestion is to use enc-fs on the local (to be backed up) machine
> so an encrypted version of the backup source is already available.
> Then when it comes time to do backup, use the encrypted version and
> send it over to the destination directory. The one 'gotcha' that I
> see is that to reconstitute, one needs not only the encrypted file
> and the passphrase, but also the ".encfs5" control file at the top
> level of the raw encfs filesystem. I don't know if rsync transfers
> hidden files but you wouldn't want to be left without it.
> Using this approach, nothing 'new' needs to be written.
There's actually a few gotchas with that:
* It requires 2 rsync steps. It should be possible to do this all in one.
* The .encfs5 file is needed, as you cited.
And, most importantly:
* When you need to recover file(s), there's no way to browse the remote
file system and selectively download specific files (since all the file
names are scrambled). So you'd have to do a *full* "reverse rsync",
downloading *all* the encrypted files - which could potentially take
many hours - in order to recover any files, no matter how small.
That last one seems like a dealbreaker to me, making this approach
I think there's really only 2 solutions here, then: either 1) the
encfs+sshfs approach I mentioned (which suffers from the restriction of
no hard links, and therefore can't do multiple generations of backups),
or 2) the approach that David suggested in his proposal. Note however,
that David's proposal would also suffer from the "no way to
browse/download" issue, unless he worked around it by either a) building
such functionality into the tool, or b) implementing the tool as a fuse
More information about the sf-lug