Backup and Business Continuity Beyond the Basics
A backup that's never been tested for restoration, or an asset nobody knew existed, can undo months of planning. Here's how to build real continuity, not just a backup schedule.
A backup↗ is a safety net, but a net with holes is worse than none, because it gives false confidence. Backups only help if you know what needs protecting, have tested that you can restore it, and can keep working while recovery happens. Business continuity↗ is the planning that ties these pieces together so that a failure, ransomware↗ attack, fire, or flood becomes an inconvenience instead of a crisis.
You cannot back up what you have not listed
Start with an asset inventory: a list of the systems, data, and devices the organization depends on, with an owner for each. It is unglamorous, but everything else rests on it. Organizations that skip it often discover, in the middle of an incident, that an important system was never in the backup plan because nobody remembered it existed. 
Beyond the 3-2-1 rule: two numbers that drive everything
Personal advice often stops at "keep three copies, on two kinds of storage, with one off-site". Organizations must go further and decide two numbers for each important service:
| Term | The question it answers | Example |
|---|---|---|
| Recovery Time Objective (RTO) | How long can we be without this service? | The payroll system can be down for two days, but the emergency phone line for only minutes |
| Recovery Point Objective (RPO) | How much recent data can we afford to lose? | A weekly backup means up to a week of work can vanish, while continuous copying means almost none |
Shorter targets cost more, so set them by importance. Not every system needs the same level of protection. A third question completes the picture: can people keep working during recovery? A plan that restores computers but says nothing about how staff serve customers or citizens in the meantime is only half a plan. Paper forms, a spare phone number, and a printed contact list are often what keep an organization running.
The most commonly skipped step: testing restoration
A backup that has never been restored is an assumption. Try restoring from backup on a schedule, ideally to a separate environment, and treat a failure the way you would treat a failed security control, because that is what it is. Common surprises include backups that silently stopped months ago, missing files, passwords for encrypted backups that nobody can find, and restores that take far longer than planned.
Protect the backups themselves
Ransomware attackers often look for backups first and delete or encrypt them. Keep at least one copy offline or in a form that cannot be changed from your normal network, and limit who can delete backups. A backup the attacker can erase is not a backup.
Mitigation as a mindset
Mitigation means accepting that not every risk can be removed and focusing on reducing the damage when something goes wrong. Backup and continuity planning is a clear example: you are not preventing every failure, you are making sure that when one happens, you recover quickly and in good order.
A simple continuity checklist
- We have a current list of critical systems and data, each with an owner.
- Each critical service has an agreed RTO and RPO.
- At least one backup is offline or protected from deletion.
- We test a restore on a schedule and record the result.
- Staff know how to work, and whom to call, while systems are down.
- The plan is reviewed after every incident and every major change.
A continuity plan is only as strong as its least-tested assumption, and backups are the assumption most often left untested.
Related reading
