Respaldos 3-2-1 y la prueba de restauración que casi nadie hace

Tener respaldos no es lo mismo que poder recuperarte. Siete prácticas para que la copia exista, esté fuera del alcance de un ataque y se restaure cuando la necesites.

Casi todas las áreas de TI tienen respaldos. Muchas menos han restaurado alguno en serio. El día que hace falta descubren que la copia estaba incompleta, que nadie sabe la clave o que el ataque también cifró el disco donde se guardaba. Un respaldo que no se ha probado es, en la práctica, una esperanza.

1. Aplica la regla 3-2-1

Tres copias de los datos (la original y dos respaldos), en dos tipos de medio distintos y una de ellas fuera del sitio. No es un invento reciente: sigue siendo la base porque cubre las tres cosas que fallan: un disco, un edificio y un error humano.

2. Una copia que el ransomware no pueda tocar

Muchas variantes del ransomware buscan y cifran los respaldos accesibles desde la misma red. Por eso se habla de extender la regla con una copia inmutable o desconectada: almacenamiento con retención bloqueada (WORM), cinta fuera de línea o una cuenta de respaldo con credenciales separadas de las del dominio.

• Credenciales del respaldo distintas a las de administración diaria.
• Sin unidades de red montadas de forma permanente en el servidor que se respalda.

3. Define qué se respalda y qué no

Haz una lista de sistemas con su importancia: correo, ERP, servidores de archivos, bases de datos, configuraciones de red, repositorios. Lo que no está en la lista no se respalda, y suele ser justo lo que alguien necesita: la configuración del firewall, las llaves de cifrado, el DNS.

4. Fija dos números: cuánto puedes perder y cuánto puedes esperar

El punto objetivo de recuperación (RPO) es cuántos datos aceptas perder; el tiempo objetivo (RTO), cuánto tarda el negocio en volver a operar. Un despacho que factura a diario no puede tener un RPO de una semana. Pregunta a quien usa el sistema, no lo decidas solo desde TI.

5. Restaura de verdad, y con calendario

Una vez al trimestre, restaura algo en un entorno aparte y mide cuánto tardó. Alterna lo que pruebas: un archivo suelto, una base de datos, una máquina virtual completa. Anota quién lo hizo, qué falló y cuánto tomó; ese tiempo real es tu RTO verdadero.

6. Cifra los respaldos y guarda las llaves aparte

Un respaldo fuera del sitio es un riesgo de privacidad si va en claro. Cífralo, pero guarda la llave en un lugar distinto y conocido por más de una persona. Un respaldo cifrado cuya llave se fue con quien renunció tampoco sirve.

7. Documenta el procedimiento y vigila los avisos

Escribe los pasos de recuperación para que los pueda seguir alguien que no los diseñó, a las tres de la mañana. Y revisa los reportes de ejecución: un respaldo que falla en silencio durante semanas es más común de lo que parece. Configura alertas para los trabajos fallidos, no sólo para los exitosos.

Para empezar esta semana

• Elige un sistema importante y restáuralo en un entorno de prueba.
• Verifica que al menos una copia esté fuera de la red principal.
• Anota los tiempos reales y compáralos con lo que el negocio espera.

Lo que te enseñe esa primera prueba suele ser más útil que cualquier política escrita.

TI respaldos continuidad seguridad mejores prácticas

← Volver al índice