In brief
A practical five-step guide for SME owners commissioning websites or custom software: define recovery needs, document dependencies, restore safely, check real work, and keep evidence.
Start with the recovery question
A green backup notification answers a narrow question: did the backup job report success? It does not, by itself, demonstrate that your team can bring a website or business system back into useful service.
AWS makes this distinction in its backup documentation: restore testing evaluates whether restoration works and records how long restore jobs take. That is a different exercise from simply creating another backup.
Before choosing tools, agree two practical limits with the people who use the system: how long could work stop, and how much recent work could you afford to recreate? Record these as planning targets, not promises. Start with one important system rather than trying to rehearse everything at once.
List what a working system needs
Ask the developer or hosting provider to explain what is included in the backup—and what is not. For a website, use a checklist covering the database, uploaded files, application code and configuration. For custom software, add any background jobs or supporting services needed for normal operation.
Keep passwords and secret values out of an ordinary checklist. Record the approved way to retrieve them instead. Give the recovery instructions an owner, with a named alternative.
Then document the dependencies that a backup file cannot explain on its own:
- Who can access the backup and authorise a restore?
- Where are deployment instructions and required software versions recorded?
- How will authorised staff obtain credentials or encryption keys securely?
- Which supplier accounts, domain settings and external services are involved?
Rehearse away from live operations
Our recommended first exercise is a controlled restore into a separate test environment, not an experiment on the live system. Agree the scope, permissions and expected cost before starting.
Ask the technical team to prevent the restored copy from sending real emails, taking payments, publishing changes or running jobs against live services. Restrict access to restored personal or confidential information, and agree how test resources and data will be removed afterwards.
Choose an actual saved backup and record its date. Follow the written recovery instructions, noting every missing step or unexpected dependency. If the exercise only succeeds because one person remembers an undocumented setting, update the instructions while that detail is fresh. The rehearsal should improve the process, not merely produce a reassuring screenshot.
Check useful work, not just a loaded page
A restored resource and a usable application are not the same test. AWS documents a separate validation stage after a restore job completes, including application health checks as an example.
Record both the technical restore duration and the total time until the acceptance checks pass. Include time spent finding access, resolving errors and obtaining confirmation. Those delays matter to the business too.
For your own acceptance checklist, ask a technical owner and a business user to verify:
- The expected records and uploaded files are present.
- A representative record opens with its related information intact.
- A safe test change can be saved and read back.
- Essential background processing works without contacting live customers.
- The restored data matches the selected backup point.
Make recovery part of the handover
Keep a short test record: system, backup date, people involved, elapsed time, checks passed, issues found and corrective actions. Assign each unresolved issue an owner, then repeat the affected checks after it is fixed.
Agree a review schedule appropriate to the system, and revisit the rehearsal after significant hosting, database or deployment changes. Avoid treating a successful exercise as a guarantee that every future incident will behave the same way.
When planning a Web Development or Custom Software project with Miracode, include recovery documentation and testing responsibilities in the scope discussion. Clarify what belongs to the business, developer and hosting provider. A maintainable system needs more than a launch checklist: it needs a practical, understood route back to service.
