Business Continuity: Why Backup Is Not Enough

A few weeks ago, a client told me with complete calm: "We're covered, we back up every night." I asked a single question: "When was the last time you restored that backup and measured how long it took to be operational again?". The silence that followed was more eloquent than any report. After a year marked by WannaCry and by a wave of ransomware that left entire companies staring at an encrypted screen, I keep finding the same dangerous confusion: believing that having copies is the same as being able to recover. They are not the same. And the difference, when the incident arrives, is measured in money, reputation, and sometimes the survival of the business.

The short version: a backup only stores data; business continuity guarantees that you can resume operations within an acceptable time and with an acceptable loss of information. Without defined recovery objectives (RTO and RPO) and without real testing, a backup is a promise no one has verified, and unverified promises tend to fail precisely when you need them most.

Why isn't backup, on its own, enough?

Backup answers one question: "Do I have a copy of my data?". Continuity answers a much more demanding one: "How long does it take me to get back to work, and how much information am I willing to lose?". These are different questions, and the second is the one that determines whether your company survives a serious incident.

In my experience, backups fail at the worst moment for very concrete reasons:

• They were never tested. The file exists, but when you restore it, it is corrupted, incomplete, or missing a critical dependency.
• They were in the same place. A copy on the same server or the same network as the original system gets encrypted or damaged along with it. That is exactly what ransomware looks for.
• They take too long to restore. Recovering several terabytes can take days; meanwhile, the operation is at a standstill.
• They cover the data, but not the environment. Having the database is useless if you cannot rebuild the server, the network, the configurations, and the access that make it work.

A backup that was never restored is not a backup: it is a hypothesis. And hypotheses are not tested during a crisis.

RTO and RPO: the two figures that change the conversation

When a company starts talking seriously about continuity, it stops asking "how often do we back up?" and begins to define two objectives:

• RPO (Recovery Point Objective): how much information you can afford to lose, measured in time. If your RPO is one hour, you need backups or replicas at least every hour; if it is one day, a nightly copy might suffice.
• RTO (Recovery Time Objective): how long a process can be down before the damage becomes unacceptable. It is the clock that runs from the moment the incident occurs until you are operational again.

What is powerful about these two numbers is that they turn a technical decision into a business decision. Defining the RTO of billing or the RPO of the order system is not the IT function's task in isolation: it is a conversation among those who know the real cost of each hour of paralysis. Once those figures exist, the technology architecture stops being an opinion and becomes a measurable requirement.

DRP vs. BCP: how do they differ, and why do you need both?

This is where I see the most confusion, so it is worth separating them clearly.

The DRP (Disaster Recovery Plan) is the technology recovery plan. It answers "how do I bring my systems, data, and infrastructure back up after a disaster?". It is the domain of servers, replicas, alternate data centers, and restoration procedures. If you want to go deeper into how one is designed, we develop it in detail on our page about disaster recovery plans (DRP).

The BCP (Business Continuity Plan) is broader. It answers "how does the business keep functioning while the technology recovers, or while we face any major disruption?". It includes people, processes, suppliers, customer communication, alternate locations, and chain-of-command decisions. Technology is a part, not the whole. Our complete view of business continuity (BCP) starts precisely there.

The relationship is hierarchical: the DRP is a component of the BCP. You can have an impeccable DRP and still fail if, during the outage, no one knows who decides, how customers are served, or where staff work. And vice versa: a well-thought-out BCP without a DRP to back it is a plan with no technical muscle to sustain it.

The year of ransomware: a lesson we should not forget

What 2017 taught us is that threats to continuity are no longer just fires, floods, or hardware failures. WannaCry showed that an attack can spread across a network in minutes and leave an entire organization inoperable without warning. Ransomware changed the calculus for a specific reason: it attacks trust in backups directly.

Attackers learned to seek out and encrypt backup copies before triggering the hijack. That is why the defenses I recommend to my clients revolve around simple but demanding principles:

• Real separation: at least one copy offline or on an isolated network, out of reach of an attacker who is already inside.
• Immutability: backups that, once written, cannot be modified or deleted for a defined period.
• Geographic diversity: so that a physical or logical incident in one location does not compromise every copy.
• Managed replication: maintaining a secondary site or environment that can take over the operation. For this we deliver replication and recovery solutions such as SyncDR, which drastically reduce the time to return to operation.

How do you build real resilience?

Resilience is not bought, it is built in layers and maintained. The path I walk with companies usually takes this shape:

• Business Impact Analysis (BIA). Identify which processes are critical and how much each hour of disruption costs. Without this, everything else is guesswork.
• Definition of RTO and RPO by process. Not everything deserves the same protection; billing is not the corporate blog.
• Design of the DRP and BCP. Technology and business aligned on the same objectives.
• Implementation with redundancy and separation. Isolated copies, replicas, and documented procedures.
• Regular testing. Real restorations, drills, and tabletop exercises that measure whether the promised times are met.
• Continuous review. Systems change, risks change; the plan must change with them.

The step most often skipped and the most important is testing. A plan that is never rehearsed ages in silence: a server changes, an application is updated, a key person leaves, and the document keeps saying what was true two years ago. The only way to know whether your company can recover is to attempt recovery before it becomes mandatory.

Where do you start if you feel you're behind?

You do not need to solve it all at once. If I had to choose three actions for the coming weeks, they would be these: restore a recent backup in an isolated environment and measure how long it takes; confirm that at least one copy exists out of reach of the main network; and bring the business functions together to agree on how many hours of paralysis and how much data loss would be tolerable in their critical processes. Those three answers will tell you, without beating around the bush, how exposed you are today.

Frequently asked questions

Does a cloud backup already guarantee me continuity?
Not on its own. The cloud makes geographic separation easier, but continuity depends on having defined recovery objectives, verified copies, and a plan that also covers processes and people, not just data storage.

How often should I test my backups?
It depends on the criticality of the system, but a real restoration of the most important systems at least a couple of times a year is a reasonable minimum. What is essential is that the tests be real and measure recovery time, not just that the file opens.

Do I need a DRP and a BCP if I'm a midsize company?
Yes, though their scope will be proportional to your size. Even a simple version, defining critical processes, owners, and basic recovery procedures, gives you an enormous advantage over having nothing when the incident occurs.

Does ransomware change my backup strategy?
It changes the assumption that your copies are safe simply by existing. It forces you to have isolated or immutable copies, out of reach of an attacker who is already inside the network, because today backups are a deliberate target of the attack.

The first step

If, after reading this, you are not sure how long it would take your company to resume operations after a serious incident, that uncertainty is, in itself, the answer. The first step is not to buy more technology: it is to measure where you stand today. At SUMāTO we conduct a continuity assessment that evaluates your backups, defines your RTO and RPO by process, and hands you a clear map of gaps and priorities, with no strings attached. Let's talk about the resilience of your operation through our contact page, and let's turn that uncomfortable question into a plan you can test before you need it.