Backup and disaster recovery are not the same thing
A backup answers whether you still have the data. Disaster recovery answers how long you will be closed. Most businesses have the first and assume it covers the second.
The two get used as one phrase, which hides an expensive difference.
A backup is a copy of your data. It answers one question: do we still have this?
A disaster recovery plan is how you resume operating. It answers a different question: how long will we be closed, and what will that cost?
You can have a perfect backup and still be down for a week, because having the data is not the same as having somewhere to run it, a way to reach it, and a documented sequence for bringing it back.
The two numbers that matter
Every recovery conversation reduces to these, and they are business decisions rather than technical ones.
Recovery point objective
How much data you can afford to lose, measured in time. If you back up nightly at 23:00 and the server fails at 16:00, you have lost a day of work. For a firm processing a handful of documents a day that may be tolerable. For one taking hundreds of orders it is not.
Recovery time objective
How long you can afford to be down. This is where assumptions collapse. Restoring a few terabytes from cloud storage over a typical business line takes considerably longer than most people estimate, and that is before anyone has procured replacement hardware or rebuilt an operating system.
Work out what a day of downtime actually costs you, in wages paid for work not done, orders not taken and commitments missed. That figure tells you what recovery capability is worth paying for.
Why backup alone leaves a gap
Consider a server that dies on a Monday morning, with good backups in place.
- Source replacement hardware. Days, if it is not held in stock.
- Install and configure the operating system and roles.
- Restore the data, at whatever speed the connection allows.
- Reconnect applications, licences and integrations.
- Verify that everything works before letting staff back in.
Nothing there is unusual, and none of it is fast. The data was never the problem.
What closes the gap
- Local and offsite copies. Local for speed, offsite for the fire, the flood and the theft.
- Immutable copies. Backups that cannot be altered or deleted for a set period, including by an administrator account. This is what defeats ransomware, which now targets backups first.
- Virtual standby. The ability to run a failed server directly from the backup appliance or in the cloud, so you are operating in hours rather than days.
- A written plan. Who declares a disaster, who does what, in what order, and which systems come back first. Written down, because the people who know may be unreachable.
- Tested restores. On a schedule, with recorded results. An untested backup is not a backup.
Power is still a local factor
National load shedding has been suspended since May 2025, and Eskom reported over 460 consecutive days without it in August 2026. That is a genuine change, and it has quietly removed the assumption many recovery plans were built on.
It has not removed power as a risk. Load reduction continues in parts of Gauteng and KwaZulu-Natal, targeting specific areas where local infrastructure is overloaded, on schedules that rotate weekly. Municipal faults, cable theft and ageing distribution equipment produce unplanned outages that arrive with no notice at all, which is worse for equipment than a scheduled cut.
The practical implications are unchanged. Repeated unclean shutdowns damage disks and corrupt databases, and a site with no power has no network regardless of what the servers are doing. Adequately sized UPS units, inverter or generator capacity for critical equipment, and a decision about which systems must stay reachable during an outage all still belong in the plan. It also remains a straightforward argument for moving key workloads to Microsoft 365 or Azure, where the power problem becomes somebody else's.
Where to start
Answer three questions honestly. How much data can we afford to lose? How long can we afford to be closed? When did we last prove a restore works?
If the third answer is never, that is the place to begin. We build backup and disaster recovery around your own recovery targets, with restores tested on a schedule and the results shown to you.