Muchas empresas creen estar protegidas porque, cada noche, un sistema ejecuta una copia de seguridad de sus archivos. El reporte indica que el proceso terminó correctamente, los datos están almacenados en algún servidor o servicio en la nube y, aparentemente, todo está bajo control.
Hasta que ocurre un incidente. Un ataque de ransomware, una falla de hardware, un error humano o una actualización que sale mal puede poner a una organización frente a una pregunta mucho más importante que “¿tenemos backup?”:
¿Podemos recuperar realmente nuestra operación y cuánto tiempo nos tomaría hacerlo?
Hay una diferencia fundamental que todavía se subestima en muchas empresas: hacer copias de seguridad no es lo mismo que tener una capacidad real de recuperación.
Un backup puede existir y, aun así, no ser suficiente cuando realmente se necesita. Puede estar incompleto, corrupto, desactualizado o requerir días para restaurarse. Por eso, una estrategia seria de continuidad tecnológica no debería limitarse a guardar información. También debe demostrar que la organización puede volver a funcionar después de una interrupción.
Tener un backup no garantiza que puedas recuperar tu empresa
Un backup es, en términos simples, una copia de datos, sistemas o configuraciones que puede utilizarse para restaurar información perdida o dañada. La recuperación, en cambio, implica un escenario mucho más amplio.
Supongamos que una empresa cuenta con una copia de seguridad de su servidor principal. Después de una falla crítica, descubre que puede recuperar los archivos. Sin embargo, nadie tiene documentado cómo reconstruir el servidor, cuánto tiempo tomará instalar las aplicaciones necesarias o en qué orden deben restaurarse las bases de datos y los servicios. Los archivos están ahí, pero la empresa sigue sin poder operar.
Ese es uno de los errores más frecuentes en la gestión de infraestructura: confundir la existencia de una copia con la capacidad real de recuperación.
También habría que preguntarse:
- ¿La copia contiene toda la información crítica?
- ¿Se puede restaurar sin errores?
- ¿Cuánto tarda el proceso?
- ¿Qué sistemas deben recuperarse primero?
- ¿Dónde se restaurarán los servicios?
- ¿Quién es responsable de ejecutar el procedimiento?
- ¿Qué ocurre si el mismo incidente afecta tanto a los servidores como a los backups?
Si estas preguntas no tienen respuestas claras, probablemente existe una estrategia de backup, pero no necesariamente una estrategia de recuperación.
Cuando el backup existe, pero la recuperación falla
Uno de los ejemplos más conocidos sobre la importancia de una estrategia de recuperación ocurrió en 2017 con Maersk, una de las compañías de transporte marítimo más grandes del mundo.
Ese año, la empresa fue afectada por el ataque de malware conocido como NotPetya, que se propagó rápidamente y afectó miles de sistemas. La interrupción obligó a Maersk a reconstruir buena parte de su infraestructura tecnológica.
El incidente dejó una lección importante: cuando una organización depende profundamente de sus sistemas digitales, recuperar la operación no consiste simplemente en restaurar unos cuantos archivos.
Hay servidores, aplicaciones, credenciales, configuraciones, bases de datos, conexiones entre sistemas y múltiples dependencias que deben volver a funcionar.
El proceso de recuperación de Maersk se convirtió en un caso ampliamente analizado dentro de la industria tecnológica y de ciberseguridad. La compañía tuvo que reconstruir una gran cantidad de sistemas en un período muy corto para poder recuperar sus operaciones globales.
La lección para cualquier empresa, incluso una mucho más pequeña, es clara: si la infraestructura desapareciera mañana, ¿sabemos exactamente cómo volver a construirla?
El problema aparece cuando el backup nunca se ha probado
Uno de los mayores riesgos de las copias de seguridad es asumir que funcionan simplemente porque el software indica que el proceso terminó correctamente.
Un mensaje de “backup exitoso” confirma que el proceso de copia aparentemente terminó. No garantiza que los datos puedan restaurarse correctamente.
Un backup exitoso puede ser un backup inútil
Hay diferentes situaciones en las que una copia puede existir, pero fallar cuando llega el momento de utilizarla.
Por ejemplo:
- La copia está incompleta.
- Algunos archivos críticos nunca fueron incluidos.
- La base de datos fue respaldada, pero no puede restaurarse correctamente.
- Las copias están corruptas.
- Las credenciales necesarias para acceder al backup ya no funcionan.
- La infraestructura donde debía realizarse la restauración ya no está disponible.
- El proceso tarda varios días, cuando la empresa solo puede soportar unas pocas horas de interrupción.
Por eso, probar la restauración es tan importante como ejecutar el backup.
Este es precisamente el enfoque que han adoptado grandes organizaciones con infraestructuras críticas. Los entornos empresariales más maduros no se limitan a verificar que una copia se haya generado; realizan pruebas periódicas de recuperación y simulaciones de incidentes. Si nunca se ha restaurado un backup, la empresa realmente no sabe si podrá recuperarse.
Backup, recuperación y continuidad: tres conceptos diferentes
Para diseñar una estrategia tecnológica más sólida, es importante separar tres conceptos que con frecuencia se mezclan.
Backup: proteger la información
El backup se enfoca principalmente en conservar una copia de los datos.
Puede incluir documentos, bases de datos, máquinas virtuales, configuraciones, aplicaciones o incluso sistemas completos. Su objetivo es evitar que la pérdida de la infraestructura principal signifique la desaparición definitiva de la información.
Recuperación: volver a poner los sistemas en funcionamiento
La recuperación responde a otra pregunta:
¿Cómo volvemos a operar después de una falla?
Aquí entran en juego los procedimientos de restauración, el orden de recuperación de los sistemas, la infraestructura disponible y el tiempo necesario para volver a prestar servicios. No todos los sistemas tienen la misma prioridad.
Una empresa puede soportar temporalmente la caída de un repositorio interno de documentos, pero quizás no puede facturar, procesar pagos o atender pedidos si su sistema principal deja de funcionar. Por eso, recuperar todo al mismo tiempo no siempre es la mejor estrategia.
Continuidad del negocio: mantener la operación
La continuidad va un paso más allá. No solo se pregunta cómo recuperar la infraestructura, sino cómo mantener funcionando la empresa durante y después del incidente.
Esto puede incluir procedimientos alternativos, infraestructura redundante, sistemas secundarios, trabajo remoto, protocolos de comunicación y planes para seguir atendiendo a los clientes mientras se completa la recuperación.
El caso que demostró que un ataque también puede alcanzar los backups
Los ataques de ransomware han cambiado radicalmente la forma en que las empresas diseñan sus estrategias de respaldo.
Durante años, muchas organizaciones mantuvieron sus copias de seguridad conectadas a la misma infraestructura que protegían. El problema es que, si un atacante consigue acceso administrativo, también puede intentar cifrar, eliminar o inutilizar esas copias.
Eso ocurrió en múltiples incidentes de ransomware, incluido el ataque contra Colonial Pipeline en 2021. Aunque el caso tuvo características particulares y la recuperación involucró múltiples mecanismos, el incidente demostró el enorme impacto que puede producir la interrupción de sistemas críticos.
Colonial Pipeline tuvo que detener temporalmente sus operaciones después del ataque, generando consecuencias que trascendieron a la propia empresa y afectaron el suministro de combustible en diferentes zonas de Estados Unidos. Para las empresas, la lección no es que todas deban construir una infraestructura del tamaño de Colonial Pipeline.
La lección es otra: hay sistemas cuya interrupción puede tener un impacto mucho mayor del que la organización imagina. Y si un atacante puede acceder al entorno de producción, también existe la posibilidad de que intente alcanzar los mecanismos de recuperación.
Por eso, las estrategias modernas incorporan conceptos como copias aisladas, almacenamiento inmutable y separación de credenciales entre los sistemas de producción y los sistemas de backup.
RTO y RPO: dos preguntas que definen si tu estrategia es suficiente
Una estrategia de recuperación no puede diseñarse únicamente preguntando cuánto espacio de almacenamiento se necesita. También es necesario definir cuánto tiempo puede permanecer detenida la operación y cuánta información puede perderse.
RTO: ¿cuánto tiempo tienes para volver a operar?
El Recovery Time Objective o RTO representa el tiempo máximo aceptable que puede permanecer interrumpido un sistema. Por ejemplo, si una aplicación tiene un RTO de cuatro horas, la estrategia tecnológica debería permitir que vuelva a funcionar dentro de ese período.
Esto tiene una consecuencia importante: No sirve de mucho tener un backup perfecto si restaurarlo tarda tres días. Una empresa debe medir el tiempo real que toma recuperar sus sistemas y compararlo con el impacto que tendría permanecer fuera de operación.
RPO: ¿cuánta información puedes permitirte perder?
El Recovery Point Objective o RPO define cuánta información puede perderse entre el último punto de recuperación y el momento en que ocurre el incidente.
Imaginemos una empresa que realiza una copia completa cada noche. Si el servidor falla a las cinco de la tarde, podría perder toda la información generada desde el último backup. Para algunas organizaciones esto puede ser aceptable. Para otras, especialmente aquellas que procesan transacciones constantemente, puede representar un problema grave.
Por eso, la frecuencia de las copias no debería definirse arbitrariamente. Debe estar relacionada con el impacto real que tendría perder determinada cantidad de información.
La regla 3-2-1 sigue siendo relevante, pero ya no siempre es suficiente
Uno de los principios más conocidos en materia de backup es la regla 3-2-1:
- Mantener al menos tres copias de la información.
- Utilizar dos medios o sistemas de almacenamiento diferentes.
- Conservar al menos una copia fuera de la infraestructura principal.
La lógica es evitar que un único incidente destruya todas las copias. Sin embargo, las amenazas actuales han llevado a muchas organizaciones a complementar este enfoque con medidas adicionales.
Por ejemplo:
Copias inmutables
Una copia inmutable está diseñada para no poder modificarse o eliminarse durante un período determinado. Esto puede representar una capa adicional de protección frente al ransomware o frente a errores administrativos.
Copias aisladas
También es importante evitar que todas las copias estén permanentemente expuestas dentro de la misma red. Si producción y backups comparten las mismas credenciales, permisos y superficie de ataque, un incidente puede comprometer ambos entornos.
Pruebas periódicas de restauración
Una copia que nunca se ha probado sigue siendo una incógnita. Las empresas deberían establecer procedimientos para restaurar periódicamente información y sistemas críticos en entornos controlados.
Cómo saber si realmente puedes recuperar tu operación
Una forma práctica de evaluar la capacidad de recuperación es imaginar un escenario sencillo. Mañana, al comenzar la jornada, el servidor principal no funciona. No hay acceso a los archivos. Las aplicaciones críticas están caídas. Las máquinas virtuales no responden. Ahora intenta responder estas preguntas.
¿Sabes qué debes recuperar primero?
No todos los sistemas son igual de importantes. Es necesario identificar cuáles son críticos para mantener funcionando la operación.
Por ejemplo:
- Sistemas de facturación.
- Bases de datos.
- Plataformas de ventas o atención al cliente.
- Correo y comunicaciones.
- Servidores de archivos.
- Sistemas secundarios.
El orden dependerá de cada empresa, pero debería estar definido antes de que ocurra un incidente.
¿Existe un procedimiento documentado?
La recuperación no debería depender de que una persona específica “sepa cómo hacerlo”. Los procedimientos críticos necesitan documentación: responsables, configuraciones, dependencias, accesos y pasos de recuperación. Si la única persona que conoce el proceso no está disponible durante una crisis, la empresa puede perder horas intentando reconstruir el procedimiento.
¿Has medido cuánto tarda una restauración?
Este punto es fundamental. No basta con saber que una máquina virtual puede restaurarse. Es necesario conocer cuánto tarda el proceso completo, incluyendo la descarga, transferencia, restauración, configuración y validación. En una infraestructura pequeña, recuperar varios terabytes de información puede tomar mucho más tiempo del esperado.
El ancho de banda, el rendimiento del almacenamiento y la capacidad disponible en la infraestructura de destino pueden convertirse en cuellos de botella. Por eso, el tiempo de recuperación debe probarse y medirse, no simplemente estimarse.
Los planes de recuperación también envejecen
Una estrategia de recuperación puede haber funcionado perfectamente hace dos años y ser insuficiente hoy. La infraestructura cambia constantemente. Se instalan nuevas aplicaciones, se crean bases de datos, se migran servicios a la nube, cambian proveedores y aparecen nuevas dependencias entre sistemas. Por eso, el plan debe revisarse periódicamente.
Cada cambio importante debería generar nuevas preguntas:
- ¿Este nuevo sistema está incluido en el backup?
- ¿Cómo se recuperaría?
- ¿Qué dependencias tiene?
- ¿Cuál es su prioridad dentro de la operación?
- ¿Se ha probado su restauración?
El objetivo es evitar descubrir, en medio de una crisis, que un sistema crítico nunca fue incluido dentro de la estrategia.
La verdadera pregunta no es si tienes backup
Los casos de empresas como Maersk o Colonial Pipeline demuestran que una interrupción tecnológica puede convertirse rápidamente en un problema operativo y financiero.
Por supuesto, una pequeña o mediana empresa no necesita replicar las complejas infraestructuras de una corporación multinacional. Pero sí puede aplicar la misma lógica fundamental: conocer qué necesita proteger, cuánto tiempo puede permanecer fuera de operación y cómo volverá a funcionar después de un incidente.
Tener copias de seguridad sigue siendo indispensable. Sin embargo, el backup debe entenderse como una parte de una estrategia más amplia. Una empresa realmente preparada no es la que simplemente acumula copias de sus datos. Es la que sabe qué hacer cuando ocurre una falla, quién debe hacerlo, en qué orden deben recuperarse los sistemas y cuánto tiempo tardará en volver a operar.
Porque mientras todo funciona, cualquier estrategia de recuperación parece suficiente. La verdadera prueba llega cuando algo falla. Y en ese momento, la diferencia entre tener un backup y tener una capacidad real de recuperación puede significar unas pocas horas de interrupción o varios días —o incluso semanas— con la operación detenida.
Por eso, quizá la pregunta más importante para cualquier empresa no sea: “¿Estamos haciendo backups?”
Sino: “Si perdiéramos nuestros sistemas hoy, ¿realmente sabríamos cómo volver a operar?”