Date: Mon, 6 Oct 2008 18:08:28 -0400 From: "Zaphod Beeblebrox" <zbeeble@gmail.com> To: "Evren Yurtesen" <yurtesen@ispro.net> Cc: hackers@freebsd.org Subject: Re: continuous backup solution for FreeBSD Message-ID: <5f67a8c40810061508t300e77c7n8c1439462622a71c@mail.gmail.com> In-Reply-To: <48EA6939.6090405@ispro.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Oct 6, 2008 at 3:38 PM, Evren Yurtesen <yurtesen@ispro.net> wrote: > Zaphod Beeblebrox wrote: > >> On Mon, Oct 6, 2008 at 10:33 AM, Evren Yurtesen <yurtesen@ispro.net<mailto: >> yurtesen@ispro.net>> wrote: >> >> [regarding r1soft.com <http://r1soft.com>, ...] >> >> I am not saying it is impossible. They just need somebody to put >> them to right track I guess. I personally cant do that. It would be >> nice if somebody who has knowledge in this area contacts r1soft. At >> the very least r1soft seems to be willing to communicate on this issue. >> >> Continuous backups as well as bare-metal-restore seem to be a key >> feature for many hosters. FreeBSD is loosing users because of this >> issue. >> >> >> Actually, having looked at the site, the hammer filesystem and it's >> replication strategy seem to be the most applicable technology (but then you >> wouldn't even need these guys --- you'd be doing it yourself). Like >> anything, though, live applications will require special treatment. Keeping >> a live filesystem replicated does in no way guarentee that your database >> (for instance) will be sane at any particular moment. It sounds like these >> guys have made allowances for MySQL (they specifically mention it), but this >> won't help the PostgreSQL users, etc. >> > > I think you didnt get the point here. Replication or mirroring != backup. > You cant return back to how things were 1 hour ago. 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 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. (but it's NetBSD, not FreeBSD, unless someone decides to port it) > 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) > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5f67a8c40810061508t300e77c7n8c1439462622a71c>