From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 7 14:33:42 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 447BC16A437 for ; Tue, 7 Mar 2006 14:33:42 +0000 (GMT) (envelope-from babkin@verizon.net) Received: from vms046pub.verizon.net (vms046pub.verizon.net [206.46.252.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 595A543D75 for ; Tue, 7 Mar 2006 14:33:38 +0000 (GMT) (envelope-from babkin@verizon.net) Received: from vms172.mailsrvcs.net ([192.168.1.1]) by vms046.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0IVR00BXMHS1GGU5@vms046.mailsrvcs.net> for freebsd-hackers@freebsd.org; Tue, 07 Mar 2006 08:33:37 -0600 (CST) Date: Tue, 07 Mar 2006 08:33:37 -0600 (CST) From: Sergey Babkin To: Bernd Walter , babkin@users.sourceforge.net Message-id: <25525887.1141742017684.JavaMail.root@vms172.mailsrvcs.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Mailman-Approved-At: Tue, 07 Mar 2006 14:39:00 +0000 Cc: freebsd-hackers@freebsd.org, Ashley Moran Subject: Re: Re: NetBSD disk backup over network X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: babkin@users.sf.net 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 14:33:42 -0000 >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. -SB