Disaster recovery can be a huge task, especially when dealing with multiple servers, sites, and databases. Two key items to take into account with the solution you select are recovery time objectives (RTOs) and recovery point objectives (RPOs).

RTO is essentially the expectation of how long it should take until the sites are back up. If you have an RTO of a minute or two (or less), then you should be considering a solution in line with what Nick suggested that involves real time replication of your files and data to an secondary data center and automatic failover of DNS which could be done with a paid service or with hardware at both data centers (such as the BIG-IP Global Traffic Manager from F5 Networks. This can get costly, but largely depends on answering the question "What is the cost of downtime?" If your RTO is a few hours or even a few days, then you can consider disaster recovery procedures that may involve more manual involvement such as bringing servers online, switching DNS, etc. Tedious, but certainly cost effective if your RTO allows for that.

RPO is basically how frequently backups are done and how much data you are willing to lose in the event of a disaster. If changes to content and/or data happen frequently, then you are likely to have an RPO of maybe minutes or hours and may be dealing with real time replication or high frequency backups. If content doesn't change that often or you have customers that don't necessarily care that they lose data for a few days, your backups can happen less often.

As I mentioned, I agree with much of what Nick had to say. Another alternative you may wish to consider is to utilize cloud based services from one of the larger cloud based providers such as Rackspace or Amazon. Both of those providers in particular have massive infrastructure in place to be able to handle just about any disaster thrown at them. With something like a cloud site or cloud server (terms used by Rackspace), you have the advantage of being able to scale as well and don't have to necessarily worry about the physical hardware aspect of it.

Rackspace also has custom options available where you can intermix your infrastructure, having a combination of cloud servers, physical servers, and cloud files as part of your solution. A hybrid approach may be something to consider depending on your customer needs if you don't want to take a one size fits all approach.

If it helps, there is a page dedicated to disaster recovery on the Rackspace site as well which can be found here. (Also for the record, I am not affiliated with Rackspace, but have used their services in the past).

Hope this has helped.

Disaster recovery can be a huge task, especially when dealing with multiple servers, sites, and databases. Two key items to take into account with the solution you select are recovery time objectives (RTOs) and recovery point objectives (RPOs).

RTO is essentially the expectation of how long it should take until the sites are back up. If you have an RTO of a minute or two (or less), then you should be considering a solution in line with what Nick suggested that involves real time replication of your files and data to an secondary data center and automatic failover of DNS which could be done with a paid service or with hardware at both data centers (such as the BIG-IP Global Traffic Manager from F5 Networks. This can get costly, but largely depends on answering the question "What is the cost of downtime?" If your RTO is a few hours or even a few days, then you can consider disaster recovery procedures that may involve more manual involvement such as bringing servers online, switching DNS, etc. Tedious, but certainly cost effective if your RTO allows for that.

RPO is basically how frequently backups are done and how much data you are willing to lose in the event of a disaster. If changes to content and/or data happen frequently, then you are likely to have an RPO of maybe minutes or hours and may be dealing with real time replication or high frequency backups. If content doesn't change that often or you have customers that don't necessarily care that they lose data for a few days, your backups can happen less often.

As I mentioned, I agree with much of what Nick had to say. Another alternative you may wish to consider is to utilize cloud based services from one of the larger cloud based providers such as Rackspace or Amazon. Both of those providers in particular have massive infrastructure in place to be able to handle just about any disaster thrown at them. With something like a cloud site or cloud server (terms used by Rackspace), you have the advantage of being able to scale as well and don't have to necessarily worry about the physical hardware aspect of it.

Rackspace also has custom options available where you can intermix your infrastructure, having a combination of cloud servers, physical servers, and cloud files as part of your solution. A hybrid approach may be something to consider depending on your customer needs if you don't want to take a one size fits all approach.

If it helps, there is a page dedicated to disaster recovery on the Rackspace site as well which can be found here. (Also for the record, I am not affiliated with Rackspace, but have used their services in the past).

Hope this has helped.

EDIT: Thought this might help if you are evaluating cloud solutions. The Gartner Magic Quadrant Report for Infrastructure and as a Service and Web Hosting may give you some insight into other solution providers.