For enterprise IT teams, disaster comes in many forms. Sometimes it’s a hurricane; other times it’s a successful ransomware attack. Then there’s that time your system upgrade goes horribly, horribly wrong, and three month’s worth of sales data vanishes into the ether.
On the surface, these disasters are completely unrelated, but they all have one thing in common: Organizations with a disaster recovery plan will find them a lot less painful.
A comprehensive disaster recovery plan is the blueprint companies need to follow to restore system functions and preserve data in the event of an unplanned outage. When such a plan is included as part of the larger business continuity plan, organizations can feel confident that business operations will suffer minimal downtime and near 0 percent data loss after a disaster.
Organizations that don’t have a formal disaster recovery plan—or that have one that is out of date—may find themselves neck-deep in financial, regulatory, and legal trouble after a security event or natural disaster that results in a system outage. With today’s unprecedented level of uncertainty, spanning a global health crisis to extreme weather events to increasingly aggressive and damaging cyberthreats, it’s irresponsible not to have a thoroughly tested disaster recovery plan in place.
Add Recovery Time Objective and Recovery Point Objective to Your Disaster Recovery Plan
In an ideal world, every application would automatically failover and its data would continuously backup, so downtime and data loss would be non-issues. Although these capabilities are technically possible, in reality, it would be cost-prohibitive for the majority of organizations to support.
Defining recovery time objectives and recovery point objectives as part of your disaster recovery plan is the next best thing.
Recovery Time Objective (RTO)
RTO is the metric that defines how long an application can be down before the business is significantly harmed. Some applications can be down indefinitely without causing harm. Others can’t be unavailable for more than a few seconds before the business, customers, or internal users are negatively affected.
This is why RTOs are calculated based on application importance:
- RTO near zero: Require failover services for mission-critical applications
- RTO of four hours: Allows time for on-site recovery from bare metal restore to full application and data availability
- RTO of eight or more hours: For applications that can be down for days without serious damage to the business
When calculating RTOs, remember you aren’t just looking at the time between the onset of the outage and recovery. You also need to define the steps to take to recover from specific types of disaster. Restoring an application and its data after a power outage is likely faster than restoring it after a wildfire.
It is important to make RTOs as accurate as possible. If an RTO is too short, you will spend extra time and money trying to protect a resource that perhaps isn’t that critical. If an RTO is too long, there may be a negative impact caused by the resource being unavailable for longer than it should be.
Recovery Point Objective (RPO)
RPO is the maximum acceptable amount of data that can be lost before the business is significantly impacted. Essentially, it’s the amount of time between the outage and the most recent fully functioning backup.
Backups can get expensive fast, so RPO is based on balancing your budget against an application’s importance:
- RPO of near zero: Use continuous replication (mission-critical data)
- RPO of four hours: Use scheduled snapshot replication
- RPO of 8-24 hours: Use existing backup solution (data that can potentially be recreated from other repositories)
The impact of getting your RPO wrong varies depending on the importance of the application. You may just waste money backing up less-important data too frequently, or you may lose hours of irreplaceable transaction data by backing up too infrequently.
How RTO and RPO Are Related and Why You Need Both
RTO and RPO are both essential factors in successful disaster recovery. Together, they ensure critical business operations are up and running quickly and that your most valuable data isn’t lost.
Near-zero RTO or RPO for every application is unrealistic and impossibly cost-prohibitive. Therefore, when calculating RTO and RPO, you have to prioritize applications and data by importance and by risk.
For example, you may have an application that isn’t used frequently but that generates highly regulated data. Downtime or data loss could result in financial penalties, so this application requires near-zero RTO and RPO, which you get by combining failover services with continuous replication.
Disaster recovery planning is an essential business function, and setting appropriate RTOs and RPOs is an important component of your disaster recovery plan. To ensure you are getting the highest level of protection from downtime and data loss, look to the cloud.
A direct-to-cloud backup and disaster recovery as a service (BaaS/DRaaS), such as Arcserve UDP Cloud Direct, lets you easily manage backup and disaster recovery with industry-best RTOs and RPOs. Download How to Build a Disaster Recovery Plan for more tips on how to bounce back from an unplanned outage with minimal downtime and data loss.
