“We have backups” is what most owners say when the subject of an outage comes up, and it is usually true. It is also not an answer to the question that matters: how long would the business be down, and how much work would it lose? Backup and disaster recovery are related, but they are not the same discipline, and the gap between them is where organizations get hurt.
Backup is a copy; disaster recovery is a plan
A backup is a copy of data taken at a point in time and kept somewhere else, so that a file, a mailbox or a database can be brought back if the original is lost or damaged. It answers the question “can we get the data back?”
Disaster recovery is the set of arrangements that get the business operating again after a serious event: a server failure, a ransomware infection, a flood in the comms room, a cloud tenant compromised. It answers the questions “how quickly can we work again, on what, and who does what to make it happen?” It uses backups, but it also depends on spare capacity, documented procedures, tested restore times and people who know their roles. You can have excellent backups and no disaster recovery at all, and many businesses do.
RPO and RTO in plain language
Recovery Point Objective
The Recovery Point Objective, or RPO, is how much work you are prepared to lose, expressed as time. If backups run once a night and disaster strikes at four in the afternoon, you lose the day. If that is unacceptable, backups need to run more often, or the critical system needs continuous replication. RPO is set per system: an accounting database and a drive of old brochures do not deserve the same answer.
Recovery Time Objective
The Recovery Time Objective, or RTO, is how long the business can tolerate being without a system before the damage becomes serious. A long RTO can be met by rebuilding a server from scratch and restoring data onto it. A short one needs something ready to take over: a replicated virtual machine, a cloud copy that can be powered on, or a spare device already configured. The shorter the RTO, the more it costs to guarantee, so it should be chosen honestly rather than optimistically.
Setting both figures for each important system, and agreeing them with the people who run the business, is the most useful thing to do before spending on tools.
The 3-2-1 idea, and why immutable copies matter
A long-standing rule of thumb says keep three copies of your data, on two different types of storage, with one copy off site. The modern addition is that at least one copy must be beyond the reach of an attacker who has already got inside your network. Ransomware operators look for backups first, and a backup on a share the server can write to will be encrypted along with everything else.
An immutable copy cannot be altered or deleted for a defined period, even by an administrator; an offline copy is physically or logically disconnected between backup runs. Either turns a ransomware event from an existential threat into a bad week. Our managed backup service is built around this principle rather than treating it as an option.
Runbooks and testing cadence
A disaster recovery runbook is a plain, ordered document that says what to recover first, in what order, from where, using which credentials, and who makes each decision. It includes the phone numbers that are not stored in the email system that has just gone down, and it lives somewhere reachable when the office is not.
Testing is what separates a runbook from a wish. A sensible cadence is a scheduled test restore of individual files and mailboxes frequently, a full recovery of a critical system less often but at least periodically, and a walkthrough of the whole plan whenever something significant changes: a new application, a move to the cloud, a change of provider. Every test produces a measured recovery time to compare with the RTO, and a list of what did not work.
What “we have backups” usually hides
The sentence usually conceals one of a few problems: backups that run but are never checked, backups that succeed but exclude the system that matters, backups held on the same network as the data, retention too short to survive a slowly discovered problem, restores that have never been timed, and no plan for the day the building or the internet connection is the thing that fails. None of these are technology failures; they are questions that were never asked. Asking them, and writing down the answers, is what turns a backup into managed disaster recovery.
Common questions
What is the difference between backup and disaster recovery?
Backup is a copy of your data kept somewhere else so it can be restored. Disaster recovery is the plan and the capacity to get the business operating again after a serious event, including where systems will run, in what order they are restored, who does the work and how long it takes. Backup is one component of disaster recovery; on its own it does not tell you how long you would be down.
What is a reasonable RPO and RTO for a small business?
There is no universal answer, because it depends on how much lost work and downtime each system can absorb before the damage becomes serious. The right approach is to set them per system with the people who run the business, then design backup frequency and recovery capacity to meet them. A short RTO costs more to guarantee, so reserve it for the systems that truly need it.
Is a cloud copy of my data enough for disaster recovery?
A cloud copy is a good off-site backup, but disaster recovery also needs somewhere for systems to run while the original is repaired, a documented order of recovery, and a tested restore time. If the cloud copy can be spun up as working servers within your RTO, and someone has proven that, it can be the recovery platform. If it is only storage, it is a backup.
How often should disaster recovery be tested?
Test individual restores frequently, because they catch broken jobs early. Perform a full recovery of at least one critical system on a scheduled basis, and walk through the entire plan whenever a major change happens. Each test should record the actual recovery time against the objective and produce a list of fixes, so the plan improves rather than ages.
If you would like to know how long your business would actually be down, our managed backup and managed disaster recovery pages describe how we set objectives and test against them, and you can contact us to have your current arrangement measured rather than assumed.
