“We have backups” is one of the phrases that brings the most peace of mind to a company, and one of the fastest to lose its strength when a disaster actually happens.
This isn't necessarily because the copy doesn't exist, but because preserving data and returning the entire operation to a working state are two different capabilities. Many organizations discover that difference at the worst possible moment: while systems are down and every minute counts.
Backup protects data. Disaster recovery protects the business's ability to keep operating.
Backup: keeping the information.
A backup is a copy of data stored on another medium or in another location. Its purpose is to allow information to be recovered if the original is deleted, corrupted or becomes unavailable.
It's essential, but it mainly answers one question: is our data safe? On its own, it doesn't determine how long the company will take to use it again, where it will be restored if the original infrastructure no longer works, or who will carry out each step of the recovery.
Disaster recovery: restoring the entire operation.
Disaster recovery, or DR , is the documented set of resources, owners and procedures that make it possible to restore systems after a cyberattack, a fire, a prolonged power failure, human error or a natural disaster.
A real plan must answer four questions precisely:
How fast?
The RTO sets the maximum time a system can remain down before causing an unacceptable impact on the business.
How much data can be lost?
The RPO defines the point in time to which data must be recovered and, therefore, the maximum tolerable loss.
Where is it restored?
The plan identifies the physical or cloud infrastructure where services will be brought up if the primary environment becomes unusable.
Who runs and tests the plan?
The plan defines owners, recovery order, dependencies, communications and periodic exercises to verify that it works.
NIST defines RTO as the maximum time a resource can remain unavailable before causing an unacceptable impact, and RPO as the point prior to the disruption to which data must be recovered. See NIST SP 800-34 Rev. 1 →
Why this confusion can be so costly.
Having a backup doesn't prove that systems will come back within the time the business needs. Real capability is only known when recovery is tested end to end and the results are compared with the established objectives.
The report gathered responses from 1,200 IT leaders and managers. The percentages above correspond to global results, not exclusively Latin American ones. See Veeam's official analysis →
The copy may do its job and preserve the information, while the operation stays down for hours or days due to lack of alternate infrastructure, undocumented dependencies or procedures that were never rehearsed.
How to know whether your company has a backup or a real recovery plan.
These questions help identify whether the organization only keeps copies or can really operate again after losing its primary infrastructure:
- Is the number of hours each critical system can remain down defined?
- Do you know the maximum amount of data that can be lost, and has a backup frequency been set according to that limit?
- Is there a physical or cloud environment where systems can be brought up if the original infrastructure stops working?
- Are there owners, documented instructions and a clear order for recovering applications and dependencies?
- Has full recovery been tested recently, and were the results recorded?
If most answers are “no” or “we're not sure,” the company probably has backups but doesn't yet have a proven continuity strategy.
How ECOMIL approaches it.
At ECOMIL we design disaster recovery solutions as part of our Cloud and Data Center services. The starting point is understanding the real criticality of each process and defining different RTOs and RPOs when the operation requires it.
Next, we define where and how applications, data and their dependencies will be restored if the primary environment fails. Finally, the plan is documented and tested periodically so it isn't executed for the first time in the middle of a real crisis.
- Criticality and dependency analysis.
- RTO and RPO definition per service.
- Design of the alternate recovery environment.
- Periodic testing, documentation and improvement.
Having a backup is necessary, but it doesn't mean being prepared for a disaster.
The difference between backup and disaster recovery is almost never noticed during a normal workday. It appears when the primary infrastructure becomes unavailable; that's why it must be reviewed, documented and tested before the incident, not after.