How recovery-time and recovery-point objectives shape network recovery design, testing, and failback.
Disaster recovery (DR) is the planned restoration of services after a disruptive event. A useful DR plan maps business needs to technical recovery procedures, dependencies, communications, and regular exercises.
Recovery time objective (RTO) is the maximum acceptable time for a service to be unavailable. Recovery point objective (RPO) is the maximum acceptable amount of data loss, commonly expressed as time. RTO addresses speed of restoration; RPO addresses how current the restored data must be.
| Objective or model | Meaning |
|---|---|
| RTO | Maximum tolerable service outage duration |
| RPO | Maximum tolerable age of recovered data |
| Cold site | A location with basic facilities; systems must be supplied, restored, or built before use |
| Warm site | A partially prepared environment that needs activation or restoration work |
| Hot site | An environment ready or nearly ready for rapid service restoration |
| Active-passive | One environment serves production while another is ready to take over |
| Active-active | Multiple live environments serve production work |
The terms cold, warm, and hot are relative. A provider’s “warm” offering may be more automated than another organization’s “hot” arrangement, so define expected capabilities and test them instead of relying on the label.
1services:
2 dhcp:
3 rto: 15m
4 rpo: not-applicable
5 recovery: warm-standby
6 configuration-archive:
7 rto: 4h
8 rpo: 1h
9 recovery: replicated-secondary
Different services can legitimately have different objectives. A low RTO and low RPO generally require more automation, replication, capacity, and operational discipline than a service that can be restored later from periodic backup.
A written procedure is not evidence that recovery will work. Exercises should verify the recovery sequence, credentials, backup integrity, required network paths, DNS and identity dependencies, monitoring, stakeholder communication, and failback to the normal environment. Record timing and gaps, then update the plan.
Common exercise forms include a tabletop review, a component restore, and a controlled failover. Choose the least disruptive form that provides useful evidence, and periodically run a deeper test for critical services.
Recovery work depends on current configuration and records. Keep Network Configuration Management and Backups and Network Documentation, Diagrams, and IPAM current so a recovery team starts with trustworthy information.