Disaster recovery plan: what an SMB really needs to prepare

A disaster recovery plan is not a fifty-page document. It is the written answer to a simple question: if our IT stops right now, what do we do, in which order, and how long until we are back? In many Moroccan SMBs, that answer lives only in the heads of one or two people: the IT manager, the provider, sometimes the managing director. The day the server will not restart, ransomware encrypts the files or water damage hits the server room, the company discovers it is improvising. This guide explains the decisions to make, the scenarios to cover, what goes into the plan and how to test it without stopping the business.

DRP, BCP: what are we talking about?

The two acronyms are often confused:

• The disaster recovery plan (DRP) organises the restart after an outage: restoring systems, data and access, in a defined order.
• The business continuity plan (BCP) aims to avoid the outage: redundant equipment, automatic failover, degraded-mode procedures.

A full BCP is expensive and only justified for activities that tolerate almost no interruption. For most SMBs, the priority is a realistic, tested DRP, complemented by a few continuity measures targeted at the most critical points.

Two numbers to decide first

• RTO (recovery time): how many hours of downtime can you accept? A clinic says “two hours”, an accounting firm “one day”, except in tax season.
• RPO (acceptable data loss): how many minutes or hours of work can you lose? This number sets backup frequency.

These two values dictate the budget. A two-hour RTO requires standby servers ready to start; a 48-hour RTO is satisfied by good backups and replacement hardware on hand.

These are management decisions, not technical ones. The IT team’s role is to put a cost on each level; the manager’s role is to choose, application by application. Email, the ERP, the point-of-sale software or the patient record do not necessarily share the same RTO.

Target RTO	What must be in place	Typical profile
A few hours (for example two hours)	Standby servers ready to start, virtual machine replication, a rehearsed failover procedure	Businesses that stop dead without IT: healthcare, production, customer reception
One day	Local backups that restore quickly, identified replacement hardware, a restore already timed	Firms, offices, departments that can work a few hours in degraded mode
48 hours	Good backups, including an off-site immutable copy, and replacement hardware on hand	Activities where a short outage is a nuisance but not critical

Scenarios to cover

Hardware failure, ransomware, fire or water damage, extended power cut, human error, departure of an administrator. Each scenario has a different answer. Ransomware, for instance, requires immutable backups and a network that can be isolated within minutes.

Scenario	What is lost	Main response
Hardware failure	A server, a storage array, a network device	Redundancy or replacement hardware, restore from the local backup
Ransomware	Encrypted data, reachable backups, sometimes admin accounts	Isolate the network, immutable off-site backup, rebuild identity first
Fire or water damage	The entire server room	Off-site copy, replacement hardware, a planned restart location
Extended power cut	Access to local servers	UPS units for a clean shutdown, essential services reachable off site
Human error	Deleted files or database, broken configuration	Granular restore, retention long enough to go back before the error
Departure of an administrator	Passwords, knowledge of the system	Shared password vault, up-to-date documentation, named accounts

Ransomware is the most demanding scenario, because it hits the backups too. Our article on the 3-2-1-1-0 rule and immutable backups explains how to keep a copy out of reach, and the one on the seven measures against ransomware covers prevention.

The plan itself, on one page

Who decides to trigger the plan. Who calls whom, with numbers. Where the backups are and how to reach them without the company network. In which order to restore: identity, network, email, ERP, files. How to inform customers and suppliers.

That order is not arbitrary. Without identity (directory, accounts, MFA), nobody can log in to anything. Without the network (firewall, switches, internet access), restored systems remain unreachable. Email then lets you communicate with customers and staff, before bringing back the ERP and finally the files, which are often large and less urgent.

The document must be available outside the system it is meant to rebuild: a printed copy in a known place, a copy reachable without the company network. A DRP stored only on the file server disappears with it.

Step-by-step method

1. Inventory applications, servers and data, with their business owner.
2. Set the RTO and RPO of each application with management.
3. Compare those targets with reality: backup frequency, storage location, restore time already measured.
4. Close the gaps: immutable backup, replacement hardware, replication, or, when the RTO is short, a high-availability virtualised infrastructure.
5. Write the page: triggering, contacts, access to backups, restore order, communication.
6. Test, measure, fix, then start again the following quarter.

What drives the effort and the budget

Two SMBs of the same size can have very different DRPs. The main factors are:

• The chosen RTO and RPO: they weigh the most, because a short outage and minimal data loss require redundancy and frequent backups.
• The number of critical applications and their dependencies: an ERP tied to a database, a directory and client workstations needs more preparation than a simple file share.
• How much of your IT is hosted on site versus in the cloud, which changes the scenarios to cover and the means of restoring.
• The number of sites to bring back and the quality of the links between them.
• Existing documentation: starting from an up-to-date inventory greatly reduces the initial work.
• How demanding the tests are, from one restore per application to a full rebuild in an isolated environment.

The most common mistakes

In SMBs, the same gaps keep coming up:

• An RTO set by default. Nobody decided it, and during the incident you discover that the restore takes far longer than the business can bear.
• Backups unreachable without the network. The credentials live in the directory that needs rebuilding, or the console is only reachable from an internal workstation.
• Outdated phone numbers, or a single emergency contact who is on leave on the day.
• A plan never reread after a change of server, provider or application.
• Communication forgotten: customers, suppliers and staff find out about the outage on their own.

The test, or nothing

A DRP that has never been tested is a hypothesis. With our clients we run a timed full restore at least once a quarter, in an isolated environment, and update the document at every gap found.

The test runs without stopping production: systems are restored into an isolated network, where you check that applications start, that data is consistent and that key users can work. The stopwatch gives the real RTO; the date of the last restored point gives the real RPO. If either one exceeds the target, the plan or the infrastructure has to change.

Checklist: where your DRP stands

• The RTO and RPO of every critical application are written down and approved by management.
• One copy of the backups is off site and immutable.
• Backups can be reached without the company network or directory.
• The restore order is defined: identity, network, email, ERP, files.
• Emergency contacts are up to date, with at least one deputy.
• The plan exists in print and outside the file server.
• A full restore is tested every quarter, and every gap is fixed.

The DRP is part of our cybersecurity service and of our high-availability virtualisation architectures. To define your recovery targets and check they are achievable, contact us.