Using a colocation data center for disaster recovery

Colocation data centers are an alternative to setting up your own DR site in a remote location or outsourcing your disaster recovery (DR) to to a disaster recovery service. Colocation facilities offer a data center in which organizations can set up their own network, servers and storage. Although there are several benefits of using colocation centers for DR, users should make sure their colocation data center is secure and in the right location. In this Q&A, Harvey Betan, an independent business continuity planning consultant, describes the benefits of a "colo data center" for DR, what criteria you should follow when choosing a colocation facility and what you can expect to pay for a colocation facility. Read his answers or download the MP3 below.

Listen to the colocation data centers for disaster recovery FAQ

Table of contents:

>> What does it mean to use a colocation data center for disaster recovery?
>> What are the benefits of using a colocation data center for DR vs. outsourcing DR?
>> How can you be sure your colocation facility is secure?
>> What other things should you consider when choosing your colocation facility?
>> How much does a colocation facility typically cost?

Can you define what it means to use a colocation data center for disaster recovery?

Basically what you're doing when you're doing colo, or colocation, is you're migrating your data center to a service provider. Colo is sometimes provided by companies that specialize in site housing. It's basically a data center where multiple customers can install their network, server, data storage, etc. so that customers reduce their overhead and optimize other efficiencies. And sometimes it's used as a good place for DR because it's not your primary location.

Can you outline some of the benefits of using a colocation data center for disaster recovery vs. just outsourcing DR completely?

When you outsource disaster recovery completely what happens is you have no control over what's going on, and it's up to whoever your outsourcer is. When you use colo, basically your data center is just in a different location, so you still have control over the hardware, the software, most of the communications, and any other issues that come up.

Since it's going to be a facility that's not entirely controlled by you, how can you be certain that facility is secure?

The best way is to physically go over to the site and make sure that there are generators; check how far the generators are from each other; check accessibility to the generator; and check the UPS rooms and make sure they're clean and efficient. Basically, do the same types of things you would do if you were checking your data center. Also see if it's monitored with cameras, video, if there's 24-hour surveillance, guards, and check their redundancy. One thing you really want to do is check if they're SAS 70-compliant and certified.

What are some of the other things you should consider when you're choosing your colocation facility?

Primarily I would say proximity to your organization. You don't want a colocation facility across the country. You want to be able to get to your colo site in case something happens to your primary site within a reasonable amount of time. You don't want to travel more than a few hours to get there because you have a lot of issues with people and you might have to get there in the middle of the night, so you don't want to start traveling that far.

What about cost? How much does space in a colocation facility typically cost? Or do they even charge by space?

They do charge by space. I've seen small areas that charge from $2,000 a month to areas that charge $30,000 a month. It'll depend on how much of a footprint you have, and what type of equipment you're putting in there. Obviously if you put a mainframe in there it's going to cost more than if you're going to put a couple of servers in there. Those are the types of things you want to consider: backbone, communication, and some of the other issues you might want to know about accessibility.

This was first published in November 2010

Back to top