continuous backup solution for FreeBSD

[Zaphod Beeblebrox]

On Mon, Oct 6, 2008 at 10:33 AM, Evren Yurtesen <yurtesen at ispro.net> wrote:

[regarding 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'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 most fundamental example I can think of to show this principle, however,
is the fact that if the HTTP standard required web browsers to try all A
records (instead of randomly choosing one), web site redundancy would be
amazingly simple to achieve.  Consider that most other protocols right down
to telnet do this, but web browsers don't.

As a complete aside, if you have both AAAA and A records for your website,
you have a form of poor-man's redundancy available to you --- with the
caveat that it only works for people with both IPv6 and IPv4 connectivity.
Browsers will try AAAA followed by A if the former doesn't respond.