A backup is only valuable when it can be restored

Category: Hosting and Operations

Many businesses receive a daily confirmation that the backup has completed. This provides reassurance, but only confirms that a process has run. It does not necessarily confirm that all required data is included, that the copy can be read, or that someone can actually restore the website within an acceptable timeframe.

A realistic recovery test is therefore a key part of professional web hosting and operations. The test uncovers dependencies that would otherwise only become visible during an outage: missing access to the domain, an incorrect database version, externally stored media files, outdated integration keys, or a CDN configuration that no one is familiar with anymore.

Start by defining what you need to be able to restore

“We back up the website” is too imprecise as an operational requirement. A modern website usually consists of several parts that must work together:

• Files, source code, themes and extensions
• Database containing content, users, settings and transactions
• Images, documents and other uploaded files
• Server configuration, environment variables and scheduled tasks
• DNS, certificates, CDN rules and cache configuration
• Integrations with forms, payments, logistics, CRM or other systems
• Access credentials and necessary technical documentation

Not everything requires the same backup method. DNS can be documented and exported, while the database must be copied frequently. Large media archives can be stored separately in object storage with their own versioning. The point is that the entire solution must be rebuildable without the team having to guess its way forward.

Determine how much downtime and data loss you can tolerate

Before the test, the business should consider two practical questions: How long can the website be unavailable, and how much data can be lost?

For a simple informational website, a few hours of downtime and one day of lost edits may be manageable. For an online store, the same incident could mean lost orders, unclear inventory status and extensive manual work.

State the requirements clearly. One example could be that a standard business website must be restorable within four hours, with a maximum of 24 hours of lost content. An online store may need much more frequent database backups and a shorter recovery time. The requirements should be based on the consequences for the business, not merely on what the hosting package provides as standard.

Carry out the test in an isolated environment

A restore test should normally not be performed directly in the production environment. Instead, create an isolated test environment that resembles production as closely as possible. It should use a comparable technical platform, software, database and configuration.

At the same time, the test environment must be protected against unwanted actions. Email sending should be blocked or redirected. Payment solutions should be placed in test mode. Integrations that can create customers, orders or support tickets must be disconnected or replaced with safe test endpoints.

A test environment that differs significantly from production can create a false sense of security. If production uses a different database, PHP configuration, storage solution or caching mechanism, the restoration may succeed in the test and still fail during a real incident.

A practical plan for the restore test

1. Choose a clear scenario

The test should be based on a specific incident. Examples include deletion of the entire server, a corrupted database, an error following an update, or loss of access to the current hosting provider. The scenario determines what you actually need to restore.

A full restoration to a new environment usually provides more insight than rolling back a single file on an existing server. It shows whether the business depends on settings and access credentials that exist only with the current provider.

2. Use a real backup

Do not create a new, specially prepared copy immediately before the test. Choose a backup from the regular routine. Record when it was taken, where it is stored and who has access.

Also check whether the copy is stored independently of the production environment. A backup on the same server or under the same compromised administrator account may disappear along with the website.

3. Start the clock and document the work

Measure the time from when the incident is discovered until the website has been technically restored and checked. Record how much time is spent finding access credentials, downloading data, creating the environment, importing the database and correcting the configuration.

This provides a more credible picture than the provider’s pure restoration time. A database can be imported in a few minutes, while clarifications, DNS changes and functional testing take several hours.

4. Restore the entire solution

Restore the application files, database and uploads. Configure scheduled tasks, certificates, email services and necessary integrations. Ensure that secrets and environment variables are handled securely and are not written into documentation that many people can access.

If the website uses a cache or CDN, you need to know what can be reused and what must be rebuilt. Clear old cache when it may contain incorrect or outdated pages. Verify that the CDN retrieves content from the correct origin server, and that protection rules and redirects still apply.

5. Test more than the homepage

The fact that the homepage is displayed does not mean that the website has been restored. Test the most important user journeys and administrative functions:

• Login and access control
• Forms and delivery of enquiries
• Search, filtering and document downloads
• Publishing and editing content
• Shopping cart, checkout and order processing
• Payment, storage and other business-critical integrations
• Scheduled tasks and automated processes
• Logs, monitoring and alerts

Also compare the content with the time when the backup was taken. This makes it clear how many edits, enquiries or transactions would have been lost.

Common weaknesses the test uncovers

A restore test rarely fails simply because the backup file is missing. The problems are often around it:

• The database and files were backed up at different times and are not consistent.
• Media files are stored externally and are not covered by the backup.
• The backup exists, but no available employee has the permissions needed to retrieve it.
• Restoration requires assistance from a vendor with no agreed response time.
• Old copies have been retained for too short a period to detect a gradual fault or damage.
• The website starts, but forms, payments or scheduled tasks do not work.
• Monitoring still points to the old environment and therefore does not confirm that the restored solution is working.

Such findings do not mean that the test failed. They are the very value of the test, provided the issues are prioritised and fixed.

Use the results to assess the operating environment

The restore test provides a better basis for choosing hosting than a comparison of storage space and processing capacity. A professional operating environment should support the level of contingency the business actually needs.

Find out whether the vendor offers separate and protected backups, how long they are retained, and whether individual files, databases and entire environments can be restored. Also clarify who performs the work, what response time applies, and whether restoration is included in the service agreement.

Access to logs, test environments and monitoring data is also important. Without this, it is difficult to confirm that the restored solution is stable. The business should also verify who owns and administers the domain, DNS and CDN. These components must be transferable or reconfigurable even if the current server environment is unavailable.

Make restoration a regular operational task

A successful test has a short shelf life. Websites change through new integrations, updates, content types and operational components. The test should therefore be repeated at an interval suited to the website’s risk and rate of change, and after major changes to the architecture or vendor.

Assign clear responsibility. One person should own the contingency plan, while the technical vendor may be responsible for execution. The business must nevertheless participate in checking forms, order processes and other functions that require business knowledge.

After the test, you should have a measured restoration time, an overview of actual data loss, documented deviations and a prioritised action list. Backup is then no longer just a green status message in a control panel. It becomes a controlled and practised part of the website’s contingency preparedness.