A retailer's finance director says the checkout database may lose up to one hour of orders in a disaster, but the checkout service must be running again within fifteen minutes. How should the DBA record these objectives?
Select an answer to reveal the explanation.
Short Explanation
Here's the trick to keep them straight: RPO is the Point you rewind to, so it's about lost data; RTO is the Time on the clock until you're back. An hour of lost orders is the RPO, fifteen minutes of downtime is the RTO. Swap them and you'll build the wrong recovery system.
Full Explanation
The recovery point objective measures tolerable data loss, looking backward from the incident to the last recoverable point. The recovery time objective measures tolerable downtime, looking forward from the incident to restored service. The director accepts losing up to one hour of orders, which is an RPO of one hour, and requires service back within fifteen minutes, which is an RTO of fifteen minutes. These objectives lead to different design choices: the one-hour RPO allows log backups or asynchronous replication at intervals up to an hour, while the fifteen-minute RTO requires a standby that can be promoted quickly rather than a restore from backup media. Recording an RPO of fifteen minutes and RTO of one hour swaps the two, producing more frequent backups than required while allowing a recovery four times slower than the business accepts. Setting both to fifteen minutes overstates the data-protection requirement, which adds cost without a business mandate. Setting both to one hour understates the downtime requirement and would permit a recovery approach that leaves checkout offline far longer than allowed. Exam caveat: the two objectives are independent, and a scenario often gives them with very different values. Operational check: document both objectives in the DR plan and confirm that the chosen replication interval and tested failover time meet each one.