From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 7 08:11:21 2008 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AED410656A6 for ; Tue, 7 Oct 2008 08:11:21 +0000 (UTC) (envelope-from yurtesen@ispro.net) Received: from mail.ispro.net (mail.ispro.net [87.251.0.19]) by mx1.freebsd.org (Postfix) with ESMTP id A90878FC25 for ; Tue, 7 Oct 2008 08:11:19 +0000 (UTC) (envelope-from yurtesen@ispro.net) Received: (qmail 90211 invoked by uid 399); 7 Oct 2008 08:11:34 -0000 Received: from a91-152-230-218.elisa-laajakaista.fi (HELO ?192.168.1.34?) (yurtesen@ispro.net@91.152.230.218) by mail.ispro.net with ESMTPAM; 7 Oct 2008 08:11:34 -0000 X-Originating-IP: 91.152.230.218 Message-ID: <48EB1A1C.7020701@ispro.net> Date: Tue, 07 Oct 2008 11:13:16 +0300 From: Evren Yurtesen User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Zaphod Beeblebrox References: <48E9E1BB.6020908@ispro.net> <001AD718-D25B-421B-8B0F-CE71FA5A7CF0@gid.co.uk> <48EA21AE.80607@ispro.net> <5f67a8c40810060852k4c51c8far511891c4b135a1e2@mail.gmail.com> <48EA6939.6090405@ispro.net> <5f67a8c40810061508t300e77c7n8c1439462622a71c@mail.gmail.com> <48EA9459.2000807@ispro.net> <5f67a8c40810061707m33a52547idae13e2bb9eb2f9a@mail.gmail.com> In-Reply-To: <5f67a8c40810061707m33a52547idae13e2bb9eb2f9a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 07 Oct 2008 11:33:07 +0000 Cc: hackers@freebsd.org Subject: Re: continuous backup solution for FreeBSD 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 Oct 2008 08:11:21 -0000 I think here might be a misunderstanding. I was talking about a reliable backup solution whereas you guys are all the time talking about mirroring and replication type solutions. Since you cant be thinking that mirroring and replication can replace backup, there must be a misunderstanding? Zaphod Beeblebrox wrote: > > From my reading, Hammer is much more than a filesystem, but then you > probably havn't read about it yet. By my reading, Hammer hits all their > feature points and does it better _because_ it's a filesystem. I glanced through these actually: http://www.dragonflybsd.org/hammer/ I didnt see anywhere that it will replace backup programs? > It's relatively simple. Database replication solves the data backup > problem (I don't store application data outside the database). Database > replication for both MySQL and PostgreSQL is relatively straight > forward. As for the configuration of code and servers --- that is taken > care of with configuration management (it's really a bigger issue than > just backing up a filesystem) and installing a new server to take a > place in the cluster is a straight forward checkout from the CM system. > For things I really care about staying up, add VRRP and an application > design that is fault tolerant. Have you ever tried to restore data from MySQL replication logs? :) Even if you use binary logging, when you want to go back in time. You will need to first restore the whole database first from normal backups then replay the logs until the point that you wanna be. There is no simple way to go back in time. That is of course you have backups. If you dont have backups because you think replication is a backup solution, you would be screwed. Totally more complicated that clicking from the web to select data and time and table and restore! Also, you are thinking about a very small sized system. While replication might work if you are relatively small sized company (like 1-2 servers). If you have many independent servers with different databases inside you just cant use it. Even if you could replicate multiple boxes into one box, there would eventually be problems such as same named databases etc. and even then, you cant just easily restore the data if the user deletes all his data in his tables. Also that is not practical for users at all. For example I cant give an option to the user to restore his data by himself. While that is possible with most backup software easily. About VRRP etc. I already told that I am not talking about redundancy here. You are talking about totally different things. I need data protection. > This actually works rather well if you do your research. Database > replication is possible at all kinds of different link speeds and > distances. Database replication also allows you to control your data > better --- you know more about your data than a block replicator would. > It means that your backup is already live and it means that, with the > right scripts, invoking a backup on primary failure is simple. Database > replication on some databases even allows you to preserve transactions > --- which is important in some cases. And how do you propose that I restore a table in the database to of 1h before status? like you can do with a data backup solution? You are talking about a spare server solution not backup solution. Replication IS NOT backup. If you look at articles and information about database replication, almost all mention that it DOES NOT replace backups. > Well... no. Backup software and strategies are just one available tool > for risk mitigation. To know what tools you require, you must define > your risks. Then with your list of risks you look at the cost of each > tool and find the toolset that suits you. By the responses in this > thread, it seems like the set of FreeBSD developers and the set of > people who desire this solution are disjoint. Right, I just cant use the tool I require. There is no way to take near continuous backups of FreeBSD filesystems. > Actually... as some obligatory positive content, the time travel > features of Hammer should be straightforward to implement in ZFS... are > ZFS modules supported on FreeBSD yet? It would seem to be a logical module. Those features work within the filesystem, you there is no mention of mirroring to a remote hard drive, if you could mirror to a remote hard drive, you couldnt easily mirror 10 machines into 1 remote hard drive, even if you could do that, it would require total disk space of all those 10 drives to exist in that 1 backup server. Even if you could overcome that, this would mean that all FreeBSD users wanting to take advantage of such system to convert their filesystems. Even if it was easy enough, there is no GUI tools to allow users exist in those systems to restore files by themselves easily. As you can see, none of the solutions you are suggesting is anywhere near simple solutions which can replace near continous backup solutions. Thanks, Evren