ENS, RGPD y NIS2: qué exige tu infraestructura en 2026
Checklist práctico para sectores regulados: soberanía del dato, CLOUD Act y qué tiene que cumplir tu cloud privado para no llevarte un susto en la auditoría.
La regla 3-2-1 y el backup inmutable: defensa real contra el ransomware
Hay una frase que repetimos hasta el cansancio porque sigue salvando empresas: un backup que nunca has restaurado no es un backup, es una esperanza. Y hay otra que el ransomware moderno nos ha obligado a añadir: un backup que el atacante puede borrar o cifrar no es un backup, es una víctima más.
El ransomware ya no se limita a cifrar tus servidores de producción. Antes de actuar, busca activamente tus copias de seguridad (repositorios de red, snapshots, NAS) y las destruye o las cifra. Así te quita la única salida que no pasa por pagar. Contra esto no te salva el antivirus, sino la arquitectura de backup. Y se resume en dos conceptos: la regla 3-2-1 y la inmutabilidad.
La regla 3-2-1, explicada bien
Es la base de cualquier estrategia de copias seria, y es deliberadamente simple para que se cumpla:
- 3 copias de tus datos (la producción + 2 backups).
- 2 soportes o tipos de medio distintos (que un fallo no se las lleve todas a la vez).
- 1 copia fuera de las instalaciones (offsite), por si el sitio entero arde, se inunda o lo cifran.
La lógica es de sentido común: ningún fallo único debería poder destruir todas tus copias a la vez. Un incendio se lleva el datacenter local; un error humano borra el volumen principal; un ransomware cifra lo que esté en red. Si una sola desgracia puede tocar todas tus copias, no cumples la 3-2-1.
La extensión moderna: 3-2-1-1-0
Con el ransomware como amenaza dominante, la regla ha evolucionado:
| Cifra | Significado |
|---|---|
| 3 | Tres copias de los datos |
| 2 | En dos tipos de soporte distintos |
| 1 | Una copia offsite |
| 1 | Una copia inmutable o air-gapped |
| 0 | Cero errores tras verificación de la copia |
Las dos novedades, el segundo “1” y el “0”, son justo las que paran al ransomware.
Inmutabilidad: la copia que nadie puede borrar
Una copia inmutable no se puede modificar ni eliminar durante un periodo definido, ni siquiera por un administrador con credenciales robadas. Aunque el atacante consiga las llaves del reino, no puede tocar esa copia hasta que expire su ventana de inmutabilidad.
Se consigue de varias formas:
- Object Lock / WORM (Write Once Read Many) en almacenamiento de objetos compatible con S3. La copia queda bloqueada por software a nivel de almacenamiento.
- Repositorios endurecidos (hardened repositories) que no exponen credenciales con permisos de borrado.
- Air-gap real o lógico: copias en un medio físicamente desconectado, o accesible solo en ventanas controladas.
La clave conceptual: la inmutabilidad no depende de que tus credenciales sean seguras. Asume que el atacante ya está dentro y aun así no puede destruir esa copia. Es la diferencia entre restaurar en horas o negociar un rescate.
El “0”: verificación, no fe
La última cifra es la más ignorada y la que más duele cuando falta. De nada sirve tener copias inmutables y offsite si el día del desastre descubres que estaban corruptas o incompletas.
Verificar significa:
- Probar restauraciones de verdad, no comprobar que el job terminó en verde. Restaura a un entorno aislado y arranca el sistema.
- Comprobar la integridad de los backups de forma automatizada y periódica.
- Documentar los tiempos reales de restauración, que es lo que te dirá tu RTO real.
Un proveedor serio te enseña informes de verificación, no solo de ejecución. Si nadie ha restaurado nunca esas copias, no sabes si funcionan.
Cómo se traduce esto en una arquitectura real
Una implementación sensata para una pyme se parece a esto:
- Copia primaria rápida en local (recuperaciones del día a día, RTO bajo).
- Copia secundaria en un repositorio endurecido, en otro datacenter (offsite).
- Copia inmutable con Object Lock, fuera del alcance de cualquier credencial de producción.
- Verificación automática de restaurabilidad, con informes.
Herramientas como Veeam o Proxmox Backup Server cubren esto bien: deduplicación, cifrado, copias inmutables y verificación. Lo detallamos en nuestros servicios de backup gestionado con Veeam y Proxmox Backup Server.
El backup no es el plan de recuperación entero
Importante no confundir conceptos: el backup es la pieza de datos. El plan de recuperación es lo que define cuánto tardas en volver a operar y cuántos datos puedes permitirte perder (tu RTO y tu RPO). Una cosa alimenta a la otra, pero no son lo mismo. Lo explicamos en RTO y RPO: cómo dimensionar tu Disaster Recovery y se concreta en un servicio de Disaster Recovery.
Lo que separa restaurar de pagar
El ransomware ha convertido el backup de un trámite en una línea de defensa de primer nivel. La regla 3-2-1, extendida con una copia inmutable y verificación real, es lo que separa a las empresas que restauran de las que pagan. No es complejo de entender; es cuestión de hacerlo bien y, sobre todo, de probarlo antes de necesitarlo.
Si quieres una estrategia de copias que aguante un ataque real, inmutable, offsite y verificada, podemos diseñarla y operarla por ti, y demostrártelo con restauraciones de prueba. Eso, también, forma parte de cumplir con ENS, RGPD y NIS2.