October 15, 2026 · Faith Forge Labs Editorial Team
A Website Backup Is Only Useful If You Can Restore It
Check what your website backups contain, who can reach them and whether an authorised person has rehearsed a safe restore. A successful backup job is only part of the picture.
“Backups are included” is reassuring until you need to know what that means. Does the copy include the database as well as the website files? Can someone reach it if the hosting account is unavailable? Has anyone checked that it can be restored?
You do not need to become a server administrator to ask those questions. You need an agreed recovery plan and someone qualified to show that it works.
Find out what the copy contains
Ask your website team to identify the pieces needed to rebuild the current site: application files or source code, database content, uploaded media and the configuration required to run it. Secrets need protected handling; a public backup download is not a safe way to share them.
Platform details matter. WordPress, for example, documents files and the database as separate parts of a backup. A copy of the theme alone would not contain the posts, settings and other records held in the database. For another platform, ask for its equivalent inventory.
Also identify what lives elsewhere. Business email, payment records and files in an external service may require separate recovery arrangements. Do not assume a website backup covers every connected account.
Agree how much lost work the business could tolerate
Consider a hypothetical brochure website that changes a few times a month, compared with a booking site updated throughout the day. The same backup frequency could leave very different amounts of missing work.
Ask two practical questions: how far back could the business afford to recover, and how long could the website be unavailable? Treat the answers as requirements to plan and test against. A backup taken yesterday does not establish how quickly a restore can be completed.
Check retention too. If a problem is discovered late, the latest copy may already contain it. Ask which older recovery points are retained and how the team would choose a suitable one.
Rehearse away from the live website
Arrange an authorised restore into an isolated environment. The rehearsal should protect any sensitive data and prevent outgoing email, payment actions and other live integrations. Replacing production just to see whether a backup works creates an avoidable risk.
Ask the person doing the restore to record which copy was used, the steps required, any missing dependencies and the time taken. Check meaningful pages and important workflows in the restored site. A homepage loading is useful evidence, but it does not show that uploaded files or application records are complete.
The NCSC's backup guidance recommends knowing how to restore a backup and checking that it contains the important data. For a website, the rehearsal turns that general advice into a concrete operational check.
Put a person and a review date beside the plan
Record who monitors backup failures, who can authorise a restore and where the instructions are kept. Ask how copies are protected from the same account compromise or failure that could affect the live site. Review the arrangements after significant hosting, application or account changes.
If you cannot answer these questions today, start with the inventory rather than buying another backup product. Bring the current arrangements to a website maintenance discussion and ask for a bounded restore rehearsal with a clear result.