Un plan de backup y recuperación ante desastres (DR) no se mide por cuántas copias se hacen, sino por cuánto tarda la organización en volver a operar tras un incidente y cuántos datos pierde por el camino. Esas dos preguntas tienen nombre técnico —RTO y RPO— y son el punto de partida de cualquier diseño serio. En este artículo desarrollamos la metodología completa: del análisis de impacto al failover automático, con la regla 3-2-1-1-0, la defensa frente a ransomware y las pruebas de recuperación que separan un plan real de un documento decorativo.
RTO y RPO: las dos métricas que lo gobiernan todo
El RTO (Recovery Time Objective) es el tiempo máximo aceptable que un sistema puede estar caído tras un incidente antes de provocar un daño inasumible al negocio. El RPO (Recovery Point Objective) es la cantidad máxima de datos, medida en tiempo, que la organización puede permitirse perder; un RPO de una hora significa que, en el peor caso, se perderá hasta una hora de transacciones. Ambos se derivan del Análisis de Impacto en el Negocio (BIA), que clasifica cada sistema por su criticidad.
La consecuencia técnica es directa: un RPO de cinco minutos no se cubre con un backup nocturno, exige replicación casi continua; un RTO de quince minutos no se cubre restaurando desde cinta, exige un sistema en espera caliente. Definir RTO y RPO sistema por sistema es lo que evita el doble error de gastar de más protegiendo lo irrelevante o quedarse corto en lo crítico. Estas métricas son, además, requisito explícito de la norma ISO 22301 de continuidad de negocio y del control de respaldo de la ISO/IEC 27001:2022.
La regla 3-2-1 y su evolución 3-2-1-1-0
La regla clásica 3-2-1 establece: tres copias de los datos, en dos tipos de medio distintos, con una copia fuera de las instalaciones (offsite). Es el mínimo civilizado. La era del ransomware ha exigido endurecerla a 3-2-1-1-0: el primer «1» adicional exige una copia inmutable o air-gapped (aislada de la red), y el «0» exige cero errores en la verificación de las copias. Una copia que no se ha verificado no es una copia: es una suposición.
La inmutabilidad se implementa con tecnologías de object lock en almacenamiento de objetos o con repositorios WORM (Write Once Read Many). El motivo es que el ransomware moderno busca y cifra activamente los repositorios de backup antes de detonar; si la copia no puede modificarse ni borrarse durante su periodo de retención, el atacante no puede inutilizarla. El air-gap, físico o lógico, añade una segunda barrera al desconectar la copia de la red de producción.
Tipos de copia: completa, incremental y diferencial
El backup completo copia todos los datos cada vez; es el más sencillo de restaurar pero el más costoso en espacio y ventana. El incremental copia solo lo cambiado desde la última copia (sea completa o incremental); minimiza la ventana de backup pero encadena dependencias, de modo que restaurar exige la completa más toda la cadena de incrementales. El diferencial copia lo cambiado desde la última completa; ocupa más que el incremental pero restaura en dos pasos. La estrategia habitual combina una completa semanal con incrementales o diferenciales diarios, ajustando la frecuencia al RPO objetivo.
Dos técnicas modernas matizan este esquema clásico. El backup incremental permanente (incremental-forever) realiza una sola copia completa inicial y, a partir de ahí, solo incrementales, sintetizando periódicamente una nueva completa en el repositorio sin volver a leer todos los datos de origen; esto reduce drásticamente la carga sobre los sistemas de producción. Por su parte, la deduplicación elimina los bloques repetidos antes de almacenarlos, de modo que un dato idéntico presente en mil máquinas se guarda una sola vez, con ratios de ahorro que en entornos virtualizados superan con frecuencia el 90 %. Ambas técnicas abaratan la retención larga, pero introducen una dependencia crítica: si se corrompe la copia completa base o el índice de deduplicación, toda la cadena queda comprometida, lo que refuerza la necesidad de verificación periódica.
Un último concepto a planificar es la retención escalonada (GFS, Grandfather-Father-Son): copias diarias que se conservan unas semanas, semanales que se conservan meses y mensuales o anuales que se conservan años. Este esquema equilibra la capacidad de volver a un punto reciente con la obligación legal o de negocio de conservar hitos a largo plazo, y debe alinearse con las políticas de conservación que impone el RGPD para los datos personales.
Replicación y failover: de la copia a la continuidad
El backup protege los datos; la replicación protege el servicio. La replicación síncrona escribe en el sitio primario y en el secundario antes de confirmar la transacción, lo que garantiza un RPO de cero pero impone una distancia máxima por latencia. La replicación asíncrona confirma en el primario y propaga al secundario con un pequeño desfase, lo que permite distancias geográficas grandes a cambio de un RPO de segundos o minutos.
El failover es el mecanismo que conmuta la operación al sitio secundario cuando el primario cae. Puede ser manual, asistido o automático. El failover automático con un RTO de minutos exige un sitio en espera caliente, balanceadores que redirijan el tráfico y una base de datos replicada y promovible. Igual de importante es el failback: el procedimiento para volver al sitio primario una vez restaurado, sin perder los datos generados en el secundario durante la contingencia. Muchos planes diseñan el failover y olvidan el failback, y descubren el problema en el peor momento.
Estrategias de DR según presupuesto y criticidad
| Estrategia | RTO típico | RPO típico | Coste relativo |
|---|---|---|---|
| Backup & restore | Horas a días | Hasta 24 h | Bajo |
| Pilot light | Decenas de minutos | Minutos | Medio-bajo |
| Warm standby | Minutos | Segundos a minutos | Medio-alto |
| Multi-site activo-activo | Casi cero | Casi cero | Alto |
La elección no es una preferencia estética: se deduce del RTO y el RPO que el BIA fijó para cada sistema. Un ERP que factura no admite el mismo nivel que un portal interno de documentación, y mezclar ambos en la misma estrategia es desperdiciar dinero o asumir riesgo inaceptable.
Las pruebas de recuperación: lo que de verdad distingue un plan real
Un plan de DR no probado es ficción documental. Las pruebas deben ser periódicas y escalonadas: revisión de tabletop (sobre papel, validando roles y decisiones), pruebas de restauración parcial de sistemas concretos y, al menos una vez al año, un simulacro de failover completo que conmute la producción al sitio secundario. La métrica que se valida es doble: que el RTO real no supera el objetivo y que la integridad de los datos restaurados es del 100 %. La ISO 22301 exige documentar estos ejercicios y registrar las lecciones aprendidas.
Un detalle frecuentemente olvidado: el procedimiento de recuperación debe estar disponible fuera de los sistemas que protege. Si las instrucciones de DR viven solo en el servidor de ficheros que acaba de caer, el plan se ha autosaboteado.
Backup y RGPD: la dimensión legal
Las copias de seguridad contienen datos personales y, por tanto, están sujetas al RGPD. Esto implica cifrar las copias en tránsito y en reposo, controlar el acceso a los repositorios y aplicar políticas de retención coherentes con el principio de limitación del plazo de conservación. El derecho de supresión («derecho al olvido») plantea un reto técnico: cuando un interesado ejerce su derecho, los backups históricos lo conservarán hasta su caducidad; la solución aceptada por la Agencia Española de Protección de Datos es documentar la imposibilidad de borrado selectivo en backup y garantizar que el dato no se reintroducirá si se restaura una copia antigua.
Errores comunes en planes de backup y DR
- No probar la restauración: el backup parece correcto hasta que se intenta restaurar y falla.
- Una sola copia online: sin copia inmutable u offline, el ransomware cifra también los respaldos.
- RTO/RPO sin BIA: objetivos fijados por intuición que no responden al impacto real.
- Olvidar el failback: se conmuta al secundario y no hay forma limpia de volver.
- Copias sin cifrar: riesgo legal y de exfiltración del repositorio de respaldo.
Preguntas frecuentes
¿Cada cuánto debo hacer copias de seguridad?
La frecuencia la dicta el RPO de cada sistema. Si el negocio no puede perder más de una hora de datos, las copias o la replicación deben cubrir esa ventana; no hay un número universal válido para todos los sistemas.
¿La nube hace innecesario el plan de DR?
No. La nube facilita la geo-redundancia, pero el modelo de responsabilidad compartida deja el respaldo de los datos y la configuración del DR en manos del cliente. Un fallo de configuración o un borrado accidental no lo cubre el proveedor.
¿Qué es una copia inmutable y por qué importa?
Es una copia que no puede modificarse ni eliminarse durante un periodo definido. Importa porque neutraliza el ataque del ransomware contra los propios respaldos, que es hoy una de las tácticas más habituales.
¿Con qué frecuencia hay que probar el plan de DR?
Como mínimo una vez al año con un simulacro completo, y de forma trimestral con pruebas parciales de restauración. Tras cualquier cambio importante de infraestructura conviene repetir la prueba.
Conclusión
Un plan de backup y recuperación robusto se construye al revés de como suele hacerse: primero se decide cuánto downtime y cuánta pérdida de datos tolera el negocio (RTO y RPO por sistema), y solo después se elige la tecnología que cumple esos números al menor coste. La regla 3-2-1-1-0, la copia inmutable frente al ransomware y, sobre todo, las pruebas de restauración periódicas son lo que convierte un conjunto de copias en una verdadera capacidad de continuidad. En Summum Sistemas diseñamos planes de DR partiendo siempre del BIA y los validamos con simulacros reales, porque el único backup que cuenta es el que se ha demostrado que restaura, y el único plan que vale es el que ya se ha ejecutado al menos una vez antes del incidente de verdad.