The backup report arrived overnight and every entry says "completed". That is reassuring, but it only answers one question: did the backup process create a copy of something?
It does not confirm that the copy contains everything needed, that it can be accessed during an emergency or that it will produce a working website when restored. Those are recovery questions, and they tend to become painfully important at the least convenient moment.
A dependable recovery plan connects the backup files with the people, access, instructions and decisions needed to return the website to a usable state.
A backup copy is only one part of recovery
For a relatively straightforward website, a backup will usually include the website files, uploaded images and documents, and the database containing content and settings. A managed website backup setup may also provide remote storage, multiple historical versions and a regular automated schedule.
Modern websites can depend on much more than those core components. Hosting configuration, scheduled tasks, domain settings, security certificates, private keys, search services and connections to payment, booking or customer management systems may all affect whether the restored website actually works.
Some of these elements can be recreated rather than backed up, but that still requires accurate documentation and appropriate access. Restoring the files and database while discovering that nobody can reach the domain account or recover an integration credential is not a complete recovery.
The National Cyber Security Centre's guidance on backing up business data recommends checking that backups contain all important data and knowing how to restore them. That distinction matters: possession of a backup is not proof of recoverability.
A recent backup can still be unusable
Backup systems fail in quiet ways. A job may run successfully while excluding a newly added directory, copying an incomplete database or retaining files that cannot be decrypted without a missing key. A copy may also be technically sound but stored inside the same hosting account that has just become unavailable.
Retention is another common weakness. Keeping only the latest few copies can be risky if damage remains unnoticed for days or weeks. Each new backup may gradually replace the last healthy version.
The NCSC's principles for ransomware-resistant cloud backups recommend retaining versions over an appropriate period and allowing restoration from an earlier point even when newer copies have been corrupted. They also emphasise protection against deletion or alteration, separate ways to regain access and alerts when significant backup settings change.
The right retention period depends on the website. A frequently updated ecommerce platform, membership system or booking service will have different needs from a small brochure website that changes once a month. More copies are not automatically better, either. Backups may contain personal or commercially sensitive information, so storage, access and retention need to be controlled.
Decide how much loss and downtime are acceptable
A useful recovery plan starts with two business questions.
- How much recent information could be lost? If the latest usable backup is 24 hours old, that could mean recreating a day's orders, enquiries, bookings or content changes.
- How long could the website remain unavailable? A company may tolerate several hours of downtime on an informational site but require a much faster response from a platform supporting daily operations.
Technical teams sometimes call these the recovery point and recovery time objectives. The terminology is less important than agreeing realistic answers.
A five-minute backup schedule offers little comfort if recovery requires two days of searching for credentials and reconstructing undocumented server settings. Equally, paying for near-instant recovery may be excessive for a low-risk website with little changing data.
The chosen approach should reflect the consequences of downtime, the pace at which information changes, contractual or regulatory responsibilities, and the available budget. It should also identify any work that will continue manually while the website is unavailable.
Test the route back before it is needed
The strongest evidence that a website can be restored is a successful restoration test. This normally means recovering an appropriate backup into a separate, controlled environment rather than overwriting the live website.
The test needs to examine more than whether the homepage appears. Depending on the website, checks might include:
- Confirming that content, images and documents are present
- Signing in to the content management system
- Testing forms, search and important customer journeys
- Checking scheduled processes and background tasks
- Confirming that integrations reconnect safely
- Reviewing whether sensitive information and permissions remain protected
A restore test can expose missing components, outdated instructions and unrealistic recovery times while the website is still operating normally. The result should be recorded, including the date, backup used, time taken, problems found and any follow-up work.
After a security incident, recovery may require extra care. Restoring the newest available copy could reintroduce malicious files or compromised software. The NCSC's data security guidance recommends using trusted sources for executable software, updating the target systems and checking restored files for malware. Identifying a clean recovery point may therefore require investigation before restoration begins.
Questions every website owner should be able to answer
A recovery plan does not need to become a vast technical manual, but responsibility and expectations should be clear. A company should be able to answer:
- What website files, databases, uploads and configuration are included?
- How often are backups created, and how quickly could recent data be lost?
- Where are copies stored, and are they separated from the live hosting environment?
- How long are historical versions retained?
- Who can access the backups if the normal hosting or company accounts are unavailable?
- When was a full restoration last tested, and what was the result?
- Which external services or manual steps are needed to make the restored website operational?
- Who is responsible for deciding when to restore and coordinating the recovery?
Backups remain a fundamental part of ongoing website care, alongside updates, monitoring and technical support. Their value, however, is measured at the point of recovery.
The better question is not simply "Do we have backups?" It is "What would it take to return this website to useful service?" A recovery plan gives that question a tested, documented answer rather than an optimistic guess.
