Backup is one of the few areas of infrastructure where an organization can be confident, compliant and entirely exposed at the same time. Jobs complete, reports are green, and nobody has attempted a full restore in three years.
Two numbers that should be decided by the business
Recovery point objective: how much data the organization can afford to lose, measured in time. Recovery time objective: how long it can afford to be without the system.
These are business decisions with cost consequences, not technical parameters. An RPO of fifteen minutes and an RTO of one hour is achievable and expensive. Twenty-four hours and three days is inexpensive. Most organizations have never stated either number explicitly, which means their infrastructure implies values that nobody has approved.
Set them per system rather than globally. The finance platform and the internal wiki do not warrant the same investment, and pretending otherwise means overspending on one and under-protecting the other.
The rule that has held up
Three copies of the data, on two different media types, with one held off-site. Recent practice adds a further requirement: one copy immutable or genuinely offline.
That addition exists because of ransomware. A backup reachable and deletable with production administrative credentials is not protection against an attacker who has those credentials — and obtaining them is the objective of the intrusion. Immutability, air gap or a separate authentication domain are what convert a backup into a control.
Testing is the whole thing
A backup that has not been restored is a hypothesis. Testing needs to cover a single file, a full system, and at least once a year the scenario nobody wants to schedule: the primary site is unavailable and the service has to be brought up somewhere else.
Measure the actual elapsed time rather than estimating it. The gap between assumed and measured recovery time is routinely a factor of three or more, and discovering that during an incident is the worst possible moment.
Document the result, including what went wrong. A restore test that surfaces two problems is a successful test. One that surfaces none usually means the scenario was too easy.