A Backup Is Not a Recovery Plan: Have You Actually Tested the Restore?

The hosting dashboard has shown a green tick every morning for months: Backup successful.

Then the website breaks.

The database is corrupted, an update overwrites files, or a compromised account changes production data. Only now do you discover whether “a backup exists” actually means the website can be restored.

Those are often two different statements.

CISA recommends not only maintaining protected backups but regularly testing their availability and integrity in a disaster-recovery scenario. NIST treats testing and exercises as a distinct part of contingency planning. Managed platforms such as AWS Backup even provide scheduled restore testing because a successful backup job by itself does not prove that recovery will work.

The important question is therefore not:

“Do we have backups?”

It is:

“Can we rebuild a working website from a real backup, and do we know how long that takes?”

Backup success and recoverability are different things

A backup job can complete successfully and still fail you during an incident.

Common reasons include:

• The database was backed up, but uploads or configuration files were not.
• Files exist, but nobody knows which database snapshot belongs with them.
• The archive can be downloaded but cannot be decrypted.
• Credentials for the backup store or registrar exist only in the password system that is currently unavailable.
• The application is backed up, but DNS, email, cron, queue, or proxy configuration is not reproducible.
• The backup is intact, but the restore instructions are obsolete.
• Recovery technically works, but takes twelve hours when the business can tolerate only two.

WordPress makes one of these distinctions especially clear. Its official documentation explains that a WordPress site consists of files and a database, and that backing up the files usually does not back up the database. Themes, plugins, and uploads can therefore survive while posts, settings, users, or other database data are missing — or the reverse.

A restore test is not merely checking an archive. It proves whether the whole chain can be put back together.

RPO and RTO turn “eventually online again” into a target

Two recovery concepts make this measurable.

Recovery Point Objective (RPO) describes the point in time to which data needs to be recovered after an outage. In practical terms: how much data loss can you tolerate?

If an online store can lose at most 30 minutes of orders, one daily database backup obviously does not meet that requirement.

Recovery Time Objective (RTO) describes how long a system can remain unavailable before the impact becomes unacceptable.

If a booking website must be back within four hours, a recovery process that starts only after a support ticket is answered on the next business day is not a suitable recovery strategy.

NIST explicitly uses RPO and RTO when discussing backup and recovery planning. A small website does not need an enterprise governance programme, but two clear numbers are much more useful than “we back up regularly.”

Eight common website-backup red flags

1. Nobody has ever completed a full restore

This is the classic one.

The backup plugin reports success. The host lists 30 restore points. Nobody has ever taken one of them and rebuilt the site in an empty environment.

Until that happens, you do not know whether the backup is complete, readable, compatible, and operationally useful.

2. Backup and production share the same failure boundary

If the website, database, and backups sit under the same account, storage layer, or credentials, one incident can affect all of them.

CISA recommends offline or otherwise protected encrypted backups and warns that ransomware actors may attempt to find and delete or encrypt accessible backups.

This does not mean every small company needs tape storage. It means a backup should not merely be another object that the same compromised identity can delete.

3. Only “content” is backed up, not the operating environment

A website is rarely just HTML and a database.

Recovery may also depend on:

• DNS zones and domain access,
• TLS configuration,
• reverse-proxy or CDN rules,
• environment variables and secrets,
• cron jobs and workers,
• object storage,
• email DNS and delivery configuration,
• redirects,
• webhooks,
• search indexes,
• infrastructure code,
• external API credentials and integrations.

Not all of this belongs in one backup. But every component needs a clear answer to where it comes from during recovery.

4. The documentation depends on knowledge held by one person

“Alex usually does the restore” is not a recovery procedure.

A useful runbook test can be performed by someone who understands the system but does not restore it every day. If that person immediately has to ask which backup to choose, where the encryption keys live, or which DNS record must change first, you have found valuable missing knowledge — just later than ideal.

5. Testing stops when “the server starts”

A restored website is not automatically a functioning website.

After recovery, validate real critical paths such as:

• homepage and important landing pages,
• login and password reset,
• forms and notifications,
• checkout or booking,
• upload and download,
• internal search,
• cron jobs and queues,
• API integrations,
• admin access,
• analytics or monitoring where relevant.

AWS Backup separates restore testing from optional validation for the same reason: creating a restored resource successfully is not the same as proving the resulting system behaves correctly. Websites should use the same mindset.

6. Nobody measures restore time

A restore can work and still miss the RTO.

Measure from “incident declared” to “critical service validated and available again.” Include waiting time for storage, DNS, provider support, keys, and manual checks.

Only then do you know your real recovery time.

7. There is no clear rule for choosing the recovery point

The newest snapshot is not automatically the safest one.

If a system was compromised, the latest backup may already contain the malicious change. During a faulty migration, snapshots may capture several inconsistent application states.

A recovery plan should therefore answer:

• Which recovery points exist?
• How far back does retention go?
• How do you identify the most recent trusted state?
• Which data has to be replayed or reconstructed afterwards?

8. Nothing is documented after a successful test

A restore test is not an exam you pass once.

NIST recommends tests with explicit objectives and success criteria, along with documented results and lessons learned. That principle is useful even for very small teams: What took longer than expected? Which credential was missing? Which instruction was ambiguous? Which external dependency was undocumented?

The next test should not rediscover the same problem.

A pragmatic restore drill for a small website

You do not need to cause a production outage to test recovery.

Step 1: Choose a real recovery point

Use an actual backup produced by the normal backup process, not a specially prepared “clean” archive created for the exercise.

That tests the system you would rely on during a real incident.

Step 2: Restore into an isolated environment

Use a separate test hostname or isolated network. Prevent the restored application from sending real email, firing production webhooks, charging payments, or exposing an indexable duplicate to search engines.

Step 3: Verify data and files separately

For a CMS, explicitly confirm that the database, uploads, themes/plugins or application code, and relevant configuration belong to a coherent state.

Step 4: Handle secrets and external dependencies deliberately

A backup should not blindly copy all production secrets into a test environment. At the same time, the real recovery plan must explain how current or replacement credentials will be made available securely.

Step 5: Validate critical functions

Define five to ten capabilities without which the website is not meaningfully “recovered.” Test them as a user and, where appropriate, with health checks or automated tests.

Step 6: Measure time and data age

Record:

• age of the recovery point,
• actual data-loss window,
• time until the first system responds,
• time until a critical function is validated,
• time until the system is ready for release.

Now RPO and RTO become testable rather than aspirational.

Step 7: Update the runbook

Turn every surprise into a change: missing access, wrong path, manual SQL fix, forgotten DNS step, undocumented provider dependency.

A useful restore test does not only produce a functioning test site. It produces a better next recovery.

Automate where it makes sense

Not every restore has to be performed manually every month.

Cloud platforms can schedule restore tests, create temporary resources, and measure restore duration. AWS Backup documents exactly this workflow and also supports post-restore validation.

Smaller environments can automate useful parts too:

• periodically restore into an isolated environment,
• verify that the database imports,
• check the homepage and health endpoints,
• run smoke tests over critical URLs,
• sanity-check files or checksums,
• record recovery duration,
• remove temporary test resources afterwards.

Automation still does not replace every exercise. A technical restore can be green while nobody knows who changes DNS during the incident, who contacts customers, or who can access the registrar.

That is why recovery benefits from both: repeatable technical restore tests and occasional human recovery drills.

What Website-Pflichtencheck would inspect

A backup and recovery review is not limited to checking whether a ZIP file exists somewhere.

It can inspect:

• which systems and data are actually protected,
• backup frequency and retention,
• separation between production and backup storage,
• protection against accidental or compromised deletion,
• encryption and access model,
• database, file, and media completeness,
• recoverability of CMS, hosting, and infrastructure components,
• documented RPO and RTO targets,
• restore runbooks,
• required credentials and external dependencies,
• measured restore duration,
• validation of business-critical user journeys,
• monitoring and documentation from previous tests.

The goal is not an enterprise disaster-recovery manual for a small business website. The goal is much simpler:

If something breaks tomorrow, the first real recovery should not also be the first test of your backup.

A green backup tick is reassuring. A proven restore is evidence.