Business systems / Checklist
Your backup says successful. Could you get the business working again?
A green backup notification tells you a backup job finished. I would still want to see somebody restore it and use the result before relying on it to get a business working again.
Think about the job you need to carry on with tomorrow morning. Can you find the customer’s record? Open the photograph attached to their job? See which orders arrived after the backup was taken? Those are useful questions to put to whoever looks after your website or systems.
You can check this in a separate test environment. It takes some planning, especially when the system can send messages or take payments, but it leaves you with evidence of what you could recover and what still needs attention.
Choose a job the restored system must let you do
Start with a normal piece of work. For a service business, that might be finding an existing job, reading its history and opening an attachment. For a shop, choose an order and check its products, payment status and delivery details.
Write down what counts as a pass before the test starts. A homepage loading tells you something about the website. It tells you very little about whether staff can sign in and use the records behind it.
Decide how long you could manage without that job being possible, and how much recent work you could afford to recover separately. Those two decisions help your supplier choose a backup and recovery arrangement that suits the business.
Check what the backup contains
Ask for a list of what is included and what lives somewhere else. WordPress needs both its database and its files for a typical full restore. The database holds the page content and settings; uploaded photographs, themes and plugins are files.
Bespoke systems have their own split. Supabase, for example, says its database backups contain the metadata for Storage objects, but do not include the stored objects themselves. A recovered job record could therefore still point at a missing photograph unless the files have their own recovery arrangement.
Include the application code and the configuration needed to run it. Ask who can obtain the backups if the usual hosting account or the person who normally manages it is unavailable. Keep copies and recovery access protected, with an appropriate copy separate from the live system.
Restore a copy that cannot contact customers
Have the supplier prepare an isolated location for the rehearsal. It should have controlled access, stay out of search results and follow the business’s rules for handling any copied personal data. Use suitable test data wherever possible.
Before starting the copy, disable scheduled jobs and outbound integrations that could act on it. That includes customer emails, texts, payment attempts and fulfilment requests. A restored queue of old work must not start sending or charging again.
AWS recommends exercising recovery against the agreed recovery objectives and the written procedure. The useful result is a rehearsal that exposes missing steps while you still have time to fix them. A live rollback during an incident needs its own decision and precautions.
Look at the gap between the backup and the fault
Suppose a shop has a backup from midnight and stops working at lunchtime. Restoring that backup would take its database back to midnight. Orders received that morning need to be accounted for before the recovered shop replaces the live one.
Ask how those newer records would be identified and reconciled with payment, delivery and accounts systems. Replaying every notification could create duplicate actions. Ignoring the gap could lose work that customers have already paid for.
Some providers offer recovery to a more recent point in time. Availability and retention depend on the service and plan, and other systems or uploaded files may have different recovery points. Write down what your own arrangement covers.
Source: Supabase: database backups
Keep a short result you can read
For the rehearsal, follow the chosen job through the restored copy. Open the attachment as well as the record. Use a test account to check the permissions and save a harmless draft if that is part of the agreed check.
Time the recovery from the agreed starting point until the working checks pass. Separate waiting for access or a provider from the time spent restoring the data. Both affect how long the business would be waiting.
The result can be a short table. It should show any missing dependency and who is going to fix it, without exposing passwords or customer records in the report.
| Check | Evidence to keep |
|---|---|
| Backup used | Date and time of the recovery point, and which components it covers |
| Working task | The agreed task and whether each step passed |
| Records and files | Sample checks passed, plus any missing records or attachments |
| Elapsed time | Start, usable finish and delays waiting for access or dependencies |
| Follow-up | Faults, owner, next action and the date to test again |
Repeat the check when the system changes
A new file store, booking integration or server can change what recovery needs. Put another rehearsal on the plan when those dependencies change, and agree a sensible recurring test for the system you run.
If nobody can show you a recent restore result, start by asking for this one controlled test. It gives you a much better conversation about support than a list of backup features you have never seen used.
Sources
Checked on 23 October 2026.
- AWS: test disaster recovery implementation
Exercise recovery procedures and compare the results with the agreed recovery objectives.
- Supabase: database backups
Database backup and restoration behaviour, plan-dependent recovery options, and the exclusion of Storage objects.
- WordPress: backups
A typical full WordPress recovery needs the database and files, with backup copies kept in separate locations.