[sf-lug] Linux backup software .. that meets unique requirements
darose at darose.net
Mon Mar 15 11:18:04 PDT 2010
On 03/15/2010 12:33 PM, David Hinkle wrote:
> That's a neat trick, but isn't the contents of your encrypted
> filesystem available for browsing on the remote end while your backup
> is taking place? From looking at the FAQ my understanding is that
> EncFS mounts an encrypted filesystem as unencrypted and available to
> the OS, and then SSHFS simply provides a transport mechanism to make
> any generic directly appear at the remote end over an ssh link.
I don't think that's an issue. The way encfs works is that it maps an
encrypted directory to an unencrypted one. So if I choose the encrypted
directory to be an sshfs remote dir, and the unencrypted one to be a
local mount point then this isn't an issue. The clear text data will be
local, and the remote data will be encrypted.
> If my understanding is correct, and that's acceptable, I'd recommend
> using a more standard encrypted filesystem and using rsync's built in
> SSH transport.
I'd be open to it, except for a couple of things: 1) I don't know of
any other FS that works similar to Encfs, and 2) remember that I have no
control over the remote file storage. All I essentially have is sftp
access to it, so I can't install things on it.
> The SSHFS website indicates there are posix problems
> related to SFTP (Which it uses for a transport, unlike rsync) not
> being able to atomically move files over other files, which causes
> problems with subversion, among other things.
That is a bit worrisome. I'll have to look into that.
> Also, I expect you'll run into pretty stiff performance problems if
> you try to use rsync to rsync against an SSHFS mounted directory.
> Rsync is going to try to read every file in it's entirety if you have
> checksumming on. This will require a complete download of the
> repository one file at a time. You can leave checksumming off, and
> then you'll be fine for files that have the same date and size, but
> any other file (i.e. files that have changed) will be downloaded in
> it's entirety and then re-uploaded, which is still suboptimal.
Not sure I understand. Does an sshfs file system work differently than
a regular remote file system in this regard? A typical rsync over ssh
won't wind up having to read every file?
> I don't know if you've ever used Linux's built in crypto filesystem
> stuff, but if you haven't here's a quick intro. You create a file
> large enough to hold all your data, then turn that file into a device
> node using the loopback device. You can then mount any crypto
> filesystem on top of that that's supported by your kernel (Or any
> other filesystem for that matter, you can treat it just like a disk).
> Though, all of this probably requires root and I don't know if you
> have root. If you do, however, you won't beat the performance of
> this solution.
But again, I have no control over the remote server, so I can't set up a
looback crypto filesystem there.
> Another option is to use fuse's encfs (http://www.arg0.net/encfs)
> alone and back up to that directly with rsync, skipping potential
> compatibility problems with the SSHFS transport by using the tried
> and true rsync over ssh transport. I've never used fuse before, so I
> can't attest to it's effectiveness.
I'm not sure I understand how this would work. I want to rsync from
<local src> to <remote dest>, with the <local src> being the unencrypted
data on my server, and <remote dest> being the unencrypted remote file
system. How would it be possible to introduce encfs alone into the mix
to make this be encrypted?
More information about the sf-lug