Business owners state that the order-processing database can tolerate losing at most five minutes of committed transactions in any disaster. The DBA currently takes only nightly full backups. Which metric did the business define, and what must change?
Select an answer to reveal the explanation.
Short Explanation
RPO looks backward: how much data can you afford to lose? Five minutes of transactions means your backups or replication have to grab changes at least that often. RTO looks forward, at how fast you're back up, which is the trap answer here.
Full Explanation
The recovery point objective is the maximum acceptable amount of data loss, expressed as time before the incident. A five-minute tolerance for lost transactions is an RPO of five minutes. To meet it, changes must be captured and stored away from the primary at least every five minutes, for example transaction log backups taken and copied off the server at that interval, or replication to another system with lag kept below five minutes. Nightly full backups give an RPO of up to roughly 24 hours, because a failure late in the day loses everything since the previous night. Calling the requirement an RTO confuses data loss with downtime; the recovery time objective is how quickly service must be restored, a separate requirement the business has not stated here. Claiming nightly backups satisfy the requirement because a full backup contains all transactions ignores that it contains only the transactions committed before the backup ran. Mean time between failures is a reliability statistic for components, not a recovery objective, and replacing hardware does not bound data loss. Exam caveat: RPO drives backup and replication frequency; RTO drives recovery method and standby design. Operational check: monitor the age of the newest off-server log backup or the replication lag and alert when it exceeds five minutes.