Backups will not restore

Your preparation

0 of 0 safeguards ready

Incident worksheet

Make the next decision with evidence

Preserve every remaining copy, diagnose the restore failure, and recover the most valuable consistent data without overwriting better evidence.

EvidenceDecisionActionProof

Capture before evidence disappears

Record backup ID, type, chain, creation time, retention, encryption key, region, account, size, checksum, software version, and exact restore error.
Protect snapshots, replicas, exports, object versions, local copies, caches, and application-derived data from retention or cleanup.
Build a timeline of last verified restore, schema and engine changes, key rotation, account migration, and backup-job success signals.

Decisions that change the response

Question	Act when	Action
Repair the chain or use another copy?	Diagnosis could alter the only backup or consume retention time.	Clone metadata and media first; test repair on copies while preserving alternate recovery sources.
Full or partial recovery?	A complete restore misses the objective but high-value tables or files can be recovered consistently.	Restore into isolation, validate relationships, and import through a reviewed reconciliation plan.

Proof that recovery worked

Recovered data passes checksums, row and file counts, referential checks, business totals, and application smoke tests.
The recovery point and known missing interval are explicit to business owners.
A new backup from the recovered system restores successfully into an empty environment.

Controls to put in place

Test restores automatically into isolated infrastructure, not only backup-job completion.
Keep independent copies, keys, manifests, software versions, and runbooks outside production control.
Measure recovery point and recovery time with business validation after every major data change.

Tabletop drill

Restore a selected backup into a blank account with no production credentials. Validate counts and business totals, simulate a broken chain, use an alternate copy, and record actual recovery time.

Escalate when

Contact the database or backup provider before modifying the only copy; use recovery specialists when media, encryption, chain, or corruption failures threaten irreplaceable data.

What this means

A backup job can succeed while recovery still fails. The copy may exclude files, require a missing encryption key, depend on deleted infrastructure, or restore data that the current application cannot read.

Do not damage the only remaining copy while experimenting. Work from duplicates and record every attempt.

Warning signs

No one remembers the last successful restore test.
Backup size, duration, or item count changes sharply.
The backup uses the same account and deletion rights as production.
Encryption keys, passwords, schemas, or restore tools are undocumented.
Recovery time has never been measured against a real outage.

Recover now

First 15 minutes

Protect every available copy. Stop retention cleanup and create duplicates of the failed backup, snapshots, replicas, exports, and current damaged system.
Record the exact error. Save logs, backup ID, creation time, size, checksum, software version, encryption method, and attempted restore steps.
Confirm prerequisites. Check keys, passwords, manifests, schemas, storage permissions, network access, and compatible restore software.
Open provider support early. Retention windows and recovery options may expire while you troubleshoot.
Choose the least destructive next attempt. Restore into a separate environment using a duplicate.

Today

Try older recovery points and alternate formats.
Restore components separately: database, files, object storage, configuration, and secrets.
Check replicas, exports, local caches, payment records, email events, and third-party systems for reconstruction data.
Validate partial recovery before merging it.
Tell the business what data and time range are confirmed, uncertain, or unrecoverable.
Preserve failed media and logs for specialist recovery when the value justifies it.

Verify recovery

Restored data opens with the intended application and passes integrity checks.
Database records, files, and external transactions reconcile.
The recovery process works from a clean account or environment.
Required keys and tools are stored securely with the runbook.
A new isolated backup completes and passes a restore test.
The measured recovery time meets the business’s actual tolerance.

Prepare now

Copies

Critical data has multiple recovery methods, including an isolated copy.
Production credentials cannot delete every backup.
Retention covers accidental deletion, compromise, and delayed discovery.
Backup alerts include size, item count, duration, and failure.

Restore

Runbooks include keys, versions, schemas, files, secrets, and validation steps.
Restore tests use a clean environment and a person other than the backup author.
Recovery time and acceptable data loss are written down.
Restored data is compared with independent financial or customer records.

Practice

A full restore test has produced a usable application within the last three months.

Common mistakes

Testing on the only copy. A failed attempt can make recovery worse.
Checking files but not application behavior. A backup can be readable and still unusable.
Forgetting encryption keys. Encrypted backups without independent key recovery are lost.
Keeping backup and production under one administrator. One mistake or attacker can delete both.
Measuring backup time instead of restore time. Recovery is what the business needs.

Sources

Last reviewed July 19, 2026Guidance changes. Confirm provider-specific actions in the linked official sources.