Continuidad del negocio: por qué el respaldo no basta

Hace unas semanas, un cliente me dijo con total tranquilidad: "Nosotros estamos cubiertos, hacemos respaldo todas las noches". Le hice una sola pregunta: "¿Cuándo fue la última vez que restauró ese respaldo y midió cuánto tardó en volver a operar?". El silencio que siguió fue más elocuente que cualquier informe. Después de un año marcado por WannaCry y por una oleada de ransomware que dejó a empresas enteras mirando una pantalla cifrada, sigo encontrando la misma confusión peligrosa: creer que tener copias equivale a poder recuperarse. No es lo mismo. Y la diferencia, cuando llega el incidente, se mide en dinero, reputación y, a veces, en la supervivencia del negocio.

En corto: un respaldo solo guarda datos; la continuidad del negocio garantiza que usted pueda volver a operar dentro de un tiempo y con una pérdida de información aceptables. Sin objetivos de recuperación definidos (RTO y RPO) y sin pruebas reales, un backup es una promesa que nadie ha verificado, y las promesas no verificadas tienden a fallar justo cuando más las necesita.

¿Por qué el respaldo, por sí solo, no basta?

El respaldo responde a una pregunta: "¿Tengo una copia de mis datos?". La continuidad responde a otra mucho más exigente: "¿Cuánto tiempo me toma volver a trabajar y cuánta información estoy dispuesto a perder?". Son preguntas distintas y la segunda es la que define si su empresa sobrevive a un incidente grave.

En mi experiencia, los respaldos fallan en el peor momento por razones muy concretas:

• Nunca se probaron. El archivo existe, pero al restaurarlo está corrupto, incompleto o falta una dependencia crítica.
• Estaban en el mismo lugar. Una copia en el mismo servidor o la misma red que el sistema original se cifra o se daña junto con él. El ransomware busca precisamente eso.
• Tardan demasiado en restaurarse. Recuperar varios terabytes puede llevar días; mientras tanto, la operación está detenida.
• Cubren datos, pero no el entorno. Tener la base de datos no sirve si no puede reconstruir el servidor, la red, las configuraciones y los accesos que la hacen funcionar.

Un backup que nunca se restauró no es un respaldo: es una hipótesis. Y las hipótesis no se prueban durante una crisis.

RTO y RPO: las dos cifras que cambian la conversación

Cuando una empresa empieza a hablar en serio de continuidad, deja de preguntar "¿cada cuánto hacemos backup?" y empieza a definir dos objetivos:

• RPO (Recovery Point Objective): cuánta información puede permitirse perder, medida en tiempo. Si su RPO es de una hora, necesita respaldos o réplicas al menos cada hora; si es de un día, una copia nocturna podría bastar.
• RTO (Recovery Time Objective): cuánto tiempo puede estar detenido un proceso antes de que el daño sea inaceptable. Es el reloj que corre desde que ocurre el incidente hasta que usted vuelve a operar.

Lo poderoso de estos dos números es que convierten una decisión técnica en una decisión de negocio. Definir el RTO de la facturación o el RPO del sistema de pedidos no es tarea del área de TI en soledad: es una conversación entre quienes conocen el costo real de cada hora de parálisis. Una vez que esas cifras existen, la arquitectura tecnológica deja de ser una opinión y pasa a ser un requisito medible.

DRP vs. BCP: ¿en qué se diferencian y por qué necesita ambos?

Aquí es donde veo más confusión, así que conviene separarlo con claridad.

El DRP (Disaster Recovery Plan) es el plan de recuperación tecnológica. Responde a "¿cómo vuelvo a levantar mis sistemas, datos e infraestructura después de un desastre?". Es el dominio de los servidores, las réplicas, los centros de datos alternos y los procedimientos de restauración. Si quiere profundizar en cómo se diseña uno, lo desarrollamos en detalle en nuestra página sobre planes de recuperación ante desastres (DRP).

El BCP (Business Continuity Plan) es más amplio. Responde a "¿cómo sigue funcionando el negocio mientras la tecnología se recupera o mientras enfrentamos cualquier interrupción mayor?". Incluye personas, procesos, proveedores, comunicación con clientes, ubicaciones alternativas y decisiones de mando. La tecnología es una parte, no el todo. Nuestra visión completa de la continuidad del negocio (BCP) parte justamente de ahí.

La relación es jerárquica: el DRP es un componente del BCP. Puede tener un DRP impecable y aun así quebrar si, durante la caída, nadie sabe quién decide, cómo se atiende a los clientes o dónde trabaja el personal. Y al revés: un BCP bien pensado sin un DRP que lo respalde es un plan sin músculo técnico para sostenerlo.

El año del ransomware: una lección que no deberíamos olvidar

Lo que 2017 nos enseñó es que las amenazas a la continuidad ya no son solo incendios, inundaciones o fallas de hardware. WannaCry demostró que un ataque puede propagarse por una red en minutos y dejar inoperante a una organización completa sin previo aviso. El ransomware cambió el cálculo por una razón específica: ataca directamente la confianza en los respaldos.

Los atacantes aprendieron a buscar y cifrar las copias de seguridad antes de activar el secuestro. Por eso, las defensas que recomiendo a mis clientes giran en torno a principios simples pero exigentes:

• Separación real: al menos una copia fuera de línea o en una red aislada, fuera del alcance de un atacante que ya está dentro.
• Inmutabilidad: respaldos que, una vez escritos, no pueden modificarse ni borrarse durante un período definido.
• Diversidad geográfica: que un incidente físico o lógico en una ubicación no comprometa todas las copias.
• Replicación gestionada: mantener un sitio o entorno secundario que pueda asumir la operación. Para esto trabajamos soluciones de réplica y recuperación como SyncDR, que reducen drásticamente el tiempo de vuelta a la operación.

¿Cómo se construye resiliencia de verdad?

La resiliencia no se compra, se construye por capas y se mantiene. El camino que recorro con las empresas suele tener esta forma:

• Análisis de impacto al negocio (BIA). Identificar qué procesos son críticos y cuánto cuesta cada hora de interrupción. Sin esto, todo lo demás son suposiciones.
• Definición de RTO y RPO por proceso. No todo merece la misma protección; la facturación no es el blog corporativo.
• Diseño del DRP y del BCP. Tecnología y negocio alineados sobre los mismos objetivos.
• Implementación con redundancia y separación. Copias aisladas, réplicas y procedimientos documentados.
• Pruebas periódicas. Restauraciones reales, simulacros y ejercicios de mesa que midan si los tiempos prometidos se cumplen.
• Revisión continua. Los sistemas cambian, los riesgos cambian; el plan debe cambiar con ellos.

El paso que más se omite y el más importante es la prueba. Un plan que no se ensaya envejece en silencio: cambia un servidor, se actualiza una aplicación, se va una persona clave, y el documento sigue diciendo lo que era cierto hace dos años. La única forma de saber si su empresa puede recuperarse es intentar recuperarse antes de que sea obligatorio.

¿Por dónde empezar si siente que está atrasado?

No necesita resolverlo todo de una vez. Si tuviera que elegir tres acciones para las próximas semanas, serían estas: restaure un respaldo reciente en un entorno aislado y mida cuánto tarda; confirme que existe al menos una copia fuera del alcance de la red principal; y reúna a las áreas de negocio para acordar cuántas horas de parálisis y cuánta pérdida de datos serían tolerables en sus procesos críticos. Esas tres respuestas le dirán, sin rodeos, qué tan expuesto está hoy.

Preguntas frecuentes

¿Un respaldo en la nube ya me garantiza continuidad?
No por sí solo. La nube facilita la separación geográfica, pero la continuidad depende de tener objetivos de recuperación definidos, copias verificadas y un plan que cubra también procesos y personas, no solo el almacenamiento de los datos.

¿Cada cuánto debo probar mis respaldos?
Depende de la criticidad del sistema, pero una restauración real de los sistemas más importantes al menos un par de veces al año es un mínimo razonable. Lo esencial es que las pruebas sean reales y midan el tiempo de recuperación, no solo que el archivo abra.

¿Necesito un DRP y un BCP si soy una empresa mediana?
Sí, aunque su alcance será proporcional a su tamaño. Incluso una versión sencilla, que defina procesos críticos, responsables y procedimientos básicos de recuperación, le da una ventaja enorme frente a no tener nada cuando ocurre el incidente.

¿El ransomware cambia mi estrategia de respaldo?
Cambia el supuesto de que sus copias están a salvo solo por existir. Obliga a contar con copias aisladas o inmutables, fuera del alcance de un atacante que ya esté dentro de la red, porque hoy los respaldos son un objetivo deliberado del ataque.

El primer paso

Si después de leer esto no está seguro de cuánto tardaría su empresa en volver a operar tras un incidente grave, esa incertidumbre es, en sí misma, la respuesta. El primer paso no es comprar más tecnología: es medir dónde está parado hoy. En SUMāTO realizamos un diagnóstico de continuidad que evalúa sus respaldos, define sus RTO y RPO por proceso y le entrega un mapa claro de brechas y prioridades, sin compromisos. Conversemos sobre la resiliencia de su operación a través de nuestra página de contacto, y convirtamos esa pregunta incómoda en un plan que pueda probar antes de necesitarlo.