The IT industry is notorious for its abundance of acronyms, so it’s easy to confuse things like recovery point objective (RPO) and recovery time objective (RTO). At first glance, RPO and RTO do seem similar. Both are key metrics in business continuity/disaster recovery (BC/DR). Both involve recovering IT assets, applications, and/or data after a business disruption.
So, what’s the difference between the two data protection concepts?
Know Your RPO
RPO refers to the point back in time from which you want your critical data restored after a system disruption or failure. It tells you how much time from the point of the outage you can afford to lose. RPO can be measured in intervals ranging from minutes, hours, or even days. A smaller RPO means that less data is lost, which is critical for normal business operations.
RPO also determines the frequency with which you’ll need to replicate data from your production site to a DR site. To achieve a smaller RPO, you need more frequent backups. If your RPO for an application is one hour or less prior to the disaster, you’ll need to replicate data at least hourly.
If you can’t afford to lose any data at all for any amount of time, you’ll need to implement synchronous replication for that application. That means your data must be written to a DR site at the same time it’s being written at your production site.
Keep in mind that the lapse after your last backup translates into lost data, and can have major repercussions if your business relies on that data for its normal operations. However, it may not be cost-effective ─ or necessary ─ to back up everything or to back it all up frequently. The more frequently you back up, the more copies you must maintain. Storing backups comes with costs, as well as security needs.
To define RPO and RTO for your organization, you’ll need to answer several questions, including:
Which of your IT assets, applications, and data are most important for ensuring your business can keep operating?
Which assets, applications, and data would you need access to first following a disaster?
Which assets, applications, or data could wait, and for how long?
Following these steps will help with the answers:
Step 1: Inventory your assets, applications, and data to determine what you have, where they reside, and how they’re used. Get input from others within your company as “shadow IT” could have introduced essential data and applications without the knowledge of your IT department. Identify any application and system dependencies.
Step 2: Perform a business impact analysis (BIA) to determine the operational, financial, and reputational effects to your business if your IT assets applications and data weren’t available. Look at them individually. Determine their importance to your company’s ability to conduct business. Establish the priorities for restoring business functions and related data or applications. Don’t forget about any compliance requirements.
Step 3: Conduct a risk assessment to examine the vulnerability of your IT assets to events that can cause downtime. Look at all possible disaster scenarios, as well as weaknesses that could make your IT assets susceptible to a manmade or natural disaster or other business disruption.
Step 4: Review your current BC/DR plan. If you don’t have a formal plan in place, make note of how your organization is handling backups and other elements commonly found in BC/DR plans.
Step 5: Consult third-party companies that specialize in BC/DR. They can help you with these steps, as well as evaluate the various strategies for achieving your company’s RPO and RTO requirements.
Or talk to a US Signal expert. Call 866.2. SIGNAL or email [email protected].
Additional Disaster Recovery Resources
To learn more about disaster recovery and managed DR services, check out these articles below from our blog or visit our resource center for whitepapers, e-books and more!