A business has backups. They have run every night for four years and the reports say successful.
A server fails. The restore is attempted and the data is there, except for one system that was excluded during a change eighteen months ago and one database that was being backed up while in use and is unusable.
Getting the business functioning takes four days. Nothing had ever been tested, because the reports said successful and nobody had any reason to look further.
1. Test a restore, and do it regularly
The only evidence that backups work. A successful backup job proves that something was written, and only a restore proves that something useful can be read.
2. Establish the recovery time honestly
How long from failure to working. Businesses assume hours and discover days, and the difference determines whether the arrangement is adequate.
3. Establish how much data can be lost
How far back the most recent usable copy is. A nightly backup means up to a day of work gone, which may or may not be acceptable and is rarely discussed.
4. Check what is actually included
Systems added since the arrangement was set up, new applications, cloud services and anything moved. Exclusions accumulate silently and are found during a restore.
5. Check the cloud services are backed up
Email, documents and business applications hosted elsewhere are frequently assumed to be backed up by the provider, and the protections are not what people assume.
6. Keep a copy that is genuinely separate
Different location, different account, different credentials. A backup reachable from the compromised system is a backup that will be compromised with it.
7. Keep a copy that cannot be altered
Protection against deletion or encryption matters more than protection against hardware failure now, and an immutable or offline copy is what provides it.
8. Check the retention period
How far back copies go. A problem introduced weeks ago and discovered today needs a copy from before it, which a short retention period does not provide.
9. Check who would actually perform a restore
By name, and whether they have done it. A documented process nobody has followed is a plan rather than a capability.
10. Document the restore order
Which systems first, what depends on what and what the business needs soonest. Restoring everything simultaneously is not possible and the order should be decided in advance.
11. Check the restore can happen without the network
If the failure is the network, a process depending on it does not work. This is the most commonly missed dependency.
12. Keep the documentation somewhere reachable
Credentials and procedures stored only on the system being restored is a well known and still common failure.
13. Review it whenever anything changes
New systems, moved data and changed providers, which is the ongoing work described in managed service enquiries from small businesses.
14. Answer the client's backup questions plainly
An assistant that explains what is backed up, how often, how far back copies go, what the recovery time is and when a restore was last tested gives a client the answers they need for insurance, compliance and their own peace of mind. The security side sits in security questions from clients worried about a breach, the validation approach in testing assistant with real past enquiries, and the same verification discipline in gp and clinic referral questions for private testing. See features, start at try, and the sector view sits under it services.