Companies talk about backup as if it were the same thing as continuity, but it is not. A backup tells you the data exists somewhere. Operational continuity tells you whether you can start invoicing again, ship orders, handle incidents and close the day after a failure. These are different problems. Confusing them is expensive.
Having a copy is not the same as being able to operate again.
The difference feels theoretical until the incident happens. Then the uncomfortable questions appear: what gets restored first, who approves the order, which systems depend on which, how long until we discover the restore will not boot or credentials are missing? Many companies do not fail because they lack backups. They fail because they never rehearsed a full recovery.
The mistake of thinking in data when the business needs processes
A backup protects files, databases and virtual machines. But business does not run on files; it runs on processes. If your ERP comes back before ecommerce, but stock is not reconciled, operations collide. If email returns before authentication, the team may start working but not with real security. If the database is restored but payments are still down, sales are not recovered.
That is why it helps to think in terms of critical services, not just systems. A critical service usually combines several pieces:
- Identity and access
- ERP or order management
- Ecommerce or sales channel
- Database and storage
- Integrations with logistics, billing or support
The useful question is not “Is it backed up?” It is “What has to be ready to resume this specific function?”
What you should really measure: RTO, RPO and operational dependency
Three metrics should move from theory into executive discussions:
- RPO: how much data loss you can tolerate.
- RTO: how long you can afford to be down.
- Recovery order: what comes back first and why.
In many companies, RPO is measured in hours because “backup runs every night”, but RTO is unknown. That gap is dangerous. If you do not know how long it takes to get back to work, your backup is only a partial insurance policy.
A practical rule: define by process, not by technology. For example, “processing orders” may require ERP, ecommerce, stock, payment gateway and shipping labels. If one of those pieces is missing from the plan, the process is still broken even if everything else works.
Another important detail: restores must be tested in an isolated environment, with real anonymized or cloned data, and with the full timeline. Restoring a test file proves almost nothing. Restoring a complete operation does.
Mini case: when the copy existed, but nobody could sell again
A mid-sized distribution company had daily backups, cloud replication and a provider confident that everything was covered. After a ransomware incident, the critical files were there, but the restored environment failed for three reasons: credentials had changed, a carrier integration was undocumented, and the ERP required a manual validation step nobody knew how to perform.
The result was not total data loss. It was something more uncomfortable: three days of partial operations, blocked orders and teams improvising with email and spreadsheets. The lesson was not “we need more backup”. It was “we need a tested recovery sequence, with owners and dependencies visible”.
That scenario is common because many organizations protect components, not business flows.
The uncomfortable decision: not everything should come back at once
Here is the part leadership often dislikes: in a serious recovery, not everything comes back at once. And it should not.
Trying to bring every system up simultaneously usually makes things worse. It creates data collisions, inconsistent access and a false sense of progress. It is better to accept a hierarchy:
- Identity and access
- Critical data and transactions
- Sales and dispatch processes
- Auxiliary systems and analytics
This forces a decision many organizations avoid: which processes have real priority and which can wait a few hours. That is not a purely technical decision. It is a business decision.
It is also worth deciding what to automate and what to keep manual during recovery. Sometimes a documented manual step is more reliable than untested automation. The obsession with “fully automated” recovery can hide fragility.
Signs your plan is not ready
Some signs are very clear:
- Nobody knows the ERP or ecommerce RTO.
- The last drill was partial or done “without impacting anyone”.
- Dependencies on external providers are not inventoried.
- Recovery depends on one specific person.
- Credentials, keys or secrets are not included in the plan.
- The recovery order is decided during the incident.
If you recognize two or more, you do not have a strong continuity plan; you have backup documentation.
What to do before the next incident
Start with a simple map of critical services and dependencies. Then define:
- RTO and RPO per service
- Recovery priority
- Owner for each step
- Quarterly or semiannual test with evidence
- Procedure for credentials, access and configuration changes
The goal is not to design a perfect fortress. It is to reduce decision time when something fails. Because in a crisis, the biggest cost is not always data loss; often it is the time lost deciding how to get back to work.
At Codefuente, we usually see the best improvements start not with more technology, but with a serious definition of what “recovery” actually means for each business.