Transit dispatch can lose at most a few minutes of data, while a low-priority archive can tolerate overnight loss. How should recovery objectives influence backup versus replication choices?
Select an answer to reveal the explanation.
Short Explanation
How much data and downtime you can stand should pick the tool. Tight objectives push you toward continuous replication; looser ones can live on nightly backups. One blunt yearly tape for everything ignores what the business actually needs.
Full Explanation
Business-driven recovery objectives decide backup and replication architecture for city workloads. Recovery point objective (how much data loss is tolerable) and recovery time objective (how long downtime is tolerable) tell architects whether nightly backups are enough or whether continuous replication, synchronous mirrors, or hot standbys are required. Tight objectives for 911-adjacent or payment systems push toward near-continuous protection; looser objectives for archival reporting can accept overnight loss at much lower cost. Matching technology to RPO and RTO prevents both under-protection and expensive over-engineering. Mandating only yearly offline tapes for every system regardless of RPO and RTO ignores workloads that cannot tolerate year-scale loss or multi-day restores. Choosing replication for every workload even when overnight loss is acceptable wastes budget without improving outcomes the business actually needs. Ignoring business recovery needs and standardizing on the cheapest monthly USB copy inverts the design order: tools must follow objectives, not the reverse. Exam caveat: Security+ repeatedly tests that RPO/RTO drive control selection—pick the answer that starts from business need, not from a favorite technology. Operational check: document RPO and RTO per municipal system tier, map each tier to a backup or replication method that can meet those numbers, and prove the mapping with timed restore tests rather than configuration screenshots alone.