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.
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:
Un backup que nunca se restauró no es un respaldo: es una hipótesis. Y las hipótesis no se prueban durante una crisis.
Cuando una empresa empieza a hablar en serio de continuidad, deja de preguntar "¿cada cuánto hacemos backup?" y empieza a definir dos objetivos:
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.
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.
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:
La resiliencia no se compra, se construye por capas y se mantiene. El camino que recorro con las empresas suele tener esta forma:
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.
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.
¿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.
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.