Tom Wang - Fotolia

Get started Bring yourself up to speed with our introductory content.

Prepare better by knowing these disaster recovery terms

After a disaster strikes, you will be much more prepared to handle it if you have a better understanding of how getting back to normal works.

It's important that IT admins and users protect their businesses from something going wrong. But even when you think you've taken all of the proper preventative steps, disaster can strike. When it does, be ready. Having a strong disaster recovery plan in place is key to getting your business back up and running with little to no downtime. 

When designing a plan, there is plenty to consider, such as time, cost and security. Here are a handful of disaster recovery terms you should be familiar with.

Disaster recovery

First things first, what exactly is disaster recovery? It's the part of your security plan that handles protecting an organization from a negative event. That negative event could be something related to equipment or a virus as well as a natural disaster like a fire or an earthquake. A disaster recovery plan is what companies use to get back on track after the disaster.

The plan is created to minimize the effect of the negative event. Your aim should be to limit the disaster's effect and allow the business to continue in a normal manner as soon as possible.


One term that you'll see floated around when talking about disaster recovery is failover. Failover is a backup operational mode used when the primary one is unavailable. Failover is very important for mission-critical systems that need to be constantly running and working even after a disaster.

A secondary system takes control of certain components, such as a server, network or processor, when the primary system is down.

Recovery point objective

Recovery point objective (RPO) is the maximum amount of time it can take for files to be recovered from backup storage for normal operations to resume after a disaster. RPO also determines the frequency that backup files must be created.

If a file was given an RPO of one day, then the backup files would have to be made at least once a day. If the RPO given was three days, or 72 hours, then backups of that file must be created in 72-hour intervals or less. 

Recovery time objective

Like RPO, recovery time objective (RTO) is a vital part of disaster recovery. RTO is the maximum amount of time that a computer, system, application or network can be down after a disaster or failure happens. Basically, it's a target time for when everything will be back up and running after the disaster strikes.

Businesses that need to be back up and running faster need a shorter RTO, while those who aren't in any hurry can use a longer RTO. RTOs vary among different workloads in a business, with more critical applications needing to be restored faster.

Hyper-V Replica

One disaster recovery tool you can use is Hyper-V Replica. It's a free tool that is offered in Hyper-V 3.0 that creates and maintains copies of virtual machines (VMs). If a disaster does happen, users can failover to the replica VMs that Hyper-V Replica created and continue on with everyday business.

Inside Hyper-V Replica, a VSS writer creates a snapshot of the VM on the primary host and it's copied onto the secondary host. When a disaster hits, the admin has copies of the VMs available.

VMware Site Recovery Manager

Another way of protecting your environment is through the use of VMware vSphere Site Recovery Manager. This tool provides automated disaster recovery testing and failover.

Businesses want to be able to quickly recover from a virtual disaster and Site Recovery Manager (SRM) offers some options to make that happen. SRM can prioritize the recovery process, choosing the order that the VMs are restarted.

Dig Deeper on Disaster recovery strategies, business continuity and virtualization

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

You know, I hate the whole terminology of "disaster recovery" in the first place, because it implies that data loss is inevitable and all you can do is figure out how to pick up the pieces. How about calling it "disaster planning," which puts the focus on eliminating data loss and maintaining data access, instead?
Disaster "preparedness" is another term that I've seen - I like that one too.