[sf-lug] New Open Source Software Proposal

[David Hinkle]

I would totally build the functionality into the tool to download subdirectories, specific files, and to produce a file listing.

David

-----Original Message-----
From: sf-lug-bounces at linuxmafia.com [mailto:sf-lug-bounces at linuxmafia.com] On Behalf Of David Rosenstrauch
Sent: Tuesday, March 16, 2010 9:37 AM
To: sf-lug at linuxmafia.com
Subject: Re: [sf-lug] New Open Source Software Proposal

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.
> http://www.arg0.net/encfsintro
>
> Using this approach, nothing 'new' needs to be written.
>
> alex

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 
unworkable.


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 
filesystem.

DR

_______________________________________________
sf-lug mailing list
sf-lug at linuxmafia.com
http://linuxmafia.com/mailman/listinfo/sf-lug
Information about SF-LUG is at http://www.sf-lug.org/