A recovery time objective (RTO) is a critical tool for disaster recovery planning. It helps you understand the kind of recovery strategies and technologies you need to have in place to successfully recover from a disaster.
Put simply, RTO is a measurement of your tolerance for downtime. It answers the question, how long can we be without access to our data before the impact on our organization is too great? Once you determine that metric you’re in better position to plan your recovery.
Note that RTO isn’t intended to help you recover data or establish backup schedules. Instead, it guides you as you set up your systems to ensure you’ll be up and running before you start hemorrhaging money and damaging your reputation. If you’re looking for a tool to help determine your data loss and backup requirements check out our post on recovery point objective (RPO).
Just What Is RTO Anyway?
When a disaster strikes, it may take one or more of your systems down. Even with a mirrored, geographically diverse infrastructure, you’re going to suffer some downtime until things can be resolved. And, obviously, downtime is bad.
That’s where RTO comes in. Determining RTO involves understanding all the ways downtime can affect you, which helps you understand how much downtime you can tolerate. Of course, no one wants any downtime, but that may not be realistic for many organizations so it’s important to understand how much you can take.
Once you have established your RTO, you’re in a position to make more informed decisions about your disaster recovery plan. For example, if you determine that you can really only handle a single hour of downtime, then you should invest in disaster recovery technology that makes that possible. Virtualization is one way to do so.
So how do you determine an RTO?
How Much Downtime Can You Take?
The first thing to keep in mind is that you’ll probably have different RTOs for each of your servers or applications. For example, your tolerance for downtime for your Exchange server—which, for the most part, everyone needs all the time—should be much lower than for an infrequently-used file server. It’s important to take these differences into account so that your disaster recovery plan can be as efficient and effective as possible.
Also, make sure you involve all of your business stakeholders in establishing your RTO. While the financial cost of downtime will probably be at the top of your priority list, it’s important to understand how downtime will affect every part of your company before you can create a plan that works for everyone.
Being prepared for a disaster is really all about understanding threats and adapting your IT environment accordingly. RTO is a great tool to help you do that.