When designing a backup and recovery solution, it is important that everyone in your organization uses the same vocabulary. Whether they are in accounting, marketing, or IT, two acronyms that constantly pop up are RPO and RTO. What do they stand for and how are they related to IT?
In the event of a system outage or a disaster, the term RTO comes into play. RTO, recovery time objective, is the amount of time it takes your organization to return its core business function up and running again. This includes getting your email server back running again, and other applications up.
RTO is defined in a service level agreement (SLA) between a company's VP of operations and its IT department. RTO is a pre-agreed estimated amount of time of how long the business can tolerate an interruption in its core business function. In other words, it is a promise that your organization will be up and running in no more time than stated in the RTO. The RTO is revisited as the organization grows.
Business can be up and running sooner from an interruption or power outage but the purpose of a RTO is to plan the maximum time their operations will be down. It can be measured in minutes or hours. For instance, a business like Netflix, which provides movies on-demand, loses significant business every minute a customer can't access their instant movie service. The preferred RTO should be in minutes. But because of the nature of the number of servers and data that may not be possible.
Company's RTO dictates what type of backup medium (such as magnetic tape or disk) the IT department uses. It also affects backup infrastructure, whether it is a high-availability cluster for seamless failover or something less costly. When the RTO is near zero, meaning almost no downtime can be tolerated, a completely redundant storage device may be required, so that in the event of a system interruption, one server can be unplugged and a virtual server can be activated.
RTO's that are stated as less than a few hours include funds transfer, online banking, trading, and ATM applications. Email functions and call center software can generally not tolerate downtimes of more than a few minutes.
Once you have defined the RTO in your SLA, you need to think about your recovery point objective, or RPO, which is the amount of data loss you are willing to trade-off between frequency of backups and loss of data. If you back up every two hours, for example, you could lose two hours' worth of data. If you want to reduce your RPO to 15 minutes, you need to do incremental backups every 15 minutes. Imagine only backing up every three hours and losing three hours of valuable data if a disaster or power outage occurred?
RPO should be determined by incorporating your company's business objectives. In a mission critical environment, such as online data transaction processing, an acceptable RPO may be less than 15 minutes. In a non-mission-critical application, such as a seldom-accessed storage repository, a 30 minute RPO might be okay.
Setting an RTO and RPO influences your frequency of backups and where you are backing up to (virtual machine, physical server, or cloud). The tighter the RTO and the tighter the RPO, the more significant your backup solution investment, but obviously, best practice is to match your recovery times with your business objectives.
Learn more about backup and restore solutions by visiting AppAssure and downloading a free software trial.
In the event of a system outage or a disaster, the term RTO comes into play. RTO, recovery time objective, is the amount of time it takes your organization to return its core business function up and running again. This includes getting your email server back running again, and other applications up.
RTO is defined in a service level agreement (SLA) between a company's VP of operations and its IT department. RTO is a pre-agreed estimated amount of time of how long the business can tolerate an interruption in its core business function. In other words, it is a promise that your organization will be up and running in no more time than stated in the RTO. The RTO is revisited as the organization grows.
Business can be up and running sooner from an interruption or power outage but the purpose of a RTO is to plan the maximum time their operations will be down. It can be measured in minutes or hours. For instance, a business like Netflix, which provides movies on-demand, loses significant business every minute a customer can't access their instant movie service. The preferred RTO should be in minutes. But because of the nature of the number of servers and data that may not be possible.
Company's RTO dictates what type of backup medium (such as magnetic tape or disk) the IT department uses. It also affects backup infrastructure, whether it is a high-availability cluster for seamless failover or something less costly. When the RTO is near zero, meaning almost no downtime can be tolerated, a completely redundant storage device may be required, so that in the event of a system interruption, one server can be unplugged and a virtual server can be activated.
RTO's that are stated as less than a few hours include funds transfer, online banking, trading, and ATM applications. Email functions and call center software can generally not tolerate downtimes of more than a few minutes.
Once you have defined the RTO in your SLA, you need to think about your recovery point objective, or RPO, which is the amount of data loss you are willing to trade-off between frequency of backups and loss of data. If you back up every two hours, for example, you could lose two hours' worth of data. If you want to reduce your RPO to 15 minutes, you need to do incremental backups every 15 minutes. Imagine only backing up every three hours and losing three hours of valuable data if a disaster or power outage occurred?
RPO should be determined by incorporating your company's business objectives. In a mission critical environment, such as online data transaction processing, an acceptable RPO may be less than 15 minutes. In a non-mission-critical application, such as a seldom-accessed storage repository, a 30 minute RPO might be okay.
Setting an RTO and RPO influences your frequency of backups and where you are backing up to (virtual machine, physical server, or cloud). The tighter the RTO and the tighter the RPO, the more significant your backup solution investment, but obviously, best practice is to match your recovery times with your business objectives.
Learn more about backup and restore solutions by visiting AppAssure and downloading a free software trial.
SHARE
