Backup and Restore Check

A backup that has never been restored is a hope, not a backup. You find out what the company would lose and how long it would take to come back, then prove it with a real test restore. The standard: for every critical system, a dated record shows a successful restore within the agreed time, and at least one copy that an attacker with admin access could not delete.

When to use

• "Are our backups OK?"
• "If the database died right now, how much would we lose?"
• "We're worried about ransomware."
• "The auditor wants evidence of backup testing."
• After a near miss: accidental deletion, a failed migration, a provider outage.

What you need

• The list of systems and where their data lives: databases, file storage, servers, SaaS tools (email, documents, CRM, accounting), code repositories, secrets and password vault, DNS zone.
• Read access to backup settings: the cloud console or backup tool in your browser signed in by the owner, a connected app, or screenshots and exports the owner provides.
• For the test restore: the owner's approval, an isolated target (a separate server, database instance or bucket that is not production), and agreement on any cost.
• The business owner of each system, to agree recovery targets.

Method

1. Inventory the data. For each system record: what data, how important, who owns it, where it lives. Do not forget SaaS: a provider keeping your data available is not the same as a backup you control; deleted or encrypted items may be gone after the provider's retention period. Check each SaaS tool's retention and export options with web_search and cite them.
2. Agree recovery targets with the business owner of each system:
   • RPO (recovery point objective): how much data, in time, the business can afford to lose
   • RTO (recovery time objective): how long it can be down These are business decisions; you propose, they decide. Example: orders database RPO 15 minutes, RTO 4 hours; marketing site RPO 1 day, RTO 1 day.
3. Inventory the backups. For each system: method (snapshot, database dump, point-in-time recovery, file sync, SaaS export), frequency, retention, storage location and region, encryption, who and what can delete them, whether failures alert anyone, and when a restore was last tested. Sync and replication are not backups: they copy deletions and encrypted files too.
4. Compare with the 3-2-1-1-0 rule:
   • 3 copies of the data (production plus two backups)
   • 2 different storage types or services
   • 1 copy offsite, in a different region or provider
   • 1 copy immutable or offline (object lock, write-once retention, or physically disconnected)
   • 0 errors in the last restore test Also check: backup credentials are separate from production admin credentials, so an attacker who takes production cannot delete the backups; encryption keys are stored where they survive the loss of production; frequency meets the RPO.
5. Run a test restore for the most critical system first, with the owner's go-ahead:
   • restore into the isolated target, never over production
   • time it from start to usable
   • verify integrity: row counts or file counts against production, checksums where available, the application starts against the restored data, and a handful of recent records the business owner recognises
   • compare the data timestamp with the RPO and the elapsed time with the RTO
   • delete the restored copy afterwards if it holds personal data, unless the owner wants it kept for a defined period
6. Record gaps and fixes, ranked: no backup at all for a critical system; never tested; no immutable copy; backups deletable with production credentials; frequency misses the RPO; restore time misses the RTO; failures do not alert anyone.
7. Schedule with cronjob: a weekly check that the latest backup of each system succeeded and is recent; a quarterly test restore rotating through critical systems; a yearly full recovery exercise for the most critical service.

Things people forget to back up

• Email and shared documents in the office suite (deleted-item retention is limited and varies by plan)
• CRM, help desk and accounting data held only in the SaaS tool
• Code repositories, including issues and wikis if they hold decisions
• Infrastructure code, server configuration and container definitions
• Secrets and the password vault (with a tested way to reach them if the main admin is unavailable)
• The DNS zone and registrar details
• Encryption keys used for the backups themselves
• Website content managed in a hosted builder
• The recovery runbook: written steps, stored somewhere that survives the outage Check each SaaS tool's export and retention options with web_search and cite the provider's own documentation.

Output

A backup register and test record, saved to the workspace, with a show_card showing each system's status.

| System | Owner | RPO | RTO | Method | Frequency | Retention | Offsite | Immutable | Last restore test | Result | Gap |
|---|---|---|---|---|---|---|---|---|---|---|---|

Test restore record
- System: <name>  Date: <date>  Performed by: <you>  Approved by: <owner>
- Backup used: <id, timestamp>   Restored to: <isolated target>
- Time to usable: <h:mm> against RTO <h:mm>   Data age: <minutes> against RPO <minutes>
- Integrity checks: <list and results>
- Issues found: <list>   Restored copy disposed: <yes, date>

Checks before you finish

• Every critical system has an RPO and RTO agreed by its business owner.
• At least one real restore was performed and timed, not just a dashboard checked.
• The restore went into an isolated target; production was not touched.
• The register states plainly which systems have no immutable or offsite copy.
• Recurring checks are scheduled.

Pitfalls

• Reading the dashboard and calling it tested. "Last backup: success" says nothing about whether you can restore.
• Treating sync as backup. A synced folder faithfully syncs the ransomware.
• Backups the attacker can delete. If the same admin account can delete production and backups, one compromised login loses both.
• Forgetting the pieces needed to restore: encryption keys, configuration, secrets, DNS, and the documentation of how to do it.
• Restoring over production "to test". Never.
• Sign-off. Business owners set RPO and RTO. The owner approves test restores and any spend. Deleting old backups or changing retention is irreversible and needs explicit approval.