Your Backup Is Green. Can You Actually Restore the Website?

Monday, 08:17. The website is failing, the database is damaged, or a compromised system needs to be rebuilt. The hosting dashboard offers a reassuring line: Backup successful, 02:00.

That is useful. It still does not answer the question that matters: Can you turn that backup into a working service with the right data, files, access, and dependencies within a timeframe the business can tolerate?

That is the difference between having a backup and being recoverable.

CISA recommends not only maintaining backups of critical data, but regularly testing their availability and integrity in a disaster-recovery scenario. AWS exposes scheduled restore testing as a dedicated backup capability for the same reason. NIST, meanwhile, treats recovery as a distinct part of the cybersecurity lifecycle.

A green backup status is evidence that a job ran. A restore test is evidence that recovery works.

Myth 1: “The backup job succeeded, so the backup is good.”

A backup system can successfully report that it wrote data. That does not prove the result is complete, readable, or restorable under realistic conditions.

Common surprises appear only during recovery:

• The archive opens, but individual tables or objects are missing.
• The database exists, but roles, permissions, or extensions do not.
• The backup belongs to a different application version than the code currently available.
• Encryption keys or credentials required for recovery are no longer accessible.
• The restore works technically but takes six hours instead of the assumed 30 minutes.
• Files are back, but uploads, search, queues, or scheduled jobs do not work.

PostgreSQL illustrates the scope problem well. A single pg_dump backs up one database, while cluster-wide information such as roles and tablespaces is not automatically included. A complete recovery therefore depends on knowing which additional pieces the system requires.

The audit question is not merely “Do backups exist?” It is: What exactly was backed up, and has that exact type of recovery point been restored successfully?

Myth 2: “The database is the website.”

For a simple static site, perhaps. For real websites, shops, portals, and SaaS products, usually not.

A recoverable application commonly has several layers:

Data: database records, user accounts, orders, form submissions, and CMS content.

Files: media uploads, generated PDFs, private documents, attachments, and objects stored outside the database.

Application: source code, reproducible builds, runtime versions, dependencies, migrations, and deployment configuration.

Infrastructure: DNS, domains, reverse proxy, CDN, storage, database services, queues, workers, and scheduled tasks.

Access and keys: secret-manager access, API credentials, encryption keys, OAuth configuration, SMTP credentials, and certificates or a reliable way to reissue them.

That does not mean every secret should be copied into a backup file. Quite the opposite: sensitive keys need an appropriate secure strategy. What matters is that the recovery process knows how required secrets and access can be re-established without depending on one person or an agency account that was deleted months ago.

A restore test exposes those hidden dependencies quickly.

Myth 3: “The hosting provider snapshot is enough.”

Provider snapshots are useful and may be an important part of a backup strategy. They should not be confused with complete resilience.

If production and the only backup share the same administrative boundary, they may also share risks: compromised accounts, configuration mistakes, deletion operations, billing problems, or provider incidents.

CISA recommends offline, encrypted backups for critical data and regular testing. The important principle is independence: an incident in production should not automatically be able to destroy the last usable recovery path as well.

Useful audit questions include:

• Are all backups stored with the same provider and under the same account?
• Who can delete recovery points?
• Is versioning or immutable retention used where appropriate?
• How long are recovery points kept?
• What happens if the primary hosting account is locked or compromised?
• Can an authorized second person access the recovery path?

Backups are not only storage. They are an architecture of permissions and dependencies.

Myth 4: “In an emergency, we will just restore the latest backup.”

“Latest” is not a recovery requirement.

Two objectives make expectations measurable:

RPO — Recovery Point Objective: How much data loss is acceptable? If new orders arrive every five minutes, a nightly backup can be technically successful while still being unsuitable for the business.

RTO — Recovery Time Objective: What is the maximum acceptable delay before the service is restored?

AWS defines RPO and RTO as recovery objectives that the organization must set. The crucial part is set. Without a target, it is difficult to judge whether a backup strategy is adequate.

A brochure site with no transactions can have very different requirements from an online shop, customer portal, or SaaS product. “We back up every night” defines neither RPO nor RTO.

A useful restore test therefore measures at least:

• time needed to find and access the correct recovery point,
• duration of the restore itself,
• required manual steps,
• timestamp of the newest data actually recovered,
• time until the system is technically functional,
• time until the service is approved for business use.

Only then can you compare the assumed recovery objective with reality.

Myth 5: “Restore successful” means “website recovered.”

A database import ending with a successful exit status is not the same as an operational product.

Recovery needs functional validation. The relevant checks depend on the system, but often include:

• homepage and critical landing pages load,
• login and password reset work,
• CMS content and media are present,
• forms can be submitted and stored,
• email is actually sent,
• upload and download work,
• search returns results,
• checkout or payment hand-off works,
• webhooks are processed,
• background jobs and scheduled tasks run,
• permissions still protect private content,
• monitoring and error tracking are reporting again,
• new data can be written after recovery.

This is where a technical restore becomes a business-usable recovery.

A practical restore drill for websites

A restore test should not begin with a production outage. It should happen under controlled conditions.

1. Choose a realistic recovery point

Do not always choose the most convenient backup. Test a recovery point you could genuinely use during an incident.

Verify its date, completeness, retention, and accessibility.

2. Restore into an isolated target environment

A test restore should not overwrite production. Use a separate environment with controlled network access and prevent unintended side effects.

This matters especially for integrations: a restored copy must not suddenly email real customers, fire production webhooks, or trigger payments.

3. Start the clock

Record when the test begins and when the service becomes technically and operationally usable. That produces an actual recovery time you can compare with the desired RTO.

4. Verify the data point

Do not stop at “database exists.” Check concrete reference data: recent content, users, orders, uploads, or other business-critical records.

Compare the recovered point with the intended RPO.

5. Reconnect dependencies

Can storage, queues, workers, email, search, and external APIs be connected correctly? Which credentials are missing? Which steps exist only in one person's memory?

Document every manual dependency.

6. Test critical user journeys

Use a short, repeatable list of essential workflows. Recovery should prove that the service is usable, not merely that infrastructure starts.

7. Document the result and fix the gaps

A failed restore drill is uncomfortable but valuable: it reveals a gap while there is no real outage creating pressure.

Record at least:

• recovery point tested,
• restore duration,
• observed data-loss window,
• missing access or dependencies,
• failed functional checks,
• owners for remediation,
• date or trigger for the next test.

AWS Backup supports this same principle with scheduled, repeatable restore tests and visibility into completion time. Even if you do not use AWS, the model is portable: recovery should be a testable process, not an emergency document nobody has executed.

What Website-Pflichtencheck would inspect

A technical Website-Pflichtencheck would not label an existing backup product good or bad simply because it exists. We would look at recoverability in the context of the real architecture.

Depending on the system, that can include:

• available backup sources and recovery points,
• scope across database, files, configuration, and external dependencies,
• retention and administrative separation,
• documented RPO and RTO targets,
• restore instructions and ownership,
• evidence from previous restore tests,
• access to domains, DNS, hosting, and secrets,
• post-restore functional checks,
• visible single points of failure in the recovery process.

The output should not be a 40-page disaster fantasy. It should answer a simple question:

If this system failed today, what would we need, who could recover it, what point would we get back to, and do we know because we have tested it?

If the current answer is only “the host takes backups,” a controlled restore drill is one of the highest-value maintenance steps you can take next.