Backup and Disaster Recovery Planning with RPO and RTO
Before choosing software, a backup plan should answer two business questions: how much data loss is acceptable, and how quickly must systems be working again? RPO and RTO give the technical team and business management a shared way to express these expectations.
Key takeaways
- ✓RPO defines the acceptable data loss window; RTO defines the target time for restoring a service.
- ✓Systems have different levels of criticality: classify targets by business impact.
- ✓Verify backup effectiveness through regular restore tests.
- ✓A technical backup alone is insufficient for a recovery plan without credentials, documentation and a communication plan.
What is RPO?
The Recovery Point Objective (RPO) expresses how far back in time the business can afford to recover after an interruption. For example, if work order data has a 30-minute RPO, the backup or replication design should target no more than 30 minutes of data loss.
RPO is not simply the backup frequency. Application consistency, database logs, connection capacity and whether the backup actually reaches its destination also affect the ability to meet this target.
What is RTO?
The Recovery Time Objective (RTO) is the acceptable time for restoring a service after an interruption. It includes obtaining hardware, downloading data, starting virtual machines, configuring networking and identity, and completing validation.
A very short RTO may require more redundancy, automation and regular testing. The target should therefore be set by assessing the cost of the solution alongside the business cost of an outage.
Classify systems by business impact
Classify business processes rather than server names. Two applications on the same server may have different tolerances for data loss and downtime.
- Critical: systems whose interruption stops production, dispatch or essential customer services
- High: systems that can tolerate a brief interruption but must return during the working day
- Normal: applications whose work can temporarily continue through an alternative process
- Archive: historical or legally required records whose unavailability does not stop daily operations
Make the 3-2-1 approach testable
The widely used 3-2-1 approach recommends maintaining at least three copies of data across two different types of media, with one copy off-site. For ransomware protection, an offline or immutable copy makes it harder for privileges compromised in production to be used against backups.
- Separate permissions and MFA for the backup destination
- A copy protected against deletion or modification
- Application-consistent backups for critical systems
- Alerts for failed jobs, capacity and retention periods
How should restore testing be planned?
The test record should identify the source backup, start and finish times, steps followed, errors and corrections, and business team approval. RPO and RTO remain aspirations until actual results are compared with the targets.
- Monthly: restore a selected file or mailbox item
- Quarterly: start a critical application or virtual machine in an isolated environment
- Annually: run a disaster tabletop exercise and communication rehearsal with business teams
- After every significant change: verify the new system's backup and recovery coverage
Related guides
Sources
This guide provides general information. Define implementation requirements around your business risks and infrastructure.