A website backup is not a recovery plan: run a restoration drill

Why a successful backup job is insufficient

A green backup notification proves that a process created something. It does not prove that the archive is complete, readable, recent enough, isolated from the original failure, or restorable by the people who will need it. Recovery depends on files, data, configuration, credentials, dependencies, documentation, and a sequence that returns the system to a known operating state.

Define recovery objectives from business impact

Choose an acceptable recovery point and recovery time for each important website journey. The recovery point describes how much recent data the business can afford to lose; the recovery time describes how long the journey can remain unavailable. A brochure site, lead-generating form, membership portal, and transactional store should not inherit one arbitrary backup schedule.

• List the customer and staff journeys that must be restored first.
• Identify data that changes between backups, including orders, form submissions, accounts, inventory, content, and consent records.
• Document short-term manual workarounds and their limits.
• Assign authority to declare a recovery and accept any known data gap.

Inventory the full recoverable system

A modern website is usually more than one directory. Record the application code, media, database, runtime and package versions, environment configuration, DNS, certificates, scheduled jobs, queues, search indexes, email services, payment or inventory integrations, analytics, and external data dependencies. WordPress guidance specifically distinguishes database content from files such as themes, plugins, uploads, and configuration; both are needed for a typical full restoration.

Create matched, protected backup sets

Treat related files and data as one timestamped recovery set so the database does not describe assets or code that came from a different moment. Encrypt sensitive backups, restrict access, protect integrity, and retain copies outside the production failure domain. CISA recommends offline, encrypted backups and regular tests because ransomware may seek and damage accessible backups.

Restore into an isolated environment first

A routine drill should not overwrite production. Build a clean target with controlled networking, restore the documented components in the correct order, and record every manual step, missing permission, incompatible version, unavailable secret, and undocumented dependency. If the procedure only works through one person’s memory, the drill has found an operational risk.

Validate a known-good and secure state

Opening the homepage is not recovery evidence. Confirm the deployed version, database consistency, authentication and authorization, security configuration, background jobs, integrations, and representative customer journeys. NIST recovery guidance emphasizes reconstitution to a known secure state and full testing after loading known-good backups.

• Test forms, checkout, login, account recovery, search, uploads, and administrative access where relevant.
• Compare representative records, totals, media, logs, and downstream systems.
• Confirm transactional email, webhooks, queues, scheduled work, analytics, and consent behavior.
• Scan for unexpected changes and reapply required patches or configuration.
• Verify that private routes and restored data remain protected.

Measure what the drill actually proved

Record the backup timestamp, restore start, service validation time, final recovery time, data gap, failed steps, manual interventions, and systems not included in the exercise. Compare the result with the stated recovery objectives. A restoration that eventually succeeds but misses the business deadline is useful evidence, not a passing result.

Separate restoration from production cutover

Restoring data and deciding to direct real traffic to the recovered system are different decisions. Define reconciliation for transactions created after the recovery point, DNS or routing changes, certificate and domain checks, customer communication, rollback conditions, and monitoring after cutover. Avoid creating conflicting writes in old and recovered systems.

Turn the drill into a maintained capability

Update the runbook immediately after the exercise, assign each gap to an owner, and repeat the affected step after remediation. Schedule drills based on change rate and business impact, and repeat them after material platform, hosting, integration, or data-model changes. NIST contingency guidance recommends scheduled tests and updating plans from exercises and actual disruptions.

What closes a restoration drill?

Close the drill only when the team can identify the correct backup, access it through approved controls, restore the intended system into isolation, validate critical journeys and security, quantify recovery time and data loss, remove temporary access, and document follow-up work. The deliverable is not an archive. It is repeatable evidence that the business can recover.