Date: Thu, 17 Jan 2008 09:30:08 +0100 From: "Ulrich Spoerlein" <uspoerlein@gmail.com> To: "=?ISO-8859-1?Q?Johan_Str=F6m?=" <johan@stromnet.se> Cc: emj@emj.se, freebsd-stable@freebsd.org Subject: Re: Backup solution suggestions [ggated] Message-ID: <7ad7ddd90801170030l790810b5r5bb156e3cda286b1@mail.gmail.com> In-Reply-To: <134BD86C-19CF-42A7-9190-FAD3BB564A06@stromnet.se> References: <E6BCC509-6CC8-44F1-98C2-416920A52218@stromnet.se> <39FB5CF3-F2F4-401B-9D6D-7796608152E5@ish.com.au> <4FF9842D-ADC9-4A99-9DC4-E0FE1CC9CDCF@stromnet.se> <20080116222729.GB1529@roadrunner.spoerlein.net> <134BD86C-19CF-42A7-9190-FAD3BB564A06@stromnet.se>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 17, 2008 1:31 AM, Johan Str=F6m <johan@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, hel= l 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7ad7ddd90801170030l790810b5r5bb156e3cda286b1>