La Llamada Que Recibí un Domingo por la Noche

Un cliente me llamó un domingo por la noche, en pánico. Su servidor de archivos había sido atacado por ransomware el viernes por la tarde, y nadie lo notó hasta que un empleado abrió una planilla compartida el lunes por la mañana y se encontró con una nota de rescate en su lugar. Tres días de silencio mientras el cifrado se propagaba por cada unidad de red mapeada.

La buena noticia: tenían copias de seguridad. La mala noticia: el disco de backup era un dispositivo de almacenamiento en red ubicado en la misma subred que todo lo demás, así que se cifró junto con los archivos de producción. Su "plan de recuperación ante desastres" resultó ser un único disco externo que, en la práctica, era solo otra carpeta más dentro de la misma red.

Se recuperaron — eventualmente — a partir de una copia de seis semanas de antigüedad guardada en la vieja laptop de un empleado que ya no trabajaba ahí. Les costó cuatro días de operación, un cliente que nunca recuperaron y unos $40,000 entre consultoría de recuperación y horas facturables perdidas. Nada de eso era necesario. Un plan construido sobre separación básica y pruebas periódicas los habría devuelto en línea en horas, no en días.

La mayoría de los dueños de negocio asumen que "tenemos backups" es lo mismo que "tenemos un plan de recuperación ante desastres". No lo es. Un backup es un archivo. Un plan de recuperación ante desastres es el marco de decisiones para lo que ocurre cuando ese archivo es lo único que queda.

Qué Cubre Realmente un Plan de Recuperación ante Desastres

Un plan de recuperación ante desastres no es un documento de IT que vive en una carpeta que nadie abre. Es un plan de continuidad del negocio que responde cuatro preguntas antes de la crisis, no durante ella:

  • ¿Qué sistemas importan más, y en qué orden se restauran? No todo tiene la misma criticidad. Su sistema contable y su aplicación de cara al cliente probablemente no tienen la misma prioridad de recuperación.
  • ¿Cuánto tiempo de inactividad podemos tolerar realmente por sistema? Este es su Objetivo de Tiempo de Recuperación (RTO) — el tiempo máximo aceptable antes de que un sistema vuelva a estar en línea.
  • ¿Cuántos datos podemos permitirnos perder? Este es su Objetivo de Punto de Recuperación (RPO) — la brecha máxima aceptable entre su último backup válido y el momento de la falla.
  • ¿Quién hace qué, y quién habla con los clientes? Un plan sin responsables asignados es una lista de deseos, no un plan.

Recomiendo tratar esto con la misma seriedad que una auditoría financiera. Rara vez recibe ese trato, y esa brecha es exactamente donde ocurre el daño.

RTO y RPO: Los Dos Números Que Realmente Determinan el Costo

Toda conversación sobre recuperación ante desastres termina reduciéndose a estas dos métricas, y los clientes toman mejores decisiones cuando entienden que el trade-off no es abstracto — es una curva de costo directa.

Un RTO y RPO casi nulos, donde los sistemas conmutan automáticamente con pérdida de datos mínima, son alcanzables. También requieren replicación en tiempo real, infraestructura redundante y un gasto continuo que la mayoría de las pymes no necesitan para todos sus sistemas. En mi experiencia, lo correcto es segmentar por niveles:

  • Nivel 1 — Sistemas críticos para el ingreso (procesamiento de pagos, bases de datos transaccionales centrales, aplicaciones de cara al cliente). RTO objetivo de minutos a pocas horas; RPO medido en minutos.
  • Nivel 2 — Sistemas operativos (herramientas internas, CRM, gestión de proyectos). RTO objetivo del mismo día; RPO de pocas horas.
  • Nivel 3 — Todo lo demás (archivos históricos, reportes antiguos). RTO objetivo de días; un RPO de 24 horas suele ser suficiente.

Este ejercicio, hecho con honestidad junto a las partes interesadas del negocio y no solo por IT, resuelve la mayoría de los desacuerdos que veo entre finanzas y operaciones sobre cuánta resiliencia es "suficiente" — y mantiene la conversación anclada en la necesidad real del negocio, no en lo que vende un proveedor.

La Estrategia de Backup Que Realmente Sobrevive a un Ataque

La historia del casi-desastre que conté arriba es lo suficientemente común como para considerarla la norma, no la excepción. El ransomware actual apunta específicamente a los sistemas de backup — la investigación de Sophos encontró que los atacantes intentaron comprometer los backups en la gran mayoría de los incidentes, y lo lograron más de la mitad de las veces. Si su backup vive en la misma red que sus datos de producción, no tiene un plan de recuperación ante desastres. Tiene un radio de explosión ligeramente más grande.

Recomiendo la versión extendida de la clásica regla 3-2-1:

  • 3 copias de sus datos — el original más dos backups.
  • 2 tipos de medios distintos — por ejemplo, almacenamiento en la nube y un NAS local, no dos copias en el mismo disco.
  • 1 copia fuera del sitio, física o lógicamente aislada de su red principal.
  • 1 copia inmutable o con air-gap — almacenamiento de escritura única o medios offline que el ransomware no pueda alcanzar ni alterar, incluso con credenciales válidas.
  • 0 errores — verificados mediante pruebas de restauración regulares, no solo registros de que el backup "se completó".

Esto se conecta con la conversación sobre resiliencia que tengo con clientes que avanzan hacia la migración a la nube — los proveedores de nube replican la infraestructura, pero no hacen backup automático de los datos de su aplicación a menos que usted lo configure. Leer "SLA de disponibilidad del 99.9%" en un contrato y asumir que eso lo cubre contra ransomware o borrado accidental es uno de los malentendidos más comunes y costosos que encuentro. Un SLA del 99.9% significa que la plataforma está disponible; no dice nada sobre si sus datos son recuperables.

Pruebe el Plan Antes de Necesitarlo

Un plan de recuperación ante desastres que nunca se probó es una hipótesis. He visto organizaciones descubrir, durante una interrupción real, que los archivos de backup estaban corruptos, que nadie recordaba las credenciales del entorno de recuperación, o que el proceso "documentado" tenía tres versiones de antigüedad.

Recomiendo una cadencia simple y recurrente:

  • Pruebas de restauración trimestrales — restaurar de verdad un sistema desde el backup hacia un entorno aislado y confirmar que funciona. No es un ítem de checklist; es una restauración real.
  • Simulacros anuales de mesa (tabletop) — guiar al equipo de liderazgo a través de un incidente simulado (ransomware, caída de la nube, base de datos borrada) y hacer que discutan las decisiones en tiempo real.
  • Revisiones post-incidente — después de cualquier interrupción real, por menor que sea, documentar qué funcionó y qué no, y actualizar el plan.

Esto es innegociable para clientes en fintech y otros sectores regulados. La disciplina descrita aquí se conecta con lo que cubro en seguridad del trabajo remoto en el sector financiero — auditores y reguladores esperan cada vez más ver evidencia de planes de continuidad probados, no solo políticas escritas.

Construyendo el Runbook de Respuesta a Incidentes

La recuperación técnica es solo la mitad del plan. La otra mitad es la comunicación, y es la mitad que la mayoría de las empresas se saltan. Cuando un sistema cae, alguien necesita saber, en cuestión de minutos, quién declara el incidente, quién se comunica con los clientes afectados y quién tiene la autoridad para tomar decisiones costosas (como pagar por soporte acelerado de un proveedor de nube) sin esperar a que se reúna un comité.

Un runbook funcional incluye:

  • Un comandante de incidente designado para cada turno o rotación de guardia.
  • Plantillas de comunicación con el cliente redactadas de antemano, para no estar escribiendo una actualización de estado mientras también intenta resolver el problema real.
  • Un árbol de contactos que no dependa completamente de un sistema que podría estar caído (no guarde su lista de contactos de emergencia únicamente en el sistema de correo que acaba de ser cifrado).
  • Una ruta de escalamiento clara hacia proveedores, plataformas en la nube y, si corresponde, aseguradoras de ciberseguridad.

Reflexión Final

Planificar la recuperación ante desastres no es un trabajo glamoroso, y entiendo por qué sigue quedando relegado frente a nuevas funcionalidades e iniciativas de crecimiento. Pero me he sentado frente a demasiados dueños de negocio durante su peor semana como para tratar esto como un consejo opcional. El costo de un plan real es una fracción del costo de no tenerlo, y las empresas que sobreviven limpiamente a un incidente serio son, sin excepción, las que ya habían respondido estas preguntas antes de necesitarlo.

Si no está seguro de que su organización pueda recuperarse de un ataque de ransomware, una base de datos de producción borrada o una caída de varios días en la nube antes de la próxima semana, eso vale una conversación ahora, no después de los hechos.

Hablemos de su situación.