Backup no es Disaster Recovery: qué debería revisar una empresa antes de confiar en su continuidad cloud

“Tengo backup” no responde necesariamente a la pregunta:

¿cuánto tardaría mi empresa en volver a operar después de una interrupción grave?

Un respaldo de datos es una parte importante de la protección tecnológica. Pero Disaster Recovery aborda un problema más amplio.

¿Qué resuelve un backup?

Un backup crea una copia de información que puede utilizarse para recuperar datos.

Puede proteger frente a escenarios como:

• eliminación accidental;
• corrupción de información;
• fallas;
• pérdida de archivos;
• determinados incidentes de seguridad.

Pero disponer de la copia no significa que todo el servicio pueda volver a funcionar inmediatamente. Todavía puede ser necesario restaurar infraestructura, aplicaciones, configuraciones, conectividad y dependencias.

¿Qué resuelve Disaster Recovery?

Disaster Recovery se concentra en recuperar sistemas y operación después de una interrupción significativa.

Las estrategias pueden involucrar:

• backups;
• replicación;
• infraestructura secundaria;
• failover;
• automatización;
• procedimientos de recuperación;
• pruebas.

Thumala (2022) resume varios de estos componentes al diferenciar respaldo, replicación, mecanismos de failover y automatización dentro de una estrategia de Disaster Recovery.

Un ejemplo

Supongamos que una empresa guarda correctamente una copia diaria de su base de datos. Ocurre una falla grave. La copia existe.

Pero para volver a operar también necesita:

1. disponer de infraestructura;
2. instalar o habilitar los sistemas necesarios;
3. recuperar la información;
4. verificar integridad;
5. restablecer conectividad;
6. validar la aplicación;
7. permitir nuevamente el acceso de los usuarios.

El backup resolvió una parte del problema. No todo el problema.

Qué debería revisar una empresa

¿Qué estamos respaldando?

No todos los datos tienen la misma importancia. Conviene identificar información y cargas críticas.

¿Dónde están las copias?

Una copia almacenada en el mismo entorno puede estar expuesta al mismo incidente que el sistema principal.

¿Con qué frecuencia se generan?

La frecuencia determina cuánto historial podría perderse entre una copia y otra.

¿Cuánto tarda la restauración?

Una copia útil debe poder recuperarse dentro del tiempo que la operación puede tolerar.

¿Se ha probado?

Un backup que nunca fue restaurado sigue siendo una promesa. Las pruebas permiten comprobar si los procedimientos, datos y responsables funcionan cuando se necesitan.

La continuidad se diseña desde el negocio

Alhazmi y Malaiya (2013) plantean que una estrategia de Disaster Recovery debe considerar los objetivos de recuperación, el costo, las necesidades de datos y el impacto potencial de los eventos.

Esto implica que no existe una arquitectura idéntica para todas las empresas. Una aplicación interna no crítica puede tolerar una recuperación más lenta. Un proceso que soporta ventas, producción o transacciones críticas probablemente no.

La pregunta correcta

No preguntes únicamente:

¿tenemos backup?

Pregunta:

si mañana perdemos este servicio, ¿cómo volveremos a operar y cuánto tardaremos?

Ahí comienza realmente una conversación sobre continuidad.

Referencias

Alhazmi, O. H., & Malaiya, Y. K. (2013). Evaluating disaster recovery plans using the cloud. Proceedings of the Annual Reliability and Maintainability Symposium.

Thumala, S. R. (2022). Importance of Business Continuity and Disaster Recovery (BCDR) methodologies for organizations: A comparison study between AWS and Azure. International Journal of Science and Research, 11(12).

Altamira Technology. (2026). Cloud Service. https://altamira.pe/cloud-service/