Information checked: 21 July 2026.
A backup strategy translates business tolerance for downtime and data loss into scope, frequency, retention, storage and restoration testing. Copying website files occasionally is not a strategy.
In brief: Design backups from recovery objectives and assume the live account itself may be lost.
Set recovery objectives
| Question | Example decision |
|---|---|
| How much recent data can be lost? | No more than one hour of orders |
| How long can the service be unavailable? | Basic enquiries restored within four hours |
| Which assets are irreplaceable? | Uploads, database, DNS and custom code |
| Which systems change independently? | Website, payment provider, CRM and booking service |
| Who can authorise restoration? | Named business owner and technical lead |
Use multiple protected copies
- A fast operational copy for routine rollback.
- A versioned copy in a separate security boundary.
- An offline or otherwise strongly isolated copy for severe incidents where proportionate.
- Documented exports from external services that cannot be reconstructed from the website alone.
Define retention and deletion
Keep enough versions to recover from damage discovered late, but avoid indefinite retention without purpose. Align personal-data retention and deletion with the business’s documented policy.
Acceptance check
Run a scenario in which the live hosting account is unavailable. The strategy passes only if the business can access backups, instructions and credentials without that account or the original supplier.
Protect against slow discovery
A harmful change may remain unnoticed for weeks. Keeping only the latest copy can preserve the damage while deleting the last clean version. Use versioned retention that reflects how quickly different problems are likely to be discovered.
Records to keep
- Retention schedule by backup class.
- Deletion and immutability controls.
- Late-discovery scenario.
- Annual strategy review.
Owner test: Choose an incident discovered 30 days late and identify which retained copy, credentials and documentation would support recovery.
Assign authority for destructive restoration
Restoring an old database can remove valid recent records. State who may authorise that action, what reconciliation must happen first and how a read-only copy of the current state is preserved. This decision is operational and business-critical, not merely technical.
Sources and date checked
This practical guidance was checked against the following primary sources. Date checked: 21 July 2026.
Keep the decision under your control
Retain the relevant accounts, source material, supplier terms and recovery information. Recheck changing prices, interfaces and rules before acting.