Disaster recovery planning for small businesses

Picture a Monday morning where the website is gone, the order database will not open, and the only person who knew how the email server was configured left in the spring. Nobody planned for it, so everyone improvises, and the improvising is what costs the day.

Disaster recovery sounds like something only large companies bother with. In practice the small business is the one that can least afford a long outage, because it has fewer people to throw at the problem and thinner cash reserves to ride it out.

Hope is not a plan#

Most small firms have a quiet assumption that someone, somewhere, has a backup. When the bad day arrives that assumption tends to dissolve. The backup was on the same server that failed, or it stopped running months ago and nobody noticed.

A real plan replaces hope with two things: a written record of what you would actually do, and tested copies of your data sitting somewhere the disaster cannot reach. The National Cyber Security Centre lays out the essentials in its response and recovery guidance for small organisations, and it is far less daunting than the phrase disaster recovery suggests.

Two numbers that drive everything#

Before you buy a single tool, agree two numbers with whoever runs the business. They shape every later decision, and they stop the conversation drifting into vague reassurance.

RTO#

Recovery time objective is how long you can be down before the damage becomes serious. For a busy online shop that might be an hour. For a small studio that takes bookings by email it might be most of a working day. Be honest rather than ambitious, because a shorter target costs more to guarantee.

RPO#

Recovery point objective is how much data you can afford to lose, measured in time. If your backup runs once a night and you fail at four in the afternoon, you have lost a day of orders. If that is unacceptable, you need backups that run far more often. Setting this number tells you exactly how frequently your copies must be taken.

Once those two figures are written down, the rest of the plan almost designs itself. They decide how often you back up, how fast your restore process needs to be, and how much it is worth spending. Our backup service is built around these same two ideas rather than a vague promise that everything is safe.

Writing a runbook people can follow#

A recovery plan that lives only in one person's head is not a plan. It is a single point of failure with a pulse. The fix is a runbook, which is simply a plain document that says who does what, in what order, when something goes wrong.

Keep it boringly literal. List the systems in priority order, name the person responsible for each, and write the actual steps to restore them rather than a summary. Include the phone numbers for your hosting provider and any key suppliers, because nobody remembers them at the worst possible moment.

Write it so a capable colleague who is not a technical specialist could follow it while the specialist is unreachable. That test alone usually exposes the gaps. For a sense of how larger organisations formalise this, the international standard for business continuity, ISO 22301, describes the same instincts scaled up.

Where to store the plan#

There is a grim irony in storing your disaster recovery plan on the very systems a disaster would take down. If the document explaining how to restore the server is only on that server, you have a problem.

Keep at least one copy somewhere completely separate. A printed sheet in a folder, a copy in a separate cloud account, a version on a phone that key people carry. The same logic applies to the backups themselves, which is why offsite copies matter so much. Continuous, offsite protection of the kind offered by our R1Soft backup option means the recovery data survives even when the primary site does not.

While you are at it, store the credentials safely too. Recovery often stalls because nobody can log in to the thing they need to restore. The NCSC has sensible advice on protecting business data that covers this without drowning you in jargon.

Testing once a year#

An untested plan is a guess. The only way to know your backups restore cleanly and your runbook makes sense is to rehearse, ideally at least once a year.

You do not need to stage a full crisis. Pick one system, restore it to a spare environment, and time how long it takes against your recovery time objective. You will almost always learn something useful: a backup that was silently failing, a step that no longer matches reality, or a target that was never realistic.

Treat each rehearsal as routine maintenance rather than an exam. Government guidance for small firms on keeping a business resilient frames continuity as an ongoing habit, and that framing is the right one. The businesses that recover fastest are rarely the luckiest. They are the ones that practised while the sun was still shining.

None of this requires a large budget or a dedicated IT department. It requires an afternoon to write the plan, a sensible backup arrangement, and a reminder in the calendar to test it. Set that up now and the bad Monday becomes an inconvenience rather than a catastrophe.