auto-backup across the net

[Jason White]

If you were using an opensource database engine, I would recomend using a
redundant device to store the actual data files of your database.  This can
be done with a variety of methods, there are third party fail-over services,
system integrated clustering solutions, and network attached storage devices
that will make your files redundant.  If I was using a clustered solution,
simply run a copy of the DBMS on each node.  If you are using network
attached storage, or the commonly suggested rsync to keep files current,
then you will still need to run your DBMS on two systems and setup either a
content smart switch, or some DNS rules to do the failover.

Since you are using perl flatfiles, rather than even a simple DBMS, you
probably aren't going for an industry standard solution, meaning
transparency and seamlessness, so you could use rsync on two systems and
have your cgi test for the presence of the primary server and connect to the
secondary server in a failure event.  Also, be sure to back up your files
regularly, because I believe it can be possible to propogate corrupted data
to the fail-over system.

I would be happy to discuss some industry standard solutions out of list.

Jason White

----- Original Message -----
From: "Kari Chisholm" <karic at lclark.edu>
To: "Portland Perl Mongers" <pdx-pm-list at pm.org>
Sent: Thursday, June 20, 2002 3:33 PM
Subject: auto-backup across the net


>
> Friends--
>
> Here's the situation.  I'm building a mission-critical web-based
> database.  It's hosted on a server at, say,
> http://www.serverone.foo/bigdata.cgi.
>
> If that server goes down, even for an hour, I want to be able to
> immediately tell my clients to switch to another server (at another
> location) at, say, http://www.servertwo.foo/bigdata.cgi.
>
> In order to accomplish this kind of seamless transition, I need to
> ensure that data is backed up across the net in more-or-less real time
> - perhaps, every 5 minutes we ship changes to the data across the net.
>
> Is there an obvious solution or technology that I should be thinking
> of?  I'm almost exclusively a Perl guy, so solutions with Perl are a
> good thing, but I'm open to other thoughts...
>
> Thanks!
>
> -kari.
> TIMTOWTDI
>

TIMTOWTDI