Business Continuity Planning – Enable IT Uptime

To understand the IT piece of disaster recovery and business continuity today, it helps to look at the not-so-distant past.

It really wasn’t very long ago that backup meant daily incremental and weekly full backups to tape or a dedicated disk backup target. Duplicate tape copies were created and shipped offsite for disaster recovery—typically to a secondary site maintained by the business or to a tape vaulting facility (e.g. Iron Mountain). Many businesses continue to use this model today, and depending on your recovery needs it may be perfectly adequate.

However, disaster recovery from offsite tape can be painfully slow. First, you need to retrieve the tapes from an offsite location. Once they are back on premises, you must ingest data to your backup server. At that point, you can restore data and applications to your primary servers. This, of course, means considerable downtime.

When creating an IT disaster recovery plan, it’s important to understand two concepts: recovery time objective (RTO) and recovery point objective (RPO). RTO is the amount of time that it takes to get a system restored following a failure or disaster event. So given the example above, your RTO might amount to 48 hours or more. RPO is the point in time to which data can be restored following the event. So, if you performed a backup at 6pm each night and a server failed at 5pm the following afternoon, your RPO would be 23 hours and any data created during that span would be lost. For many organizations this was unacceptable.

So, rather than relying on tape for disaster recovery, some organizations replicated data to a secondary site that mirrored their data center for DR. However, this approach historically required a massive investment in hardware, because it required two sets of identical servers, storage, switches, software etc. Not to mention a secondary data center facility. Remote replication allows users to fail over operations to a secondary site in the event of a disaster, which improves RTO, but is well out of the reach of most businesses financially.


Advances in virtual server backup and cloud computing changed all of that. Today, users can run applications from image-based backups of virtual machines. This capability is commonly referred to as “recovery-in-place” or “instant recovery.” Recovery-in-place dramatically improves RTO because operations can continue while primary servers are being restored. RPO is reduced as well—snapshot-based, incremental backups at 15 minute intervals are a common practice. Virtual machine images can also be replicated to an alternate site or cloud for disaster recovery.

There are a number of ways to implement this type of system. Many backup software products today have the ability perform these tasks. If your current backup software supports it, you can set it up yourself. If you are relying on an older backup software product or you are starting from scratch, you might opt to outsource these tasks. In this model, an appliance is typically placed on premises for local backup and recovery and data is replicated to the cloud for disaster recovery. Recovery-in-place technology allows you to run applications from the onsite appliance or from the cloud following an outage or disaster. This is commonly referred to as “cloud disaster recovery” or “disaster recovery as a service” (DRaaS).

DRaaS offers the failover capabilities of traditional remote replication at a much lower price point. Users typically pay a monthly subscription fee based on the amount of data they are storing in the cloud. Some services charge additional fees for the processing power necessary to run applications in the cloud during disaster recovery. Compare that with the facilities, personnel and technology expenses associated with setting up a secondary data center and the value of recovery-in-place and DRaaS is apparent.

Testing IT disaster recovery plans is essential. Historically, this was a difficult and potentially risky process. Today’s technologies and services have greatly eased the testing process. Because of the ease in which virtual servers can be created, users can set up DR test environments without the risk of harming production systems. Some DRaaS providers will even perform DR testing for their clients.