An SLA states that the customer portal's database must be back in service within two hours of any outage. The current plan restores from off-site backups, a process the last test timed at six hours. Which metric is the SLA defining, and what does the test result mean?
Select an answer to reveal the explanation.
Short Explanation
RTO is the stopwatch: from 'it's down' to 'it's back.' You've got a two-hour stopwatch and a six-hour recovery, so the plan fails no matter how safe the backups are. Taking backups more often fixes data loss, not downtime.
Full Explanation
The recovery time objective is the maximum acceptable time to restore a service after an outage. A requirement that the database be back in service within two hours is an RTO of two hours. The tested restore from off-site backups took six hours, so the current method cannot meet the objective; the team needs an approach whose tested recovery time fits within two hours, such as a warm or hot standby kept current by log shipping or replication, or local backups with faster restore paths, followed by a new timed test. Calling the requirement an RPO confuses downtime with data loss; more frequent backups would reduce the amount of data lost but would not shorten a six-hour restore. Concluding that the method meets the RTO because backups are stored off-site mixes up protection with speed; off-site storage protects against site loss but often lengthens recovery because the backups must be retrieved and transferred. Mean time to repair is a historical average across incidents; an average does not satisfy a per-incident commitment, and the tested recovery is three times the target. Exam caveat: only a tested, timed recovery demonstrates that an RTO can be met. Operational check: after choosing the new approach, time a full failover or restore drill and compare it with the two-hour objective.