A Backup Is Only Good When the Restore Works

The backup dashboard shows a green check every morning. Database captured. Files copied. Retention active.

Then the website fails, and nobody knows how to turn those stored files back into a working system.

A backup answers whether data was written somewhere. A restore test answers the question that matters to the business: Can the organisation rebuild the website under realistic conditions?

The dangerous assumption: “Backups run automatically”

Automation is useful, but a successful job can hide serious gaps:

• The database is included, but uploaded files are not.
• The files exist, but the encryption keys are unavailable.
• The backup sits inside the same provider account as production.
• A corrupted archive is uploaded and still marked successful.
• The database imports, but it is incompatible with the application version.
• DNS, environment variables, scheduled jobs, mail configuration, or external storage are missing.
• Recovery works only when one particular person is available.

CISA recommends maintaining separated or offline encrypted backups and regularly testing their availability and integrity in a disaster-recovery scenario. NIST likewise treats backup, system recovery, and contingency-plan testing as connected controls.

The principle is simple: a backup that has never been restored is an assumption.

What a modern website actually needs to recover

“The website” is rarely one directory and one database. Depending on the system, recovery may require:

Application data

• database and transactional records
• CMS content
• users and permissions
• form submissions
• orders, bookings, or case data
• media and uploaded files

Technical configuration

• environment variables and secrets
• web server, proxy, and CDN configuration
• DNS documentation
• scheduled jobs and queues
• redirects and security headers
• storage buckets and access policies
• email providers and webhooks

Rebuildable software

Source code should live in version control, but that alone does not guarantee a reproducible system. Recovery also needs pinned dependency versions, database migrations, deployment instructions, infrastructure definitions, and compatible runtime versions.

Restores often fail not because the large database dump is missing, but because one small dependency was never considered part of the backup plan.

RPO and RTO without the management fog

How much data can the organisation afford to lose? The Recovery Point Objective describes the maximum acceptable data loss. Twenty-four hours may be tolerable for a mostly static company site. For orders, bookings, or user activity, even one hour may be too much.

How long can the website remain unavailable? The Recovery Time Objective describes the tolerable recovery period. A backup may be complete and still fail the business if restoring it takes three days.

These targets determine backup frequency, system priorities, required access, and how often realistic recovery should be exercised.

A realistic restore test in seven phases

1. Choose a concrete failure scenario

Do not test “the backup” in the abstract. Choose complete server loss, accidental database deletion, a compromised CMS, a failed deployment, or an unavailable agency. The scenario defines which existing resources may not be used during the exercise.

2. Prepare a clean recovery environment

Do not overwrite production simply to prove a restore. Use an isolated environment with controlled access. This tests actual reconstruction without putting live data at risk.

3. Validate the backup independently

Before importing anything, verify:

• Does the expected backup exist?
• Is it complete and recent enough?
• Do size, checksum, or integrity checks pass?
• Can it be decrypted with the documented keys?
• Can the copy be mapped to a specific system and time?

A green job status is not proof of integrity.

4. Rebuild the system and restore data

Follow the runbook to reconstruct the application, database, uploads, and configuration. Record every manual step, missing permission, and fact that was available only through somebody’s memory.

5. Test more than the homepage

An HTTP 200 response does not prove successful recovery. Exercise sign-in and roles, forms, file access, email delivery, background jobs, payment or CRM integrations, redirects, canonicals, and consent configuration.

6. Check data state and consistency

Use representative samples to confirm that records, files, and relationships agree. A database may restore successfully while media is missing, migrations remain unapplied, or external identifiers point to the wrong environment.

7. Record time, gaps, and decisions

The output should contain more than “pass” or “fail”: actual recovery time, latest recoverable data point, missing access or secrets, undocumented specialist knowledge, untested dependencies, and improvements with an owner and due date.

Red flags in existing backup arrangements

• Backups exist only at the production hosting provider.
• Production and backup administration share one account.
• Nobody is alerted when a backup fails.
• There is no immutable or independently separated copy.
• Encryption is enabled, but key recovery has never been tested.
• Retention is shorter than the time it normally takes to discover a defect.
• Database and uploads are captured separately without a consistency strategy.
• The runbook names former staff.
• The last restore test happened “during initial setup.”

How often should recovery be tested?

There is no useful universal interval. Use a risk-based model: automated integrity checks after every backup, recurring restores of selected data sets, and complete recovery exercises for critical systems on a regular basis and after major changes to hosting, CMS, database, encryption, or ownership.

The more dynamic and business-critical the website, the less acceptable it is for the first full restore to happen during a real outage.

What Website-Pflichtencheck would inspect

A backup and recovery review follows the entire chain:

• scope, frequency, and retention
• separation between production and backup copies
• encryption, key access, and permissions
• integrity validation and alerting
• database, uploads, configuration, and external services
• documented RPO and RTO targets
• the recovery runbook
• an actual restore into an isolated environment
• critical user journeys after recovery
• ownership and a prioritised improvement plan

The objective is not another green dashboard. It is evidence that the website can return to an operational state after data loss, misconfiguration, or infrastructure failure.

Backups provide reassurance. Restore tests provide proof. Without a complete recovery exercise, an organisation may own many stored files but still lack a dependable way back into operation.