Knowing that a backup runs is useful. Knowing what it contains, who can retrieve it and whether it has been restored is more useful when something goes wrong. The right recovery plan starts with what your business would need to keep serving customers, taking orders or answering enquiries.
- Backup created
- A copy exists for the agreed files, data and period.
- Restore tested
- The copy has been used to recover and check a working result.
A successful backup label alone does not establish that the business can recover the website and its important data.
Work out what needs recovering.
A copy of the website design may leave out orders, enquiries, uploads or settings held in separate services. Identify those pieces before choosing a backup process. For a typical WordPress site, the official guidance identifies both database and files as necessary for a full restore.
A custom site may keep code in version control while storing customer records elsewhere. Ask which information lives in each place and how those pieces fit together. Record the recovery route without copying private records, passwords or secret keys into the handover.
Reading behind this section: WordPress
Decide how much recent work could be missing.
A backup taken before the latest order cannot contain that order. Discuss how often important information changes and how the business would reconcile activity since the last usable copy. A brochure site and a busy shop may need very different arrangements.
Also agree how long recovery could take and what the team would do meanwhile. That might include a temporary contact route or manual order handling. These are planning questions for the particular business, rather than a recovery time that can be assumed from a hosting label.
Restore into a safe place and check the result.
GitLab’s first-hand account of its 2017 database outage describes backup failures that had gone unnoticed and a lack of ownership for regular testing. It is a useful reminder to check the recovery process itself, including who receives and acts on failure alerts.
A practical restore check uses a separate environment and records which copy was used, what returned and which functions were checked. Keep test systems from sending real customer messages or accepting live payments. Opening the homepage alone does not establish that orders, enquiries or attachments are recoverable.
Reading behind this section: GitLab engineering team
Leave clear instructions for the next person.
Record where copies are held, who can retrieve them and whether recovery depends on access to the same account that might be unavailable. Agree retention, access protection and responsibility for checking that the process continues to work.
The most useful question to ask a provider is specific: when was a copy last restored, and what did that check cover? A dated answer with clear limits gives the business a better basis for planning than an unqualified assurance that everything is backed up.
Put it to use
A useful check for your business.
- List code, files, records and connected services separately.
- Agree backup frequency and how recent activity is reconciled.
- Request a safe restore check with recorded results.
- Confirm access, retention and the person handling failures.
The thinking behind this guide
Sources & further reading.
Our practical interpretation, with the references below for the specific principles and further detail.
- Backups
A typical WordPress restore requires both database and files; backup arrangements need to cover both.
- Postmortem of database outage of January 31
First-party 2017 incident account: failed backup procedures, failed notifications and absent ownership of regular restore testing. Historical example, not a KD result.
