A backup product can tell you its recovery point objective. It cannot tell you what losing an hour of dispatch data does to a shift. Vendors treat recovery as a storage problem, selling RPO and RTO as configuration sliders in an appliance console. In a mission-critical environment, recovery is an operational problem. You do not buy continuity by increasing snapshot frequency.
For a payroll system, an RPO of twenty-four hours means someone re-enters timesheets. For a border control biometric matching system, an RPO of twenty-four hours means a person who should have been flagged walks through because the watchlist updates from the last six hours are missing. The datasheet RPO is a promise made in a room with no users in it.
If you write “RPO 0, RTO 0” into a procurement document, you get marketing language back. You also get a highly complex, fragile clustering architecture. A vendor might deliver sub-millisecond synchronous replication across two availability zones. That instantaneous replication just means you corrupt your backups at the exact same speed you corrupt your primary data when a ransomware variant hits the primary storage. The useful move is writing objectives in mission terms. Specify that no more than five minutes of unit-location data can be lost during a failover, and require the vendor to map that outcome to their architecture in writing. The vendor’s architecture is their problem. The mission outcome is yours.
Mission-critical does not mean zero downtime. It means the function continues. Those are different requirements that lead to different architectures. Most systems already have a degraded mode. It is usually called a phone call, a whiteboard, and a paper log. The question is whether you have designed and rehearsed that state, or whether you are going to invent it at 0300 under pressure.
Consider a maritime patrol vessel that loses its satellite uplink while tracking an unregistered freighter. The centralized threat analysis system is unreachable. Instead of a dead screen, the ship’s local terminal drops into a read-only mode, serving a twelve-hour-old cached replica of the regional vessel database. It cannot process new intelligence, but the crew can still pull the freighter’s history and structural blueprints. The operational RTO is zero, achieved through local persistence rather than rapid network recovery.
Define what the function looks like at fifty percent capability, at ten percent capability, and at zero system capability. Each of those states needs an owner and a procedure. If the degraded-mode procedure is in an appendix nobody has opened since the last audit, you do not have a degraded-mode procedure. A manual workaround is a system. It has an RPO, an RTO, and a failure mode. It just does not have a product manager.
The heaviest technical debt in a mission-critical outage is the reconciliation process. When a computer-aided dispatch system goes offline, dispatchers revert to radios and physical cards. The operation continues. Four hours later, IT declares the system recovered. The immediate problem is not that the software is running again. It is that the database is now four hours out of sync with the physical reality of the deployed units.
A records management system restored from backup after an outage might show a clean restore. But if twenty minutes of entries typed into a local spreadsheet during the outage never get merged, a warrant status remains wrong for two days. Reconciliation is the tax you pay for operating in degraded mode. Any degraded-mode operation generates reconciliation debt. You must design who reconciles the analog data, against what source of truth, and how conflicts get resolved. If staff create records during an outage, reconciliation is part of recovery. If it is not in the plan, it is happening anyway, just without an owner.
Testing continuity under ideal conditions is testing whether the plan works when nothing has gone wrong. You do not test a system’s resilience by gracefully shutting down a server on a Sunday morning with the A-team. You test it by pulling the power cord while the database is writing under peak load, during a shift change, with the network degraded.
A dispatch center losing its primary system during a multi-agency incident will fall back to radio and a paper log. It works for ninety minutes. At hour three, the supervisors are reconciling three different paper logs against each other and nobody can say which unit is assigned to which call. The manual workaround has a shelf life. A unit can run on radios and paper for a shift. It cannot run that way for a week without someone making a policy decision about what gets dropped.
Command-and-control systems have a property most enterprise systems lack: the operator may be the only person who knows the current state of the world, and that state is not fully in the database. Continuity has to account for the human-held state. Furthermore, a secondary site is not a continuity plan for people who cannot reach it. If your failover strategy requires a steering committee call to authorize the DNS swap, your recovery time is measured in politics, not minutes. A redundant application may still depend on a single way to sign in.
When the mission owner, the architect, and the vendor collapse their distinct roles into a single procurement conversation, you get objectives that match the backup appliance instead of the mission. A four-hour RTO is an infrastructure metric. A four-hour gap in a live surveillance feed is a mission failure.
The storage array will eventually restore the database, but it cannot reconstruct the operational picture that existed while it was down.