Date: Tue, 07 Oct 2008 01:42:33 +0300 From: Evren Yurtesen <yurtesen@ispro.net> To: Zaphod Beeblebrox <zbeeble@gmail.com> Cc: hackers@freebsd.org Subject: Re: continuous backup solution for FreeBSD Message-ID: <48EA9459.2000807@ispro.net> In-Reply-To: <5f67a8c40810061508t300e77c7n8c1439462622a71c@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
Zaphod Beeblebrox wrote: > Actually, right back at you. You didn't fathom the meaning in my > statement. While your post was vague, I read the company's website to I am sorry what was vague since I wrote 'continuous backup' in my post? The whole idea is such a basic idea that if you put this to google you can get wikipedia entry about it in first 3 results (I see in 2nd). Maybe you didnt know anything about it makes it vague to you. The message I sent was quite clear and plain. > determine the featureset they were claiming (although I missed their > postgres support --- I only read the "features" page). NetBSD's hammer > filesystem achieves replication at the filesystem layer (which will do > infinitely better at this problem than a block-only driver) by > maintaining a history of what's happened and being able to "select" (as > in the database term) changes to the filesystem that have occurred since > the last batch of blocks were shiped out to replication. This gives you > both fine grained recovery (basically changes to files are kept until > your "rules" define they should be freed) and replication and fine > grained recovery on the other side of replication. In fact, Hammer > delivers what they claim in a far more sophisticated way. You might want to read this page too: http://www.r1soft.com/CDP.html > (but it's NetBSD, not FreeBSD, unless someone decides to port it) While Hammer might be doing a similar job, it is a filesystem not a backup application and it wont replace backups. It doesnt just store the data in a backup server. While eventually it might become a backup solution, it will take years before that can happen. Even then, people will not just switch their current filesystems overnight. The CDP backup softwares are available today, it just needs a sort of driver to function in current system. > Also they support postgresql as well (while its usage is way smaller > than mysql) > http://www.r1soft.com/CDP_db_postgreSQL.html > > In any case, the product guarantees that it can return your > databases to any point in the time. Do you see what you are missing? :) > > > Well... "I" am not missing it. I have that without making my filesystem > jump through an enormous hoop. But designing "my" application > correctly, I have that feature for far less effort. (that was the other > point of my post) Can you just explain how can one currently do that in FreeBSD? Is it as easy as in Linux with CDP backup softwares? such as installing a program and done? > > > I've spent a lot of time thinking about redundancy and I've come > to one inescapable conclusion: That the further up the stack you > design for redundancy, the cheaper and easier it becomes. Most > databases have replication strategies of one type or another > that don't require exotic hosting solutions to work. > > > The idea/problem is not redundancy here, it is data protection. > > > Well... no... you don't need fine grained filesystem history for data > integrity (unless you let loose a bunch of summer students armed with > the ability to RM or your application is faulty (in which case, your > filesystem won't protect you). As I said, This can all be achieved with > other far simpler solutions. However, if your dev team isn't smart > enough (or don't care for some reason), then you can take advantage of > their product and pay their price. There is no perfect system. This is exactly why people take backups. If what you said was applicable then there wouldnt be any need for backup software. People would just make sure that they dont loose their data. In addition to this, I have no control of if my customer will delete his/her data accidentally. I cant make a system which does not allow customers to delete data. I have given an example of a simple solution that Linux users can utilize (which obviously we also can utilize if we put our heads into it and give some directions as r1soft is willing to support FreeBSD). While you are first saying that these can be achieved with far simpler solutions, at the same time you are saying that the dev team must be smart enough. My solution is simple enough to write here. You install Linux on all machines and then CDP backup server on the backup server and CDP agent on the client machines, is yours simpler? Then explain how we can create similar sort of data protection? Thanks, Evren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48EA9459.2000807>