RPO and RTO
RPO and RTO are the two key metrics of disaster-recovery and business-continuity planning. The RPO (Recovery Point Objective) defines the maximum amount of data loss a company can tolerate, while the RTO (Recovery Time Objective) defines the longest a system such as the ERP may stay down after an outage before it is productive again.
RPO and RTO are two target figures companies use to define how resilient their IT systems must be against outages. The Recovery Point Objective (RPO) answers the question "How much data loss is acceptable at most?" and thus describes the permissible interval between the last usable backup and the outage. The Recovery Time Objective (RTO) answers the question "How long may a system stay down at most?" and sets the maximum tolerable downtime until recovery. Both values are expressed in units of time – from seconds through hours to whole days.
Unlike a backup or a recovery procedure, RPO and RTO are not technology but business requirements: they state how bad an outage may be from a business perspective and derive from that which technical measures are needed. For an ERP system, where orders, stock, invoices and accounting all come together, they are especially relevant – here every hour of downtime and every lost record costs money and trust directly. RPO and RTO translate this risk into measurable, verifiable figures that can be contractually guaranteed.
At a glance
- RPO = maximum tolerable data loss (how old the last backed-up state may be)
- RTO = maximum tolerable downtime (how long the system may stay down)
- RPO drives the backup/replication frequency, RTO the restart technology
- Both values are business requirements, not technology – the shorter, the more expensive the protection
- With cloud/SaaS ERP, RPO and RTO are in the SLA and should be checked before signing the contract
What exactly do RPO and RTO mean?
RPO and RTO measure two different dimensions of the same outage: the RPO looks back into the past and measures lost data, the RTO looks forward and measures lost time. Both are defined individually per system or process, because not everything is equally critical. A starting point for both values is the business impact analysis, which for each business process estimates the damage caused per hour of downtime and per amount of lost data.
RPO – the maximum tolerable data loss
The Recovery Point Objective denotes the point in time to which a system can be reset after an outage without the damage becoming unacceptable. An RPO of one hour means: in the worst case, the data of the last hour before the outage is lost. The RPO therefore directly sets the minimum backup frequency – an RPO of one hour requires at least hourly backups, an RPO close to zero requires continuous replication. The closer the RPO gets to zero, the more complex and expensive the technology becomes.
RTO – the maximum tolerable downtime
The Recovery Time Objective defines how much time may pass at most between the outage and the restoration of productive operation. An RTO of four hours means: four hours after the outage the ERP must be usable again. The RTO covers the entire path back – fault detection, provisioning of the target environment, restoring the data state, startup and verification. Short RTO values require standby failover systems or automatic switchover (failover), while long RTO values can be met by a simple restore from backup.
How RPO and RTO interact and what they cost
Although RPO and RTO are defined separately, they are closely linked economically: both drive the cost of protection, and the stricter the requirements, the higher the effort. A very short RPO requires frequent or continuous data mirroring, a very short RTO a permanently available secondary environment. In practice, companies therefore group their systems into classes (tiers): business-critical systems such as the ERP get low values, less important systems higher ones.
The difference between target value and actual value is important. RPO and RTO are requirements – what is actually achieved only shows in a real incident or a test. The recovery time actually measured is sometimes called the Recovery Time Actual (RTA). If the RTA regularly exceeds the agreed RTO, the protection is under-dimensioned. That is why documented tests, in which recovery is rehearsed and the time is measured, belong to any serious planning.
Distinction from MTD and WRT
Several further metrics exist around RPO and RTO. The Maximum Tolerable Downtime (MTD) describes the absolute upper limit beyond which an outage becomes existentially threatening; the RTO must always be smaller than the MTD. The Work Recovery Time (WRT) is the time still needed after technical restart to check and re-enter data until normal operation is truly re-established. Simplified: MTD = RTO + WRT. Anyone who plans only the RTO and forgets the follow-up work underestimates the actual downtime.
RPO and RTO in the ERP system
In an ERP context, RPO and RTO are especially demanding because the system rarely stands alone: shops, marketplaces, shipping providers, payment providers and accounting are connected to the ERP via interfaces. A low RPO therefore concerns not only the ERP database, but also the question of how orders, stock postings and incoming payments that occurred during the outage are cleanly re-processed after recovery. Too generous an RPO can lead to overselling or duplicate postings here.
How the target values can be implemented depends heavily on the operating model. With a cloud or SaaS ERP, the provider operates the infrastructure and guarantees RPO and RTO in the service-level agreement – often with geo-redundant data centers and automatic backups. Customers should explicitly ask for these values before signing the contract, because "highly available" alone says nothing about the guaranteed data state. With an on-premise ERP, the company defines RPO and RTO itself and must organize backup, failover environment and tests on its own.
DACH specifics: GDPR, retention and proof
In the German-speaking region, RPO and RTO are relevant not only from a business perspective but also legally. Article 32 of the GDPR requires the ability "to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident" – which presupposes that a company has defined recovery objectives at all. Appropriate RPO and RTO values are thus part of the required technical and organizational measures.
Added to this are the tax retention and GoBD obligations: accounting-relevant ERP data must remain audit-proof and recoverable for many years. A low RPO protects current operations, while long-term archiving secures the statutory proof – both belong in a well-thought-out concept. Anyone who outsources operations to a cloud provider remains responsible under data-protection law and should document, alongside RPO and RTO, also the server location, certification (such as ISO 27001) and the contractually guaranteed timeframes. A robust, tested RPO/RTO plan is thus at the same time part of the duties of care and proof.
Example
Example: RPO and RTO for a trading company
A wholesaler with around 1,200 orders per day runs its ERP as a cloud solution. In the business impact analysis, the company calculates that every hour of ERP downtime costs about 4,000 euros in lost revenue and additional effort, and that a loss of more than 15 minutes of order data seriously jeopardizes stock synchronization with the online shop. From this it derives an RPO of 15 minutes and an RTO of two hours for the ERP.
With these figures the merchant enters the vendor selection. A system that only guarantees daily backups and an RTO of eight hours is ruled out – the possible data loss and downtime would be too large. The choice falls on a provider with continuous replication (RPO a few minutes) and geo-redundant failover (RTO under one hour), whose SLA contractually guarantees these values. An annual recovery test confirms that the guaranteed values are actually achieved in practice.
Frequently asked questions
Matching ERP systems
Related services
Sources
Questions about RPO and RTO in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.