The statement that a backup exists says little about a company's resilience. What matters is how much data may be lost in an emergency, how long a business process may be down at most, and how quickly the emergency solution must be up and running afterward. RPO, RTO, and the maximum tolerable period of disruption translate these requirements into measurable targets for backup, replication, and recovery. They are a foundation for disaster recovery and business continuity management. The terms here follow BSI Standard 200-4 (the business continuity management standard of Germany's Federal Office for Information Security).
Three metrics, three questions
- Maximum Tolerable Period of Disruption (MTPD): How long may a business process be down at most before intolerable consequences occur for the company? In German, it is called maximal tolerierbare Ausfallzeit (MTA); other terms are MTPoD and maximum acceptable outage (MAO). It applies to the business process, not to an individual system, and is determined on the basis of an assessment of the potential damage.
- Recovery Time Objective (RTO): How long may it take from the declaration of the emergency until the required commissioning of the emergency solution? In German, it is called geforderte Wiederanlaufzeit (WAZ). The RTO is derived from the MTPD and assigned to the time-critical business processes and to the resources they need, such as an IT system. For IT resources, the emergency solution can be the switchover to a replacement system or a rollback to the last backed-up state.
- Recovery Point Objective (RPO): How old may the available data be at most so that it can still be used meaningfully in emergency operation? In German, it is called maximal zulässiger Datenverlust. The RPO determines how often backups must be made or whether continuous replication is required. If the backup runs once a night, in the worst case almost a full day's data can be missing.
Why the RTO must be shorter than the MTPD
The MTPD clock starts at the outage, the RTO clock only when the emergency is declared. In between lies the response time: the outage must be detected, reported, and classified, and the emergency declared. This time does not count toward the RTO but uses up part of the MTPD. BSI Standard 200-4 therefore requires that the RTO be strictly shorter than the MTPD, subtracts the response time from the MTPD, and additionally recommends a time buffer, because detection in particular is uncertain.
A worked example: if order intake may be down for at most 24 hours and the company, based on experience, needs up to 4 hours to detect an outage and declare the emergency, at most 20 hours remain for recovery. With a buffer, the RTO is set below that, for example at 16 hours. The system that order intake needs must be running again by then; its RTO must therefore not be longer.
Target and actual: RTA and RPA
RTO and RPO are target values. Whether they are achievable is shown by comparison with the values actually achievable: the recovery time actual (RTA, actual recovery time) describes how long it really takes from the declaration of the emergency to a productive emergency solution, and the recovery point actual (RPA) the data loss actually to be expected. The requirement is met if the RTA is at most as long as the RTO and the required level of emergency operation is achieved. This can be measured reliably in recovery and restore tests, for example with the restore test log.
Typical examples
- For an online shop, every order counts. A short RPO requires frequent backups or replication.
- For a file server, a nightly backup may be sufficient if the loss of one working day is acceptable.
- For the email system, quickly restoring sending and receiving is important. Older messages can follow in a second step.
What companies should keep in mind
- Define values together with the business departments, not by IT alone. The MTPD results from the business impact analysis, that is, from the consequences of an outage for the business.
- Take dependencies into account: an application often needs a database, an authentication service, and the network. These resources need an RTO that fits the RTO of the application.
- Know the response time for detection, alerting, and decision-making and subtract it in planning; the IT emergency handbook records alerting and recovery, and the IT emergency card the first steps.
- Consider the ransomware case separately: a clean restore point may be older, and checking for malware takes time. The backup checklist 3-2-1-1-0 shows how backups should be set up for this.
- Record agreed values with service providers in a service level agreement.
Norms and standards
BSI Standard 200-4 (Business Continuity Management) describes MTPD, RTO, and RPO in the chapter on business impact analysis and defines them in the accompanying glossary. According to the BSI, the standard is compatible with ISO 22301:2019 and additionally cites ISO 22317 for the business impact analysis. The BSI standard itself is available for free download from the BSI.
How TOMORIS relates
Within TOMORIS GRID, GRID.vault covers backup and recovery.