On a Monday morning, the company shifts into incident mode: the ERP is down, ecommerce is still taking orders, and operations does not know whether to stop or continue. Everyone assumes “we have backups”. Nobody is sure how long recovery will take or which system must come back first.

Having copies is not the same as being able to resume operations.

That difference feels obvious until ransomware, data corruption or a cloud provider outage makes it urgent. Then the uncomfortable question appears: were we protecting data, or business continuity?

The real problem is not storing, it is restoring

Many backup architectures are designed to satisfy a checkbox: daily copies, 30-day retention, off-server storage. That lowers the risk of permanent loss, but it does not solve time to recovery.

Recovery fails for very specific reasons:

• No one has tested a full environment restore, only individual files.
• Dependencies are undocumented: database, queues, credentials, DNS, certificates, scheduled jobs.
• The data was copied, but not the configuration.
• The startup order is undefined.
• Nobody knows which data is critical to get revenue moving again.

If a business sells online, bills subscriptions or depends on customer service, the goal is not “recover everything someday”. The goal is to restore the systems that keep the business alive first.

What should be measured before buying another tool

Before choosing another product, answer these questions:

• What is the real acceptable RTO per system? Not the theoretical one, the one leadership will accept.
• What is the acceptable RPO for orders, accounting, CRM and documents?
• Which systems must be restored in sequence and which can wait?
• Which external dependencies would break recovery even if the backup is intact?
• Who validates that restored data is actually usable?

A good backup plan for an SME does not need to be sophisticated, but it must be explicit. It should define what is backed up, how often, where it is stored, how it is encrypted, who can delete copies and how restores are tested.

In practice, that usually means combining several layers:

• Immutable or deletion-resistant backup protection.
• A separate account, region or provider when the risk justifies it.
• Periodic full restore tests, not just partial ones.
• Versioning and retention aligned with legal and operational needs.
• A clear runbook for prioritized recovery.

The uncomfortable mistake: choosing the cheapest backup and calling it strategy

Here is the decision that makes people uncomfortable: many companies buy backup like a generic insurance policy. They compare cost per gigabyte and forget the real cost of being offline.

That usually leads to three mistakes:

1. Keeping too much for too long without knowing why.
2. Relying on a single protection layer.
3. Not budgeting for restore tests.

Testing is the least glamorous and most valuable part. It often reveals failures the vendor cannot see: permissions that prevent a database from starting, expired credentials, scripts tied to an old path, or integrations that do not reconnect after restore.

In some cases, the best decision is not to keep everything “always ready”, but to define what can be rebuilt from scratch and what needs fast recovery. Not every system deserves the same criticality.

Mini-case: when the backup existed, but the company still could not operate

A mid-sized company with ecommerce and in-house logistics had automated cloud backups and felt covered. The problem appeared during a real recovery test: the database came back, but the scheduled jobs, transport integration keys and several user permissions were not part of the plan.

Result: they could “see data”, but not process orders.

The fix was not more storage. It was continuity redesign with three concrete decisions: prioritize services, document dependencies and run quarterly recovery drills. Within two drills, they found failures that would have cost hours of billing and service time.

Signals your backup is not incident-ready

There are easy symptoms to spot:

• Nobody has performed a full restore in the last 90 days.
• The recovery plan lives in a document nobody opens.
• There is no priority order by business process.
• Backups depend on the same provider or credentials as production.
• The team assumes “if it ever happens, we will figure it out”.

If you see two or more of these, you do not just have technical debt. You have operational debt.

The conclusion is simple: a useful backup is not the one that stores the most, but the one that reduces time and uncertainty when operations must come back. If this is affecting ERP, ecommerce, cloud or DevOps in your business, at Codefuente we usually start with real continuity, not the tool.