Looking for something else?
Kyle Rankin, systems architect with Quinstreet Inc. and president of the North Bay Linux Users Group, discusses the pros and cons of remote data center management for disaster recovery in this FAQ. His answers are also available as an MP3 below.
Table of contents:
>> Benefits of using a remote data center for disaster recovery
>> Who needs such a robust setup?
>> Are there any tools available to help manage a "lights out" remote data center?
>> What are the drawbacks of automated server management?
>> How does server virtualization play into remote server management?
>> How can you get similar benefits at a lower cost?
I live in California, and I have a lot of computer equipment here, so we are always waiting for the big one that makes where we live fall into the ocean. If you have a business that depends on that data and generates revenue with that data, you want to make sure that you have someplace offsite where you can store it.
Depending on what your goals are, you may not have to do a one-to-one duplication of everything. You might be able to say, "In the case of a disaster, I don't really need all of the speed and resources I have currently available in the data center." For example, if an earthquake destroyed your office, it is probably acceptable to have a slightly sluggish backup site. If your business can deal with somewhat degraded performance, you can save money by purchasing less expensive equipment.
Well, a lot of companies might not have a fully functional remote data center; many just want offsite data storage. So, there are a lot of tools, anything from storage area network (SAN) replication to most backup software, which will allow you to send data offsite.
As far as products for automating management go, the same management tools that you'd use for a typical data center are used for an unmanned or "lights out" data center. The benefits of not having to be in the data center are the same if you are five miles away or 500 miles away.
Let's say you are using SAN replication, unless you are using some sort of clustering file system, or maybe even if you are, typically that means that the server at the remote site can't access the storage while it's being accessed at your primary site. Now in the case of pure disaster recovery, that may not be an issue but it does mean you have to go through some steps if you want to test the storage out.
Some people, instead of just leaving all of those servers idle, and to make a better economy out of their disaster recovery site, may decide it makes sense to treat the disaster recovery site as more of a failover site. So instead of strict disaster recovery, we may want to test it out by having that data center take some active load 24/7 along with the first site. And in that case, if you have something that's automatically dumping backups, it may interfere with being able to have your remote site always running.
If you're not currently using server virtualization, but you want to get better economy out of your disaster recovery site, and you're willing to risk degraded performance, it makes sense to at least have your remote site run on virtual machines. You'll want to try to get as many servers as you can to fit into a slightly smaller footprint, especially if you're going to have a site that's completely idle. If you're only planning on using that site in the case of a bad disaster, then it makes more sense to have those machines be virtual.
Depending on what virtualization software you're using, there's a lot of products that nowadays can have it either up and running, or even something with SAN replication, you can have the data associated with the virtual machines already set up on the remote site. If you already use virtualization, then you get even more benefits because it's a lot easier to duplicate your current environment somewhere else.
The one thing that's most important to most people is the data. Depending on how much downtime your business can sustain, most people build data centers because they figure the cost it would take to build something from scratch in the event the first data center goes completely black, (for example, a fire wipes out all the servers) is too high.
It may be enough to have archival backup. For a very small business, it might be as simple as going to tape or disk backup that you ship elsewhere instead of having servers. You may also be able to take advantage of some sort of cloud computing depending on your applications, so you have at least something out there that can continue running at least part of your business.