# RPO and RTO (Recovery Objectives)

> Source: https://netray.co/glossary/rpo-and-rto
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Glossary

## Short answer

RPO (recovery point objective) is the maximum acceptable data loss measured in time. RTO (recovery time objective) is the maximum acceptable time to restore service. Together they set ERP backup and disaster recovery design.

## Aliases

- RPO
- RTO
- recovery point objective
- recovery time objective
- ERP disaster recovery objectives

## Category

erp-core

## Full Definition

Recovery point objective (RPO) answers how far back in time you can afford to go after a failure. An RPO of 15 minutes means you can lose at most 15 minutes of transactions, so backups or replication must capture changes at least that often. Recovery time objective (RTO) answers how long the ERP may be unavailable. An RTO of 4 hours means service must be back within four hours of the incident.

The targets drive the technical choices. Nightly full backups give an RPO of up to a day. Adding frequent transaction log backups can bring that down to minutes. Synchronous or asynchronous database replication, such as SQL Server Always On availability groups, reduces both RPO and RTO but costs more in licensing, network and operations. A cold restore from backup to new hardware may take many hours or days.

Different systems deserve different targets. The ERP database, file stores for attachments, the integration layer, EDI connections, license servers and the identity provider all need to be recoverable, and the recovery order matters. A restored ERP that cannot authenticate users or reach its integration queue is not recovered in any useful sense.

Targets only count if tested. Run a restore drill at least annually, time it, and compare the result with the stated RTO. Most plants discover gaps such as missing encryption keys, outdated runbooks or backups of the wrong database during the first test, not during a real outage.

## Why It Matters

- A production plant can lose shipping, receiving and scheduling within minutes of an ERP outage, so the cost of downtime should set the targets.
- Untested backups are a common cause of failed recoveries after ransomware.
- Business owners, not just IT, must agree the targets because tighter objectives cost significantly more.
- Customer contracts and cyber insurance often require documented and tested recovery objectives.

## In Practice

A manufacturer sets an RPO of 15 minutes and an RTO of 4 hours for its ERP. It enables log backups every 10 minutes copied offsite, keeps a warm standby database in a second location, and documents the restore order: database, application, identity, integrations. A first drill takes 7 hours because the offsite copy lacked a key, which is fixed before the next test.

## Faq

### Which is more expensive to improve, RPO or RTO?

**Answer:** Both rise in cost as they approach zero. Lower RPO needs more frequent capture or replication, and lower RTO needs standby systems and automation, so the right target depends on downtime cost.

### Is a backup the same as disaster recovery?

**Answer:** No. A backup is a copy of data. Disaster recovery is the tested ability to restore the whole service, including applications, identity and integrations, within agreed objectives.

### How often should an ERP restore be tested?

**Answer:** At least once a year, and after major changes such as upgrades or moves. Time the exercise and compare it with the RTO.

## Search terms

RPO and RTO, recovery point objective ERP, recovery time objective, ERP disaster recovery, ERP backup strategy, ERP high availability, disaster recovery plan manufacturing, what is RTO

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json