«El backup lo tenemos.» Es la frase que más oímos — y casi siempre es verdad. El problema es que responde a la pregunta equivocada. La pregunta correcta es otra: si mañana por la mañana los sistemas no arrancan, ¿en cuánto tiempo vuelve la empresa a trabajar? Y sobre esta, quien tiene «el backup» a menudo descubre que no tiene respuesta.
Una copia no es una reanudación
El backup es un objeto: una copia de los datos, en algún sitio. Volver a arrancar es un proceso: en qué hardware restauras, en qué orden vuelves a levantar los servicios, quién lo hace, con qué credenciales, siguiendo qué documento. Entre el objeto y el proceso está la diferencia entre quien vuelve a arrancar en horas y quien se queda parado días — con los departamentos llamando, los clientes esperando y cada decisión tomada por impulso.
Esta distinción tiene dos nombres precisos: data protection es proteger el dato; business continuity y disaster recovery es garantizar que la empresa siga funcionando. Son dos disciplinas distintas, y la segunda no se compra: se diseña.
RTO y RPO: las dos preguntas que hacerse antes
Todo plan serio parte de dos parámetros, que en el fondo son dos preguntas sencillas:
- RTO (Recovery Time Objective): ¿cuánto tiempo puedes estar parado? De aquí se deriva todo: un RTO de 4 horas y uno de 2 días llevan a arquitecturas — y costes — completamente distintos;
- RPO (Recovery Point Objective): ¿cuántos datos puedes permitirte perder? Las horas de trabajo entre la última copia útil y el momento del fallo no vuelven.
El punto que cambia la perspectiva: RTO y RPO no se definen «para la empresa», se definen por servicio. El correo electrónico, el ERP y el archivo histórico no valen lo mismo — y tratarlos igual significa gastar demasiado donde no hace falta y demasiado poco donde duele.
No todos los servicios valen lo mismo
La herramienta para decidirlo se llama Business Impact Analysis (BIA): el análisis que pone en fila los procesos de la empresa, mide qué ocurre si cada uno se detiene — facturación perdida, obligaciones frente a terceros, daño reputacional — y de ahí obtiene prioridades y objetivos de reanudación. Es el momento en que el plan deja de ser un documento IT y se convierte en una decisión de negocio: qué servicios vuelven primero, en qué orden y cuánto merece la pena invertir en cada uno.
Un backup no probado es una esperanza
El día del desastre no es el momento adecuado para descubrir si la restauración funciona.
Las copias pueden estar corruptas, incompletas o, simplemente, ser más lentas de restaurar de lo que nadie imaginaba. La única forma de saberlo es probar: verificaciones de restauración periódicas — por muestreo en los sistemas individuales y, con la cadencia adecuada, completas en los servicios críticos — cronometrando los tiempos reales y comparándolos con el RTO declarado. Si la restauración medida del ERP requiere 11 horas y el objetivo era 4, mejor saberlo un martes tranquilo que durante el incidente.
Cuando el atacante busca precisamente los backups
Hoy hay una razón más para tomarse todo esto en serio: en los ataques ransomware modernos las copias de seguridad no son un daño colateral — son un objetivo primario. Quien cifra los datos sabe que una empresa con backups íntegros no paga: por eso intenta alcanzar y destruir primero las copias.
Las contramedidas son conocidas y deben aplicarse juntas: la regla 3-2-1 (tres copias, en dos soportes distintos, una de ellas fuera de las instalaciones), al menos una copia inmutable o desconectada que ninguna credencial comprometida pueda borrar, y la separación entre las cuentas que administran los sistemas y las que administran los backups. A esto se suma el trabajo de prevención y respuesta: el backup es la última línea de defensa, no la única.
El valor de alguien que vigila
Última lección del terreno: los backups fallan en silencio. Un job que se interrumpe, un almacenamiento que se llena, un sistema nuevo que nunca se añadió a las políticas — y el descubrimiento llega siempre en el peor momento. La diferencia la marca una supervisión diaria: alguien que controla los resultados, corrige las desviaciones y mantiene las políticas alineadas con cómo es la empresa hoy.
Es la razón por la que prestamos la protección del dato como servicio gestionado — con verificaciones de restauración incluidas y el NOC vigilando los jobs junto con el resto de la infraestructura. Y si quieres partir de la pregunta correcta — «¿en cuánto tiempo volvemos a arrancar?» — hagámosla juntos, con un Business Impact Analysis.
