Casi todas las empresas tienen copias de seguridad. Muchas menos saben si esas copias se pueden restaurar, cuánto tardarían en hacerlo y qué datos perderían por el camino. Y es en el peor momento posible, tras un fallo de hardware o un ataque de ransomware, cuando se descubre la diferencia entre "tenemos backup" y "podemos recuperar el servicio".
La regla 3-2-1… y su versión actual
La regla clásica 3-2-1 dice:
- 3 copias de los datos (la original y dos copias).
- En 2 soportes distintos.
- 1 copia fuera de las instalaciones.
Con la generalización del ransomware, que busca y cifra también las copias accesibles desde la red, la regla ha evolucionado a 3-2-1-1-0:
- 1 copia offline o inmutable, que no pueda ser modificada ni borrada desde los sistemas de producción, ni siquiera con credenciales de administrador.
- 0 errores en la verificación: las copias se comprueban y se restauran periódicamente.
RPO y RTO: las dos preguntas que hay que responder
Antes de hablar de herramientas, el negocio tiene que responder dos preguntas por cada servicio:
- RPO (Recovery Point Objective): ¿cuántos datos podemos permitirnos perder? Si la respuesta es "una hora", una copia diaria no es suficiente.
- RTO (Recovery Time Objective): ¿cuánto tiempo puede estar el servicio caído? Restaurar varios terabytes desde una copia remota puede llevar días.
Con estas respuestas se decide la frecuencia de las copias, dónde se guardan, qué tecnología se usa y si hacen falta réplicas o alta disponibilidad además del backup.
Errores habituales
En las auditorías encontramos una y otra vez los mismos problemas:
- Copias en el mismo servidor o en la misma red que los datos originales, al alcance de cualquier ransomware.
- Credenciales compartidas: la consola de backup usa la misma cuenta de dominio que el resto de sistemas.
- Trabajos que fallan en silencio durante semanas porque nadie revisa las alertas.
- Copias de ficheros, pero no de la configuración: se puede recuperar un documento, pero no reconstruir el servidor.
- Bases de datos copiadas "en caliente" sin el mecanismo adecuado, lo que produce copias inconsistentes.
- Nadie ha probado nunca una restauración completa.
Cómo organizar las pruebas de restauración
Una copia que no se ha restaurado nunca es una hipótesis. Proponemos un calendario sencillo:
- Mensual: restaurar ficheros o elementos concretos elegidos al azar y comprobar su integridad.
- Trimestral: restaurar un servidor completo en un entorno aislado y verificar que arranca y que la aplicación funciona.
- Anual: simulacro de desastre de un servicio crítico, midiendo el tiempo real de recuperación frente al RTO acordado.
Cada prueba debe quedar documentada: qué se restauró, cuánto tardó, qué falló y qué se corrigió.
El objetivo de una prueba de restauración no es aprobarla, es encontrar los problemas antes de que lo haga un incidente real.
Protección frente al ransomware
Además de la copia inmutable, conviene:
- Separar la infraestructura de backup del dominio de producción, con credenciales propias y autenticación multifactor.
- Restringir en la red qué sistemas pueden llegar a los repositorios de copia.
- Activar la inmutabilidad que ofrecen los repositorios compatibles (bloqueo de objetos en almacenamiento S3, repositorios endurecidos, cintas o soportes desconectados).
- Monitorizar cambios anómalos en el volumen o la tasa de cambio de los datos copiados.
En resumen
Tener copias de seguridad no es suficiente: hay que saber qué se copia, con qué frecuencia, dónde se guarda, quién puede borrarlo y, sobre todo, comprobar que se puede recuperar dentro del tiempo que el negocio necesita. La regla 3-2-1-1-0 y un calendario de pruebas de restauración son la forma más fiable de conseguirlo.
Si no recuerdas cuándo fue la última vez que restauraste un servidor completo, es un buen momento para revisar tu estrategia de copias.