Date: Thu, 17 Jan 2008 01:31:45 +0100 From: =?ISO-8859-1?Q?Johan_Str=F6m?= <johan@stromnet.se> To: Ulrich Spoerlein <uspoerlein@gmail.com> Cc: emj@emj.se, freebsd-stable@freebsd.org Subject: Re: Backup solution suggestions [ggated] Message-ID: <134BD86C-19CF-42A7-9190-FAD3BB564A06@stromnet.se> In-Reply-To: <20080116222729.GB1529@roadrunner.spoerlein.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 16, 2008, at 23:27 , Ulrich Spoerlein wrote: > On Wed, 16.01.2008 at 00:26:34 +0100, Johan Str=F6m wrote: >> I create regular tarball (gziped maybee) with some files i want to =20= >> backup, >> Then i encrypt this file with ie gpg. Then i send of this file =20 >> using some >> unspecified network protocol to the storage server. >> Encrypted all the way, from my end to the remote disk.. >> The downside is that it is a static file.. not a "dynamic =20 >> filesystem", >> nothing I can mount and have easy access to individual files from. =20= >> *Thats* >> what I'm looking for. > > Export the disk on the backup server with ggated. Bind it on the =20 > client > with ggatec. Slap a GELI or GBDE encryption on top of it and then =20 > 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 =20 (server), hosting the system in a ZFS "sparse volume" with a =20 predefined size, exported that via ggated and connected ggatec on the =20= client box. I then did some experimentation with just newfs, and it =20 worked great! The only downside with this would be that the size is fixed. So I =20 played around a bit with setting the volsize property in ZFS and it =20 seemd to work just fine. zfs list reported the new, bigger, size. =20 Restarted ggatec and did a growfs, and then remounted.. Yay bigger =20 disk :) Then I went on do do some geli test, geli'ed /dev/ggate0 and =20 newfs'ed, mounted and played around a bit. All fine.. Now came the =20 problem, i unmounetd it, expanded the zfs volume a bit more, =20 restarted ggatec and tried to attach it using geli again (note, I =20 have no idea if this is supposed to work at all, I'm just testing. =20 Havent read such things anywhere). Now I got Invalid argument. Im not realy sure about how GEOM works, but if I recall correct it =20 uses the last sectors of the disk? If I moved X bytes of data from =20 old end of disk to new end of disk, would that make GELI work? If I =20 can get that to work, then this would be a kickass solution (all =20 encryption stuff works great, I don't have to allocate all space =20 immediatly, I can expand it later without destroying data and =20 starting from scratch etc). Some other questions, more related to ggated/c. Is this stable? Good =20 working? how does it handle failure situations? Anyone using it for =20 production systems? Yes this is for backup only so minor glitches =20 might be acceptable for me, but I'd rather know about those beforehand. I did some dd from urandom to the disk, with and without GELI.. I did =20= notice some slightly lower speeds, i was able to write around 11MB/s =20 without GELI, with GELI it did around 9.5MB/s. The client machine is =20 no super box but its not that bad (A64 3200, 1G mem with not much load). Input and ideas? Thank you very much :) -- Johan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?134BD86C-19CF-42A7-9190-FAD3BB564A06>