Your backups are not tested until you have restored from them

Every organization has backups. Rather fewer have restores. The distinction only becomes apparent at the worst possible moment, and the failure is never that the backup did not run — it is that the backup ran perfectly and could not be used.

What a green backup job proves

It proves data was read and something was written. It does not prove:

• that the archive is readable;
• that it contains what you think it contains;
• that it is internally consistent — a database copied file-by-file while running is frequently not;
• that you have the encryption key;
• that the target system can accept it;
• that a restore completes inside the time the business assumes.

Each of those is a real, documented way that a complete backup set fails to restore. The only way to close them is to restore.

Three levels of testing

File restore — monthly

Pick a file, restore it, compare it to the original. Ten minutes. Proves the chain works end to end and catches expired credentials, changed paths and full targets.

System restore — quarterly

Restore a whole system to isolated infrastructure and start it. This is where the real problems appear: a missing dependency, a hard-coded hostname, a license tied to hardware, a configuration file that was never in scope. Time it, because that number is your actual recovery time and it is usually longer than the assumption.

Scenario test — annually

Take a realistic scenario — a site lost, a ransomware event — and recover the set of systems that scenario requires, in order, with the people who would actually do it. It tests the dependencies and the sequence, which is the part no single-system restore can cover.

The failures this finds, in practice

• The backup covered the data and not the configuration.The database restores; the application cannot start because nothing captured how it was set up.
• Application-inconsistent database copies.Restores, starts, and is subtly corrupt.
• Encryption keys stored only on the system being backed up.A complete circle, and more common than it should be.
• Restore time an order of magnitude beyond expectation.Particularly from cloud archive tiers, where retrieval has its own latency and cost.
• Something added a year ago that was never added to the job.The newest system is the least likely to be covered.
• Backups reachable from the compromised environmentWhich, in a ransomware scenario, means they are not backups.

Write down what you are actually promising

Two numbers per system, agreed with whoever owns it rather than assumed by IT:

• Recovery point objective — how much data you can afford to lose. This sets backup frequency.
• Recovery time objective — how long you can be down. This sets the method, and it is where daily-tape thinking meets a four-hour expectation.

Then measure the real figures in a test and compare. Where they do not match, either the architecture changes or the expectation does — but the mismatch has to be visible to be resolved.

Immutability and separation

Ransomware changed what a backup has to survive. It is no longer only hardware failure and mistakes; it is an attacker with your administrator credentials who deliberately deletes backups first.

Practically: at least one copy that cannot be modified or deleted within its retention period, credentials for the backup system that are not the same as the production ones, and a copy that is offline or on a separate account. Then verify that the isolation is real by trying to delete something from a production account, rather than assuming the configuration does what it says.

Make the test a scheduled obligation

Restore testing does not happen without a date in a calendar and a name against it, because it is never urgent. The record needs only four things: what was restored, how long it took, what went wrong, and what was fixed. That record is also the most persuasive document available when someone asks whether the backup spend is justified.

Our infrastructure managed services include scheduled restore tests with those results reported to you, because a backup report showing green jobs is not evidence of recoverability and should not be accepted as any.