From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 7 15:48:44 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0ACB716A420 for ; Tue, 7 Mar 2006 15:48:44 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 779E543D48 for ; Tue, 7 Mar 2006 15:48:43 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id k27FjtZH004897; Tue, 7 Mar 2006 08:45:56 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 07 Mar 2006 08:45:55 -0700 (MST) Message-Id: <20060307.084555.41637172.imp@bsdimp.com> To: babkin@users.sourceforge.net, babkin@verizon.net From: Warner Losh In-Reply-To: <25525887.1141742017684.JavaMail.root@vms172.mailsrvcs.net> References: <25525887.1141742017684.JavaMail.root@vms172.mailsrvcs.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Tue, 07 Mar 2006 08:45:56 -0700 (MST) Cc: ticso@cicely12.cicely.de, freebsd-hackers@freebsd.org, work@ashleymoran.me.uk Subject: Re: NetBSD disk backup over network X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2006 15:48:44 -0000 From: Sergey Babkin Subject: Re: Re: NetBSD disk backup over network Date: Tue, 07 Mar 2006 08:33:37 -0600 (CST) > >From: Bernd Walter > >> >From: Ashley Moran > >> > >> >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