A ransomware attack, server failure or site incident can stop an SMB in minutes. A disaster recovery plan turns that interruption into a controlled sequence: identify what must come back first, choose trustworthy recovery points, assign responsibilities and test the process before a crisis.

Disaster recovery and business continuity are not the same

A business continuity plan (BCP) keeps essential operations running during an incident, sometimes in a reduced mode. A disaster recovery plan (DRP) restores systems, applications and data so the organisation can return to normal operations.

The two plans reinforce each other. For many SMBs, the most useful starting point is a focused DRP covering the applications and data that directly affect revenue, customer service, safety or regulatory obligations.

Start with RPO and RTO

Two objectives determine the design of a recovery plan:

  • Recovery Point Objective (RPO): the maximum acceptable amount of data loss, expressed as time. An RPO of four hours means the backup schedule and retention design must provide a usable recovery point no more than four hours old.
  • Recovery Time Objective (RTO): the maximum acceptable time before a system is operational again. An RTO must include detection, decision-making, access to clean backups, recovery and validation, not only the copy time.

Set these objectives per application. An ERP, identity service or production database may require a much shorter target than an internal archive. A single target for the entire estate usually overprotects low-value systems and underprotects critical ones.

Six steps for an actionable disaster recovery plan

1. Map critical systems and dependencies

List applications, servers, SaaS services, identity systems and data stores. Then document their dependencies: DNS, networking, authentication, certificates, databases and third-party services. A server restored without the services it depends on is not a recovered business process.

2. Prioritise risks and recovery order

Consider ransomware, hardware failure, accidental deletion, cloud or supplier failure and physical incidents. Define the order in which services must return. Recovery should follow business priority, not whichever server is easiest to restore.

3. Assign RPO and RTO per workload

Agree targets with business owners and make them measurable. The backup frequency, retention, network capacity and recovery platform must be capable of meeting those targets in real conditions.

4. Use a 3-2-1-1 backup design

Maintain three copies of the data on two types of media, with one copy off site and one copy offline or otherwise out of reach of the production environment. The final copy is decisive during ransomware recovery: it must remain usable even when production and administrative credentials have been compromised.

5. Document the recovery procedure

Record who declares the incident, who can access backup systems, which systems are restored first, where encryption keys and credentials are held, and how a restored system is validated. Keep an accessible copy outside the production environment.

6. Test and record the results

A plan that has never restored a real workload is only a hypothesis. Run partial tests regularly and a complete exercise on a defined schedule. Record the recovery point used, elapsed time, dependencies, failures and corrective actions.

Why the recovery point matters more than the backup job

Modern attackers target backups before encrypting production. A completed job is therefore not enough: the resulting restore point must be isolated from the compromised environment and protected against overwrite or deletion.

With Oxibox, data is encrypted at the source and every backup is disconnected from production after transfer through a software air gap. Committed restore points use an append-only write path with an extend-only retention floor. Behavioural analysis examines writes as an additional defence; the protection of committed points does not depend on an AI verdict.

This distinction is essential in a DRP. The team can start recovery from a point whose integrity does not rely on the production network or on an uncompromised administration console.

Plan for recovery across environments

Hardware and virtualisation platforms may not be available after a major incident. The recovery design should therefore cover more than a return to the original host. Oxibox supports recovery across VMware ESXi, Microsoft Hyper-V, Proxmox VE, Nutanix AHV and KVM-based environments, as well as physical systems through bare-metal backup.

Individual systems can be restarted in minutes with R2V recovery. A complete information system takes longer because services must be restored and validated in dependency order; in one real ransomware incident, an entire information system protected by Oxibox was restarted in under two hours.

A practical DRP checklist

  • Critical applications and their owners are identified.
  • Dependencies and recovery order are documented.
  • RPO and RTO are defined per workload.
  • At least one recovery copy is disconnected from production.
  • Backup encryption keys and emergency credentials are accessible during an outage.
  • Recovery procedures are available outside the affected environment.
  • Tests include both files and complete systems.
  • Test results and remediation actions are retained as evidence.
  • Suppliers, MSPs and internal teams know their responsibilities.
  • The plan is reviewed after infrastructure or business changes.

From document to recovery capability

The value of a disaster recovery plan is not the document itself. It is the verified ability to start from a clean recovery point and bring critical services back within the agreed time. Begin with the systems that matter most, test them end to end, and extend coverage iteratively.

For the technical recovery layer, review the Oxibox deployment options and the bare-metal backup guide.