I am running a hosting server currently equipped with a backup diesel generator. Since the blackout, I have been considering a backup high availability system, where if one would go out, the other would pick up the slack. I have been told that this is impossible, and can only work if I use a high availability scheme which would always keep one server running.

It's called quasi real-time backup with redundancy failover...

I have been told: "The expensive version of that would be to use the akamai network, you could have both geographical load balancing and near-instant failover.

That's the hardware version... yikes. Count your pennies, you will need them.

Otherwise, Youd have to build a cluster to start with, there are a lot of ways to do this, and it depends on the service.

A cluster is not necessary, although I've heard the word "cluster" loosely used to decribe what you want. IIRC there is a distro out (I have no details, this is from memory) that does this pretty much automagically.

WWW for example is much easier to do than mail, you can use rsync to keep the content up to date.

Unless those websites are glued together by a database. Then it becomes more complex...

Logfiles on the other hand would have to be recombined and processed later on to do statistics.

Log to a seperate log machine and you don't have to worry about it. good idea on an Enterprise network anyways...

Another cheap way to do this would be to set up a bunch of squid servers to proxy traffic to your box. This wouldnt do anything for mail though, to keep that together you'd need some kind of network file system, NFS, AFS or Coda (qmail is NFS aware, which helps). You'd only need to store the user mailboxes (/var/qmail/mailnames) on the network filesystem, Id keep the queue on a local disk for performance reasons.

Just settle for using Maildir. Anything not completed will be tried again by most mailservers. Using a short (1 min) backup window will come in handy here, so only the mails completed within that magic minute will be lost until synced back into the mix after bringng the first machine back to life.

For content, I'd designate one system as the designated "master" for inbound content (ftp, database, etc), and everything else mirrors that (rsync, replication for mysql and postgres, etc).

Just directing to an IP is good enough... the failover scheme takes care of all the rest.

Databases would be the most complex component, you'd have to work out your replication strategy to break out how to do the inserts/updates without each system stepping on each others toes."

Does anyone have an idea of how I could offer live (or rsynced to 2 hours) backup/live services for hosting. I would like if one server went down, the other would take over. Is this possible?

I know you can do it to within as little as one minute depending on the data you're backing up. The setup is quite simplistic: One machine that holds the data master copy, one for the backup server, and a third to see to the switching. Sysadmin Mag had an article about doing thsi last year (July 2002) "An Economical Scheme for Quasi Real-Time Backup" by Leo Liberti and Franco Raimondi. I don't think the article can be found on the net, but I happen to have a copy that I can photocopy for you if you'd care to come pick it up. That will take care of keeping the 2 servers sync'ed. Now you need a fast failover plan. Here's a link to another article that's pretty simple to follow. "Quick Network Redundancy Schemes" by Leo Liberti http://www.samag.com/documents/s=1152/sam0104a/0104a.htm Liberti co-authored the first article and also combines the 2 systems, which is pretty simple, actually. HTH -- Keith Mastin BeechTree Information Technology Services Inc. Toronto, Canada (416)696 6070 -- The Toronto Linux Users Group. Meetings: http://tlug.ss.org TLUG requests: Linux topics, No HTML, wrap text below 80 columns How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml