The sentence “we have backups” creates an immediate sense of security.
Data is copied every night.
The business system creates its own backup.
The server retains several versions.
Documents live in the cloud.
A dashboard shows the latest jobs in green.
It feels sufficient.
But the question that really matters is not:
“Do we have a copy?”
It is:
“If this system disappeared tomorrow morning, how long would it take us to work again?”
Those are two different problems.
Backup is about creating and preserving a copy.
Recovery is about using that copy to reconstruct a real service.
Business continuity goes further still: how quickly the organization can resume the activities that matter.
That is why a backup that has never been restored is, at least partly, still an assumption.
A green job proves that the backup ran
A backup system can tell us many useful things.
That the process completed.
That a certain amount of data was transferred.
That specific versions exist in the repository.
That no errors were detected during the copy operation.
All of this matters.
But it does not completely answer the next question:
Can that data be restored correctly when it is needed?
A restore can fail for reasons that were invisible during backup.
A configuration may be missing.
A dependency may be missing.
The backup may contain the data but not everything needed to use it.
The permissions required for recovery may no longer be available.
Documentation written years ago may no longer match the current environment.
An application may depend on other systems that must be restored in a specific order.
The copy can be perfect.
And the service can still fail to come back.
That is why restore testing is part of the strategy rather than an optional check.
Restoring a file is not the same as restoring a service
For some incidents, recovering a single document is enough.
For others, it is not.
Consider a business management system.
The database may exist in the backup.
But returning to operation may also require:
- the application;
- configuration;
- connected services;
- authentication;
- certificates;
- integrations;
- network configuration;
- compatible versions;
- operational documentation.
The same principle applies to a website, email system, file server or internal application.
Data is essential, but it is often only one component of the service.
A recovery strategy should therefore start not only from what is being copied, but from what must actually be reconstructed.
The better question becomes:
“What does this service need in order to genuinely work?”
That is far more useful than:
“Which folders are we backing up?”
How much can we afford to lose?
One of the fundamental decisions concerns time.
If the last usable backup was created yesterday evening and the incident happens this afternoon, some of today’s work may be lost.
How much is acceptable?
A day?
An hour?
Five minutes?
It depends entirely on the process.
This concept is normally expressed through the Recovery Point Objective — RPO.
In practical terms:
How far back in time can we afford to go?
A rarely updated archive can tolerate a different recovery point from a system that records orders or transactions continuously.
There is therefore no universally correct backup frequency.
There is a frequency that matches the amount of data the organization is prepared to lose.
How long can we remain offline?
The other variable is how long recovery takes.
A backup may be perfectly valid and still require many hours to restore.
Or days.
The result depends on data volume, architecture, available bandwidth, infrastructure reconstruction and the complexity of the procedure.
The Recovery Time Objective — RTO describes the period within which the system should return to an acceptable operational state.
Again, there is no universal number.
A secondary service may tolerate a long interruption.
A system that stops production, orders, customer support or access to essential information may not.
The problem is that RTO and RPO written in a document do not prove that they can be achieved.
The best way to find out is to test them.
Restore testing turns an assumption into a measurement
A restore test answers practical questions.
Is the copy readable?
Is it complete?
Which recovery point can we actually use?
Who has the required access?
How long does it take to recover the data?
How long does it take to rebuild the service?
Which steps depend on undocumented knowledge?
Which systems must be recovered before others?
Testing therefore produces something that backup alone cannot:
operational evidence.
After a recovery exercise we no longer need to say:
“We should be able to recover in a few hours.”
We can say:
“In the last test, recovery took this long and these were the problems we encountered.”
That difference matters.
The correct diagram is not backup → safety
- Criticality
- Backup
- Test
- Measurement
- Correction
The sequence should be:
Criticality → Backup → Test → Measurement → Correction
After correction, the cycle can begin again.
Continuity is not something achieved permanently.
The environment changes.
Applications change.
Data changes.
People change.
Credentials and permissions change.
Volumes change.
Integrations change.
A procedure tested two years ago may no longer describe the environment that exists today.
Not every system has the same priority
During an incident, attempting to recover everything at once may be less effective than establishing a sequence in advance.
Which system actually stops the business?
Which service is required before other services can work?
Which information must be available immediately?
Which components can wait?
Business continuity requires prioritization.
An organization may have dozens of systems, while only a small number are truly critical during the first hours of an incident.
Knowing which ones matter allows backup, recovery and investment decisions to be proportional to the real business impact.
Infrastructure does not become more resilient because everything is labelled critical.
It becomes more resilient when we know what must return first.
Ransomware has changed how backups must be designed
For a long time, backup was primarily viewed as protection against hardware failure, human error or accidental deletion.
Today another scenario must be considered:
an attacker who compromises the infrastructure may also attempt to compromise the backup environment.
If the backup is always accessible through the same environment, administrative accounts and credentials, an attack may be able to affect both production and the mechanism intended to recover it.
That is why concepts such as these matter:
- isolated copies;
- offline storage where appropriate;
- immutability;
- privilege separation;
- multiple versions;
- protections against deletion or modification.
But even a perfectly isolated copy must still be recoverable.
Resilience comes from combining both:
protecting the recovery point and knowing how to use it.
Being in the cloud does not remove the problem
Cloud platforms have dramatically improved availability and the ability to build resilient systems.
But “it is in the cloud” is not a recovery strategy.
We still need to understand:
- what the provider protects automatically;
- what remains the organization’s responsibility;
- which versions are retained;
- for how long;
- what happens after deletion;
- how a complete recovery is performed;
- which dependencies must be rebuilt.
High availability, replication and backup solve different problems.
Replication may keep a service available during a failure.
But it may also propagate an unwanted change or deletion quickly.
A backup preserves an earlier state.
But it does not automatically guarantee an acceptable recovery time.
Reliability and continuity therefore require several layers.
Restore testing also tests the people
Recovery procedures do not execute themselves.
Someone has to recognize the incident.
Someone must decide which recovery point should be used.
Someone must have access.
Someone must know where documentation and tools are located.
Someone must verify that the restored service actually works.
If all of this depends on a single individual, another vulnerability exists.
A recovery test therefore also tells us whether operational knowledge is distributed.
Does documentation exist?
Can it be accessed during an incident?
Is it current?
Can another person follow it?
Are responsibilities clear?
The technology may be redundant while operational knowledge remains a single point of failure.
The worst time to learn how to recover is during the incident
When an important system is unavailable, time changes value.
Every minute matters more.
People work under pressure.
Decisions are made faster.
Mistakes become more expensive.
That is not the ideal moment to discover:
- where a backup is stored;
- which copy is the correct one;
- which credentials are required;
- which machine must be rebuilt first;
- how long recovery takes;
- whether the procedure still works.
A controlled test moves those discoveries before the real incident.
Every problem found during an exercise is one less problem to discover during a crisis.
A backup strategy should produce answers, not only copies
Ultimately, an organization should be able to answer a small set of important questions.
Which systems are genuinely critical?
What is the latest recoverable point?
How much data loss is acceptable?
How long does recovery actually take?
Where are the copies stored?
Are they protected from compromise of the primary environment?
Have we ever performed a complete restore?
When was the last test?
Who knows how to perform the procedure?
If these answers do not exist, the backup itself may not necessarily be wrong.
The problem is that we are still managing copies, not a genuine recovery capability.
Backup protects a copy. Recovery protects operations
The distinction may sound semantic.
It is not.
Backup is a technical component.
Recovery capability is a property of the system.
Business continuity is a property of the organization.
They are three different levels.
And they need to be designed together.
The question therefore should not be:
“Do we have backups?”
It should be:
“If we lose this system now, do we know exactly how and how quickly we can return to operation?”
If the answer comes from a real test, we have a capability.
If it comes only from an assumption, there is still work to do.