Planning for Data Center Disasters Doesn’t Have to Cost a Lot of $$

June 18, 2008

One of the hot topics over the past couple of weeks in our growing industry has been how to minimize downtime should your (or your host’s) data center experience catastrophic failure leading to outages that could span multiple days.

Some will think that it is the host’s responsibility to essentially maintain a spare data center into which they can migrate customers in case of catastrophe. The reason we don’t do this is simple economics. To maintain this type of redundancy, we’d need to charge you at least double our current rates. Because costs begin jumping exponentially instead of linearly as extensive redundancy is added, we’d likely need to charge you more than double our current rates. You know what? Nobody would buy at that point. It would be above the “reservation price” of the market. Go check your old Econ 101 notes for more details.

Given this economic reality, we at SoftLayer provide the infrastructure and tools for you to recover quickly from a catastrophe with minimal cost and downtime. But, every customer must determine which tools to use and build a plan that suits the needs of the business.

One way to do this is to maintain a hot-synched copy of your server at a second of our three geographically diverse locations. Should catastrophe happen to the location of your server, you will stay up and have no downtime. Many of you do this already, even keeping servers at multiple hosts. According to our customer surveys, 61% of our customers use multiple providers for exactly that reason – to minimize business risk.

Now I know what you’re thinking – “why should I maintain double redundancy and double my costs if you won’t do it?” Believe me, I understand this - I realize that your profit margins may not be able to handle a doubling of your costs. That is why SoftLayer provides the infrastructure and tools to provide an affordable alternative to running double infrastructure in multiple locations in case of catastrophe.

SoftLayer’s eVault offering can be a great cost effective alternative to the cost of placing servers in multiple locations. Justin Scott has already blogged about the rich backup features of eVault and how his backup data is in Seattle while his server is in Dallas, so I won’t continue to restate what he has already said. I will add that eVault is available in each of our data centers, so no matter where your server is at SoftLayer, you can work with your sales rep to have your eVault backups in a different location. Thus, for prices that are WAY lower than an extra server (eVault starts at $20/month), you can keep near real-time backups of your server data off site. And because the data transfer between locations happens on SoftLayer’s private network, your data is secure and the transfer doesn’t count toward your bandwidth allotment.

So let’s say your server is in our new Washington DC data center and your eVault backups are kept in one of our Dallas data centers. A terrorist group decides to bomb data centers in the Washington DC area in an attempt to cripple US government infrastructure and our facility is affected and won’t be back up for several days. At this point, you can order a server in Dallas, and once it is provisioned in an hour or so, you restore the eVault backup of your choice, wait on DNS to propagate based on TTL, and you’re rolling again.

Granted, you do experience some downtime with this recovery strategy. But the tradeoff is that you are up and running smoothly after the brief downtime at a cost for this contingency that begins at only $20 per month. And when you factor in your SLA credit on the destroyed server, this offsets the cost of ordering a new server, so the cost of your eVault is the only cost of this recovery plan.

This is much less than doubling your costs with offsite servers to almost guarantee no downtime. The reason that I throw in the word “almost” is that if an asteroid storm takes out all of our locations and your other providers’ locations, you will experience downtime. Significant downtime.

-Gary

Comments

June 30th, 2008 at 2:31pm

"... very customer must determine which tools to use and build a plan that suits the needs of the business ..."

This is one of the hardest but most necessary decisions that any business with online operations can make.

I've always advised starting this process from the business function side and ignore costs and technology. Ask yourself simple questions, what would happen if we lost all of our data? What would happen if we were offline for an hour, a day or a week? Consider the impact of an outage to you and your customers.

In general, you will find that the faster the recovery from a critical incident the more expensive the solution will be. If you need sub 1 hour recovery periods, you may need to be using Global Server Load Balancing, advanced data replication methods and other technologies that are considerably more expensive to deploy and maintain than a DVD with a copy of your files.

Also, never forget to re-evaluate your disaster recovery needs, especially if you are a rapidly growing online business. I have seen clients have their revenues grow by 10-fold and never re-evaluate their IT operations.

When I visit some hosting forums, I always see people starting with a budget. When it comes to disaster recovery, I recommend leaving the budget last. Start with your business needs, price a solution and then see if it is affordable. If not, then you may need to re-evaluate either what your promise to your customers or the fees you charge them.

Leave a Reply

Filtered HTML

  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <pre>, <blockcode>, <bash>, <c>, <cpp>, <drupal5>, <drupal6>, <java>, <javascript>, <php>, <python>, <ruby>. The supported tag styles are: <foo>, [foo].
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.

Comments

June 30th, 2008 at 2:31pm

"... very customer must determine which tools to use and build a plan that suits the needs of the business ..."

This is one of the hardest but most necessary decisions that any business with online operations can make.

I've always advised starting this process from the business function side and ignore costs and technology. Ask yourself simple questions, what would happen if we lost all of our data? What would happen if we were offline for an hour, a day or a week? Consider the impact of an outage to you and your customers.

In general, you will find that the faster the recovery from a critical incident the more expensive the solution will be. If you need sub 1 hour recovery periods, you may need to be using Global Server Load Balancing, advanced data replication methods and other technologies that are considerably more expensive to deploy and maintain than a DVD with a copy of your files.

Also, never forget to re-evaluate your disaster recovery needs, especially if you are a rapidly growing online business. I have seen clients have their revenues grow by 10-fold and never re-evaluate their IT operations.

When I visit some hosting forums, I always see people starting with a budget. When it comes to disaster recovery, I recommend leaving the budget last. Start with your business needs, price a solution and then see if it is affordable. If not, then you may need to re-evaluate either what your promise to your customers or the fees you charge them.

Leave a Reply

Filtered HTML

  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <pre>, <blockcode>, <bash>, <c>, <cpp>, <drupal5>, <drupal6>, <java>, <javascript>, <php>, <python>, <ruby>. The supported tag styles are: <foo>, [foo].
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.