Re: [tlug] Raid5 box & backup

[Curt Sampson <cjs@example.com>]

On 2008-05-25 23:46 +0900 (Sun), Bruno wrote:

> On Sun, May 25, 2008 at 10:31 PM, Curt Sampson <cjs@example.com>
> wrote:
> 
> > The only way you can hope to reasonably fast rsync or unison style
> > syncing is if each local machine has unencrypted access to the
> > filesystem. You might be able to do this livably by using encrypted
> > files on top of unencrypted filesystems.
> >
> 
> This was my first idea... I just hoped to get another solution, but I will
> not, apparently :-(

Actually, that's where we go back to my original idea, come to think of
it. You won't get bidirectional sharing (because it would corrupt the
filesystems), but here's what you do:

    1. At site A, set up a set of large files, a1, a2, ..., each of
    which will hold a filesystem to be used locally at site A. Set up
    rsync to sync these over to site B. Do the inverse for site B.

    2. Export each of these files as a block device over the network.

    3. Each owner than configures his own machine to attach this block
    device to his computer, and then configures it as an encrypted
    filesystem, using local keys etc. as you would with any local
    filesystem. You may want to contemplate making this use hard
    sync, to minimize the amount of time the filesystem has integrity
    problems.

Voila, everybody has his own encrypted filesystem, backed by encrypted
blocks in a normal file on the server, which is sync'd regularly to the
remote server.

The disadvantages?

    1. It's not usable remotely, at least not with any kind of reasonable
    speed, and possibly not at all, depending on firewalls, etc.

    2. Even on a GigE network, it's likely to be slower than a local
    filesystem.

    3. Unless it's a transactional filesystem, it's likely regularly to
    be in an inconsistent state on a regular basis, and this inconsistent
    state will be copied to the backup.

    4. The CPU cost of the rsync is likely to be fairly high on both
    ends, because the only way rsync has to know whether to copy a
    particular block or not is to read it and calculate its hash.

> Even with these thousands, I guess you would not *guarantee* anything,
> would you?

Not likely. I can make some guarantees, but if keep in mind that even
seemingly simple guarantees might depend on me, for example, doing a
complete analysis of whatever encrypted filesystem you're using and
taking steps to make sure that you, e.g., never do a kernel upgrade.

I can only tell you what level of resistance you have against various
attacks. And even there, much of it is to do with you. If you decide to
give your keys to someone, there's not much that *I* can do about that.
(Other than perhaps suggest you should have just let the guy shoot you
instead. :-))

cjs
-- 
Curt Sampson       <cjs@example.com>        +81 90 7737 2974   
Mobile sites and software consulting: http://www.starling-software.com