A company can have daily backups, cloud replication and a provider that “stores everything”, and still be frozen for hours or days when something breaks. The problem is usually not the lack of copies. The problem is confusing having a backup with being able to recover.

A backup that cannot be restored within the time the business needs is not a continuity plan; it is a theoretical insurance policy.

The serious discussion does not start with technology. It starts with an uncomfortable question: how long can the operation stay down before sales, invoicing, customer support or production are affected? Once you answer that, the conversation changes. The goal is no longer “store data”, but design a recovery system that can handle operational reality.

The false comfort of “we already have backups”

In many SMEs, backup is treated like an administrative task. A policy is enabled, a copy is stored in the cloud, and the issue is considered solved. The failure appears when a real restore is needed.

Typical symptoms are easy to spot:

• nobody has tested a full restore in months or years;
• the backup lives in the same account, tenant or domain as production;
• no one knows which data is critical and which can wait;
• recovery depends on one person who “knows how to do it”;
• the restore time does not match the maximum downtime the business can tolerate.

The core mistake is treating backup as storage. Operationally, backup is a response capability. If you cannot estimate how long it will take to come back online, how much data you can lose, and which systems must be restored first, then you do not have a resilience design. You have a copy policy.

What real recovery means

Recovery is not simply seeing files again. It is restoring the right service, with enough integrity, in the correct order. In business terms, that usually means three levels:

1. Technical recovery: the data exists and can be mounted again.
2. Functional recovery: critical processes run again without major errors.
3. Operational recovery: the company can invoice, ship orders, answer support or keep producing.

A realistic example: a mid-sized distributor loses access to its ERP and part of its document repository because of storage corruption. The company has nightly backups. On paper, it is covered. But when it tests recovery, it discovers that restoring the ERP into the same compromised environment brings back the same broken permissions, document attachments no longer match orders, and operations do not know which process to restart first. The problem was not the backup. It was the lack of a recovery runbook and a clear service priority.

The right questions are much more concrete:

• Which systems are restored first, and why?
• What is the RTO for each critical system?
• What RPO is acceptable for orders, accounting, inventory or support?
• Is recovery done in an isolated environment or inside the same perimeter?
• Who validates that recovered data is consistent?

The uncomfortable mistake: backing up without isolating risk

Here is the decision many organizations avoid: a backup too tightly connected to production infrastructure can also be attacked, encrypted or deleted. In ransomware incidents, it is not enough that the copy exists; it must be isolated, immutable, or at least protected by access controls very different from production.

That forces an uncomfortable trade-off: the safest recovery setup is not always the easiest to manage. It may require separate accounts, immutable storage policies, retention rules and permissions that do not mirror day-to-day operations.

There is also a cost trade-off. More retention, more copies and more tests require money and time. The question is not whether they cost something, but how much a shutdown costs. If the answer is “a lot”, the cheap backup becomes expensive very quickly.

How to tell whether your strategy is serious

You do not need a perfect lab to improve. You do need measurement. These criteria usually separate a decorative strategy from a useful one:

• Regular restore tests: not just checking that backups run, but restoring real systems or representative subsets.
• Repository isolation: separate credentials, accounts or administrative domains.
• Immutability or deletion protection: especially if ransomware is a relevant threat.
• Impact-based prioritization: not all systems deserve the same recovery target.
• Simple operational documentation: a clear runbook with steps, owners and validation.
• Recovery telemetry: knowing how long each restore takes and where it fails.

If a company cannot answer with numbers “how long until we are operational again?” and “how much data can we lose without breaking the business?”, then the plan is not mature.

A practical investment rule

Backup and continuity should be treated like a risk portfolio. You do not protect accounting the same way you protect marketing archives. You do not restore a historical file the same way you restore an order ERP. And you do not justify the same protection level for everything.

The useful move is to classify systems by criticality and define a realistic objective for each one. Sometimes that means reinforcing only three things: the most critical repository, the restoration procedure and the periodic test. Other times it means redesigning the backup strategy entirely.

The real shift is to stop asking “do we have a backup?” and start asking “what happens if we need to use it tomorrow at 9:00 a.m.?”

At Codefuente, we usually address these decisions together with operational continuity, cloud and security, because the answer is rarely only technical: it is also about process, dependencies and real priorities.