# Highly Available System Metrics  (B)

+ Define recover time objectives (RTOs)
  + Refers to the maximum amount of time a business system can tolerate being out of service, that is, the shortest time it takes for a business system to recover service functionality from a disaster
+ Define recover point objectives (RPO)
  + The amount of data loss a business system can tolerate, expressed in time, is the time between a disaster and the last backup of the data


![left](./student-guide/diagram/28-Highly-available-evaluation-indicators-02-01.png)


![right](./student-guide/diagram/28-Highly-available-evaluation-indicators-02-02.png)

------------------------------------------------------------
Define recover Time Objective (RTO)
RTO, recover time objective, recovery time objective, refers to the maximum time that a business system can tolerate to stop service, that is, the shortest time it takes for a disaster to recover the service function of the business system. The indicated time between the occurrence of the disaster and the recover of system services.
For example, if the RTO is 1 hour, this means that the time to tolerate a business system outage is 1 hour, that is, the business can continue normally even though the business system cannot be serviced within 1 hour. If business systems are not recoverable after 1 hour, the business may suffer irreparable losses.


Define recover point objectives (Recovery Point Objective, RPO)
RPO, recover Point Objective, Recovery Point Objective refers to the amount of data loss that a business system can tolerate. As shown in the figure above, how far back? The time between when the indicated disaster occurred and the most recent backup of the data.
For example, business system data is backed up at 0:00 every day, and an accident occurs at 8:00 a.m. one day, resulting in eight hours of data loss. If the original business system RPO was set to 24 hours, this is not a big deal, but if the RPO is 4 hours, the business will be impacted and lost.


Both RTO and RPO are measured using time. For RTO time, this is the time between the disaster and the recover of the service, which also includes the time for data recover. For RPO time, this is the time between the disaster and the last backup of the data.

While both RTO and RPO are measured in terms of time, they are used for different purposes. RTOs focus on application or system availability, and while RTOs include time to recover data, they describe more of a time limit for application downtime.
The RPO focuses on data integrity and describes the maximum data loss limit that can be tolerated. Unavailability of business system services can result in financial losses, but if customer transaction data is lost, the loss is even more catastrophic.

RTO and RPO objectives need to be considered when developing an enterprise disaster recovery plan; however, there are differences in the cost of RTO and RPO objectives. The cost of maintaining a demanding RTO objective can be higher than an RPO objective because it involves the entire business infrastructure, not just the data.
To implement RPO objectives, only data backups are performed at the correct intervals, and data backups can be easily automated, so an automated RPO strategy is easy to implement. On the other hand, fully automated RTO policies are more complex to implement because RTOs involve the recover of all IT operations.

Both RTO and RPO are important for disaster recovery planning. Each enterprise business scenario is different, which requires us to select the appropriate RTO and RPO targets based on the actual situation to maximize economic benefits.