Recovery time objective (RTO) defines the acceptable duration of downtime after a failure or disaster. It is a business requirement used to shape a database recovery strategy, not a default number to apply to every system. section 12.1 section 12.12
RTO differs from recovery point objective (RPO). RPO sets acceptable data loss; RTO sets acceptable outage time. A plan can meet one requirement while missing the other, so both must be agreed before choosing schedules, recovery models, or restore methods. section 12.1 section 12.12
Avoid the “one schedule fits all” mistake:
- Ask the application owner what outage duration causes unacceptable business impact, rather than accepting “instant recovery” as an unexamined requirement. section 12.1
- Compare the requested recovery time with the cost of redundant, geographically dispersed infrastructure. Very short recovery requirements may justify high availability and disaster recovery; lower-priority systems may reasonably use backup and restore. section 12.1
- Set backup and recovery arrangements to the agreed RTO and RPO. A default schedule can either leave an application exposed or consume unnecessary backup storage and resources. section 12.1 section 12.12
A priority mismatch
A P4 application may not justify a highly available topology when its business impact permits recovery through backup and restore. Conversely, treating every database as though it can tolerate an hour of disruption can create a serious problem when its agreed limit is shorter. section 12.1 section 12.1
Recovery capability must be real, not assumed. Backup validation and a workable restore sequence support the recovery strategy; untested or failed backups can turn an apparently acceptable RTO into a prolonged outage. section 12.0 section 12.12
