Backup solution suggestions [ggated]

[Ulrich Spoerlein]

On Jan 17, 2008 1:31 AM, Johan Ström <johan at stromnet.se> wrote:
> > Export the disk on the backup server with ggated. Bind it on the
> > client
> > with ggatec. Slap a GELI or GBDE encryption on top of it and then
> > put a
> > ZFS on top of it.
> >
> > You can mount/import this "remote" ZFS at will and do your zfs
> > send/receive on your local box. Nothing ever leaves your box
> > unencrypted.
>
> Now that is a cool solution! That actually sounds like something doable.
> I tried it out some at home between a 6.2 box (client) and 7.0 box
> (server), hosting the system in a ZFS "sparse volume" with a
> predefined size, exported that via ggated and connected ggatec on the
> client box. I then did some experimentation with just newfs, and it
> worked great!
> The only downside with this would be that the size is fixed. So I
> played around a bit with setting the volsize property in ZFS and it
> seemd to work just fine. zfs list reported the new, bigger, size.
> Restarted ggatec and did a growfs, and then remounted.. Yay bigger
> disk :)
> Then I went on do do some geli test, geli'ed /dev/ggate0 and
> newfs'ed, mounted and played around a bit. All fine.. Now came the
> problem, i unmounetd it, expanded the zfs volume a bit more,
> restarted ggatec and tried to attach it using geli again (note, I
> have no idea if this is supposed to work at all, I'm just testing.
> Havent read such things anywhere). Now I got Invalid argument.
> Im not realy sure about how GEOM works, but if I recall correct it
> uses the last sectors of the disk? If I moved X bytes of data from
> old end of disk to new end of disk, would that make GELI work? If I
> can get that to work, then this would be a kickass solution (all
> encryption stuff works great, I don't have to allocate all space
> immediatly, I can expand it later without destroying data and
> starting from scratch etc).

I'm pretty certain that GELI cannot handle variable sized disks. But
you could add GVIRSTOR into the mix. But I'd just allocate the
necessary space and be done with it. Adding yet another layer is
asking for trouble, imho.

> Some other questions, more related to ggated/c. Is this stable? Good
> working? how does it handle failure situations? Anyone using it for
> production systems?

>From my personal experience (which is rather limited): No, barely, bad, hell no.

There were/are some open PRs about ggate. I had troubles with
gmirror+ggate in that it would deadlock every other hour on SMP
systems (try removing option PREEMPTION if that bug hits you).

> Yes this is for backup only so minor glitches
> might be acceptable for me, but I'd rather know about those beforehand.

Give it a shot, if your systems stay up and stable, good. If the link
breaks from time to time, I think ZFS should be able to recover most
of it. Since it is your backup, I'd try to break it in interessting
ways first, to get a feel for how robust it is.

Uli