A backup can be perfectly readable and still fail to bring a service back.
The database may restore while the application remains offline because a signing key is missing, an object-storage bucket was not included, DNS points at the wrong place, or an identity provider cannot be reached. A recovery document may describe every command correctly but omit the order in which dependencies must return. None of this is visible when the only test is whether a backup job completed.
That gap became unusually concrete this week. Risky Business reported that an attacker breached Romania's cadastral agency, wiped systems and backups after a failed extortion attempt, and left official services offline for a week. The report also noted that the agency appeared to retain an offline copy.
The interesting product question is therefore not simply, "Do we have a backup?" It is: "Can this team use what it has to restore a working service under realistic failure conditions?"
A recovery drill that is allowed to break things
