11 August 2026 · 3 min read
A backup is only a backup if you can bring the data back. It sounds obvious, but it is the test that separates a plan that survives a bad day from one that does not.
What can go wrong
Data loss in a small business rarely announces itself. The cause is usually something you would not call a disaster: a database that corrupts during an update, a file deleted or edited by mistake, a disk that fails, a web host that drops a configuration change and takes the site down with it. Ransomware and theft are rarer but more severe, and they are the reason one copy of a backup is never enough.
The 3-2-1-1 rule
Keep three copies of what matters, on two different kinds of storage, with one copy somewhere other than your office. The extra copies exist because a single backup shares failure paths with the system it protects. A file lost to a mistaken delete is missing from that day’s backup too, and the copy you can trust is yesterday’s.
The fourth copy is the one that survives an attack on the backups themselves. It has to be either immutable, written once and locked so nothing can change or delete it for a set period, or offline, disconnected from the network and attached only when a restore actually happens. Ransomware works by finding the backups that are still reachable and encrypting them alongside everything else. The copy that matters in that scenario is the one the attack never had access to.
Two numbers to agree on
Two measurements describe a backup strategy, and they are worth agreeing with whoever runs your systems before you need them, not after.
Recovery point. How much data can you afford to lose? If your backups run nightly, the honest answer is up to a day of work. For transactional systems, the bar may need to be minutes, which changes how often you need to snapshot.
Recovery time. How long can the business run without the system? A website down for an hour and a database down for a day are different problems, and they call for different restore plans.
Writing those two numbers down, even roughly, turns “we back up everything” into a strategy you can defend and improve.
A baseline to start from
- Keep at least three copies: the live system, a local backup, and an off-site copy. At least one of them should be immutable or offline, so an attack that reaches the others leaves it intact.
- Back up what would be painful to retype: databases, site files, code, configuration, and customer records.
- Schedule the jobs and watch them run. An unattended backup that fails quietly is worse than none, because it builds false confidence.
- Test a restore at least once a year, ideally on a copy of the system rather than the live one. It is the step people skip first, and the one that tells you whether the rest of the plan is real.
- Keep the off-site copy somewhere the rest of your infrastructure cannot reach, so a single incident does not take everything.
None of this is exotic or expensive at a small-business scale. The parts that cost money are the testing and the planning, and those are the parts that decide what a bad day actually costs you.