Durante años, muchas empresas en Chile trataron el respaldo de datos y la continuidad de negocio como si fueran la misma cosa: "tenemos backup, así que estamos cubiertos pase lo que pase". Ese supuesto es, hoy, uno de los puntos ciegos más comunes en las estrategias de resiliencia tecnológica — y de los más caros de descubrir justo cuando no toca: en medio de una caída real.

Porque una cosa es tener copias de tus datos y otra muy distinta es poder seguir operando cuando algo falla. Esa diferencia no es un detalle técnico menor. Es la diferencia entre recuperar información y recuperar el negocio.

Disaster recovery vs backup: no son la misma pregunta

El backup responde algo puntual: ¿tengo una copia de mis datos? El disaster recovery, en cambio, responde una pregunta bastante más exigente: ¿puedo volver a operar, y en cuánto tiempo?

Un respaldo bien hecho asegura que la información no se pierda. Pero no dice nada sobre cuánto va a demorar restaurarla, si los sistemas críticos van a estar disponibles durante ese proceso, ni si la recuperación prioriza lo que de verdad mantiene a la empresa funcionando. Y ahí está el problema: una empresa puede tener respaldos impecables y aun así quedar días sin poder facturar, atender clientes o acceder a sus propios sistemas, simplemente porque nunca definió cómo se restablece la operación.

De esa distinción nace justamente el concepto de BCDR (Business Continuity and Disaster Recovery): la unión, a propósito, entre la recuperación técnica de los datos y la continuidad real de las operaciones.

RTO y RPO: las dos métricas que el backup no responde

Acá está el fondo del asunto, y por qué separar respaldo y continuidad dejó de ser opcional: hay dos métricas que definen si una empresa está realmente preparada, y ninguna de las dos se resuelve solo con hacer copias de seguridad.

RPO (Recovery Point Objective) es cuánta información puede permitirse perder una organización, medida en tiempo. Si el RPO definido es de 4 horas, quiere decir que ante un incidente la empresa acepta perder, como máximo, lo que se generó en esas 4 horas previas. Un backup diario, por ejemplo, deja un RPO de hasta 24 horas — y para varias operaciones críticas, ese margen simplemente no da.

RTO (Recovery Time Objective) es el tiempo máximo tolerable para volver a levantar un sistema o proceso después de una interrupción. No es cuánto se demora restaurar un archivo; es cuánto tiempo puede estar detenida un área del negocio antes de que el daño sea grave: ventas que se pierden, contratos que se incumplen, reputación golpeada o, en sectores regulados, infracciones normativas.

El error más común es dejar estos objetivos genéricos, o de plano no definirlos. Cada sistema y cada proceso tiene una tolerancia distinta: los sistemas transaccionales o de atención a clientes suelen necesitar RTO y RPO medidos en minutos, mientras otros procesos administrativos pueden esperar horas sin mayor drama. Sin esta segmentación, las empresas terminan protegiendo todo por igual — o peor, protegiendo lo menos importante y dejando expuesto justo lo que sostiene la operación.

Un backup, por sí solo, no define RTO ni RPO. Eso solo lo resuelve una estrategia de BCDR pensada específicamente para restaurar operaciones dentro de esos márgenes.

Qué tiene que tener un plan de continuidad de negocio

Un plan de continuidad de negocio que funciona no es un documento que explica cómo se hacen los respaldos. Es un plan que responde, para cada proceso crítico de la organización:

• ¿Cuál es el RTO y el RPO aceptable para este proceso en particular?
• ¿Qué sistemas, datos y accesos se necesitan para levantarlo de nuevo, y en qué orden?
• ¿Quién ejecuta cada paso de la recuperación y bajo qué protocolo de comunicación?
• ¿Con qué frecuencia se prueba que el plan funciona en la práctica, y no solo en el papel?

Este último punto es donde muchas estrategias fallan sin que nadie se dé cuenta: un plan de continuidad que nunca se prueba es, en los hechos, una suposición. Las pruebas de recuperación — simulacros controlados de restauración — son las que confirman si los tiempos que se pusieron como meta (el RTO) son realmente alcanzables con la infraestructura actual, o si hay una brecha entre lo que la empresa cree que puede hacer y lo que de verdad puede hacer.

BCDR para empresas en Chile: ya no es solo buena práctica

En Chile, esta conversación dejó de ser puramente técnica. La Ley Marco de Ciberseguridad (Ley 21.663) exige a las entidades definidas como Operadores de Importancia Vital (OIV) contar con planes de continuidad operativa y capacidad de recuperación ante incidentes. Para esas organizaciones, tener solo respaldo — sin una estrategia de continuidad con RTO y RPO definidos — ya no es una decisión interna de gestión de riesgo, es una brecha frente a un marco regulatorio que ya está vigente.

Pero aunque tu empresa no esté dentro del alcance de la ley, el principio es el mismo si dependes de tus sistemas para operar: la pregunta ya no es si existe un respaldo, sino si tu organización sabe con precisión cuánto tiempo de inactividad puede aguantar y cuánta información puede permitirse perder — y si la infraestructura actual está diseñada para cumplir esos números.

Definir esos umbrales, armar el plan de continuidad alrededor de ellos y comprobarlos con pruebas reales es, al final, lo que separa a una empresa que "tiene backup" de una que puede seguir funcionando cuando algo se cae.

Si quieres revisar cuáles son los RTO y RPO realistas para los procesos críticos de tu organización, conversemos.