Every company should have a disaster recovery plan in place that allows business to resume within a specified amount of time. Additionally, the plan should be audited and updated regularly, considering any system upgrades and other factors that may affect its implementation. After all, if your plan turns out to be partly irrelevant should the worst happen, then it will end up being practically useless.
Today, more companies are outsourcing disaster recovery to take advantage of the benefits of cloud computing. Most importantly, the cloud allows you to back up much, if not all, of your company’s software systems and data remotely. However, when choosing a disaster-recovery-as-a-service (DRaaS) vendor, you’ll need to pay particularly close attention to two key points in their service level agreement (SLA):
- RTO (Recovery Time Objective) refers to the maximum length of time it will take for your systems to be up and running again.
- RPO (Recovery Point Objective) refers to the restore point to which your data and infrastructure will be recovered.
Should disaster strike your business, you’ll inevitably face some downtime which, of course, needs to be as brief as possible. Your plan should clearly state a maximum acceptable downtime, and you’ll want to make sure any SLA provided by your vendor lies within that requirement. The same applies to your RPO. The greater the RPO, the more lost data your company will have to compensate for.
Defining Your RTO
Every business understands that every moment of downtime translates into lost revenue. While most service vendors promise an uptime of close to 100%, there is always a risk of unforeseen consequences leading to unscheduled downtime. You’ll need to define a maximum RTO based on the amount of time it would take before your business suffers irreparable damage.
For mission-critical systems, such as payment portals and security systems, a maximum RTO might be less than an hour. Other non-essential facilities, such as marketing-related systems, might be fine having a longer RTO assigned to them. Of course, however, the optimal RTO varies enormously from one company to the next and even between different departments within the same company.
Your RTO should be calculated from the time the disaster is first identified and declared, rather than when it occurred. After all, you cannot expect to do anything about a disaster if you don’t even know about it! Additionally, you may find that the partial recovery of affected systems will be enough for a longer period, in which case you’ll need to make your priorities clear in your plan.
Defining Your RPO
Your recovery point objective only concerns processes that involve handling data, be they transactions, website content, marketing materials, customer information or anything else. Your RPO refers to how current your data needs to be if it needs to be recovered after a disaster. In other words, it’s a restore point rather like those used in the System Restore utility in Windows.
Financial departments and institutions may have a much more recent RPO than others, since lost transactions can quickly become extremely costly. Other companies might get away with recovering data from the previous day. Defining your RPO should be a primary consideration when you’re organizing your backup schedule. Ultimately, it’s about asking yourself what your company can afford to lose in terms of data.
Although RTO and RPO work together in some ways, and are both crucial elements of any disaster recovery plan, it’s important to realize that they’re still very different measures. The best approach is to consider RPO as the data you need to get your business back on its feet and RTO as the amount of time you need to get back to business as usual.
SpectrumWise offers a wide range of managed IT services including business continuity planning to help safeguard your operations in the event of a disaster. To find out how to prepare yourself for just about any eventuality, give us a call today.
