The Latest Arcserve News
Product and Solution Information, Press Releases, Announcements
|Your Disaster Recovery Planning 101: RTOs vs. RPOs|
|Posted: Tue Oct 13, 2020 08:50:16 AM|
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:
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:
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.
Orignal Post by Arcserve