Date: Tue, 07 Mar 2006 08:45:55 -0700 (MST) From: Warner Losh <imp@bsdimp.com> To: babkin@users.sourceforge.net, babkin@verizon.net Cc: ticso@cicely12.cicely.de, freebsd-hackers@freebsd.org, work@ashleymoran.me.uk Subject: Re: NetBSD disk backup over network Message-ID: <20060307.084555.41637172.imp@bsdimp.com> In-Reply-To: <25525887.1141742017684.JavaMail.root@vms172.mailsrvcs.net> References: <25525887.1141742017684.JavaMail.root@vms172.mailsrvcs.net>
next in thread | previous in thread | raw e-mail | index | archive | help
From: Sergey Babkin <babkin@verizon.net> Subject: Re: Re: NetBSD disk backup over network Date: Tue, 07 Mar 2006 08:33:37 -0600 (CST) > >From: Bernd Walter <ticso@cicely12.cicely.de> > >> >From: Ashley Moran <work@ashleymoran.me.uk> > >> > >> >I just saw this slashdotted article: > >> >http://ezine.daemonnews.org/200603/dermouse.html > >> > >> Well, I've been running around with this kind of idea for > >> around 10 years now. Never actually implemented it though. > >> I can't quite believe that encryption at full disk speeds > >> makes no noticeable CPU overhead. > > > >This sounds as nothing more than a mirror with one disk beeing a remote > >file. > >And this is not really a new idea - remote mirror has a long standing > >tradition. > >You can already configure these things with GEOM right now. > >But this is in no way a backup, this just saves you from disk failures > >which is the purpose of a mirror. > >What is missing is history in the remote image so that one can access > >older contents. > > You can easily save the stream of updates as a redo > log (well, that's the idea I've been running around with). > Then you can roll forward from the full backup points using > this log, and also use it for online backups while > the operations are still running. Of course, it would > probably require an fsck to get things actually mounted. > My impression from the article was that he had this thing > as well. Years ago, I did something called Datastar. We did remote geographic mirroring between different sites at the block level. This worked only so so. The biggest problem was that on solaris (and FreeBSD too, I'd think) the buffer cache would persist in core a long time before being shipped out to disk in some cases for busy blocks. This made the remote system unusable most of the time. We had no way of knowing how good/bad the actual data was due to these buffering issues. The problem also was that fsck would break the mirror if you did it in write mode, forcing a complete resync (optimized, of course, but still expensive). As would mounting the file system r/w. There were also major issues with solaris mounting it read-only when the mirroring daemon was writing to the disk. These issues aren't insurmountable, but can be difficult to cope with. The missing data issue is likely the biggest, most difficult problem to face. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060307.084555.41637172.imp>