Disaster Recovery & Backup for SA Business — What Actually Works

Why DR matters more in South Africa

SA businesses live with a stacked risk profile: load-shedding kills hardware; Eskom voltage events fry equipment; ransomware crews target mid-market companies weekly; and cloud misconfigurations quietly erase data nobody notices until it's needed. Insurance is tightening — you can't claim cyber cover in 2026 without proving MFA, immutable backups and tested restores. DR isn't an IT project anymore. It's a governance obligation.

RTO, RPO and the honest maths

Pick your RTO and RPO per system, not for the whole business. Payroll and finance systems usually need tight numbers; the marketing team's file share can survive 24 hours down.

• RTO ≤ 1 hour, RPO ≤ 15 min. Trading, e-commerce, mission-critical apps. Requires warm/hot DR — real money.
• RTO ≤ 4 hours, RPO ≤ 1 hour. Typical SME finance/ERP/CRM. Cloud-based DR-as-a-Service fits well.
• RTO ≤ 24 hours, RPO ≤ 24 hours. General file shares, non-critical apps. Traditional daily backup is usually enough.
• RTO ≤ 72 hours. Archive, compliance data. Cold cloud storage is fine.

The 3-2-1 rule, updated for 2026

• 3 copies of your data — production + 2 backups.
• 2 different media types — e.g. cloud + local NAS.
• 1 copy off-site — different physical or cloud location.
• +1 immutable copy — cannot be modified or deleted even by admins during a defined retention window. This is the anti-ransomware layer.
• +1 tested — a copy that has been successfully restored in the last 90 days. Untested is unproven.

Modern industry shorthand: 3-2-1-1-0 — three copies, two media, one off-site, one immutable, zero errors on last restore test.

The 4 layers of a real DR plan

1. Endpoint / user data. Laptops sync to OneDrive/SharePoint with retention + third-party backup. Never rely on the user to back up their own device.
2. SaaS data. Microsoft 365, Google Workspace, HubSpot, Xero — every SaaS platform needs its own third-party backup with independent credentials. See our M365 backup guide.
3. Server / VM workloads. Image-based backup (Veeam, Nakivo, Datto) with off-site replication to a cloud DR target. RTO measured in hours, not days.
4. Runbook. The written, tested document — who calls whom, who has admin credentials in the offline vault, who talks to customers, who talks to the regulator (POPIA breach = 72 hours). No runbook = no DR.

Ransomware-proof design principles

• Immutability is non-negotiable. If your backup admin's credentials can delete backups, ransomware will too. Use S3 Object Lock, Wasabi immutable buckets, or Veeam hardened repository.
• Air-gap or logical isolation. Backup infrastructure must not sit on the production Active Directory. Separate identity plane. Different MFA. Different admins.
• Long enough retention. Ransomware dwell time averages 20+ days before detonation. Backups that only go 14 days back are already infected. Minimum 60 days rolling immutable copies.
• Detection tied in. Backups feed anomaly alerts — sudden 40% file-change rate is ransomware, not user behaviour.
• Insurance-ready evidence. Monthly restore-test reports, immutable-copy attestations, MFA on backup consoles — cyber-insurance renewals demand this now.

Testing that catches the lies

1. Monthly file-level restore. Random file, random user, random day. Time it.
2. Quarterly application restore. Bring up a full VM or M365 mailbox in an isolated environment. Log in. Prove it works.
3. Annual full DR exercise. Simulated outage, follow the runbook, involve non-IT stakeholders. Debrief and update the plan.
4. Chaos-day (advanced). Unannounced: an engineer breaks something at 09:30 on a Tuesday. See what actually happens vs. what the runbook says.
5. Document every test — dates, results, defects, remediations. This is your insurance and audit evidence.

Frequently asked questions