Un incendio en el NIRS (Daejeon, Corea) ha destruido el G-Drive gubernamental —el “cloud” interno donde ~750.000 funcionarios guardaban su trabajo desde 2018— y ha dejado inutilizados 96 sistemas críticos colaterales. No existían copias externas del G-Drive por la arquitectura elegida (almacenamiento de gran capacidad y bajo rendimiento sin backup off-site), así que los ficheros de usuario se han perdido salvo lo que pueda recuperarse de otros sistemas (p. ej., OnNara). Traducción para admins: la “nube” no era multi-CPD, no tenía 3-2-1 y, además, había acoplamiento entre servicios críticos en el mismo dominio de fallo.
En España, el ENS (RD 311/2022), en nivel Alto, exige DRP y copias adecuadas; pero ya sabemos que norma ≠ ejecución. Este incidente es un buen detonante para revisar arquitectura, backups y procedimientos.
El fallo de diseño (y cómo evitarlo)
Qué salió mal
- Monolito físico: servicio “cloud” en un solo CPD.
- Sin off-site: la propia arquitectura no permitía backups externos.
- Acoplamiento: otros 96 sistemas críticos cayeron con el mismo evento.
- Uso exclusivo: algunos ministerios obligaban a usar G-Drive como única fuente.
Antídoto mínimo para cualquier plataforma “enterprise”
- Regla 3-2-1 (mejor 3-2-1-1-0)
- 3 copias, 2 soportes distintos, 1 off-site; añade 1 copia inmutable/air-gapped (S3 Object Lock, WORM, cinta) y 0 errores verificados en restauraciones de prueba.
- Redundancia geográfica
- Activo-activo entre dos zonas/regiones (RTO≈0 si hay capacidad).
- Activo-pasivo con conmutación orquestada y RTO definido.
- Separación de dominios de fallo
- Energía, refrigeración, red, racks, uplinks, proveedores (cuando aplique).
- Backups fuera del plano
- Repositorios gestionados con identidades segregadas, MFA y acceso mínimo, no dependientes del mismo IAM/AD que producción.
- Inmutabilidad
- WORM (S3 Object Lock compliance mode), air-gap con cinta o repositorios “sellados”.
- RPO/RTO reales
- Defínelos por servicio. Documenta dependencias (DNS, IAM, PKI, colas, feature flags).
- DR drills
- Ensayos de conmutación y de restauración temporizados, al menos 1–2/año y tras cambios relevantes.
Arquitecturas de referencia (rápidas y con impacto)
1) “Cloud” privado/colo: activo-activo + backup inmutable
[CPD A] <—replicación síncrona/async—> [CPD B]
\ /
\—(jobs backup→repositorio WORM)—> [CPD C]
Lenguaje del código: HTML, XML (xml)- Producción: replicación de metadatos y datos (block/object) entre A y B.
- Copia: backup inmutable diario/horario a C (otra región/proveedor).
- Runbook: conmutación a B (fallo A) o restauración desde C (evento catastrófico).
2) Híbrido/SaaS: responsabilidad compartida
- SaaS≠ backup de tus datos. Exige en contrato:
- Ubicaciones (zonales/regionales) y RPO/RTO proveedor.
- Exportabilidad periódica a tu repositorio WORM.
- Pruebas de recuperación o evidencias auditables.
Herramientas y patrones que funcionan (y que puedes desplegar mañana)
- Backups
- Proxmox Backup Server: deduplicación, cifrado, verificación de restauras, retention policies, soporte immutable (con store backends adecuados).
- Veeam: scale-out repositories, SOBR con Object Lock, detección de anomalías, SureBackup (verificación), DR Orchestrator.
- Cinta LTO: air-gap económico para retenciones largas/compliance.
- Datos
- S3-compatible con versionado + Object Lock (MinIO/ceph-rgw, nube pública).
- ZFS snapshots + send/receive entre CPDs, con retention y scrub programado.
- Orquestación DR
- Infraestructura como código (Terraform/Ansible) + runbooks automatizados.
- DNS/Anycast/GLB para bascular tráfico. Config-as-code (Consul/etcd).
- Seguridad
- IAM/LAPS para repos de backup separado del dominio de producción.
- MFA obligatorio; bóveda de secretos (HashiCorp Vault; HSM si aplica).
- SIEM/SOAR alertando de borrados masivos, cambios de políticas o cifrado de repositorios.
Mini-runbook (plantilla) — caída total del CPD A
Objetivo: recuperar servicio desde B con RPO≤X min y RTO≤Y min.
- Activar DR (trayecto corto)
- Congelar cambios en A (si está medio vivo).
- Promover B como primario (base de datos/objetos/colas).
- Cambiar DNS/GLB → B.
- Validar salud (APM, synthetics, healthchecks).
- Comunicar estado.
- Activar DR (trayecto largo: pérdida de ambos A/B)
- Provisionar B desde templates (IaC).
- Restaurar datos desde C (WORM):
- DB → point-in-time
- Objetos/ficheros → última versión válida
- Validar integridad (checksums), arrancar servicios, conmutar DNS.
- Post-mortem
- Tiempo de detección, RPO real, RTO real, bloqueo, causas raíz, acciones.
Checklist de sysadmin (para no repetir Daejeon)
- Dos zonas/CPDs en activo-activo o conmutación probada (runbooks).
- Copia off-site inmutable (WORM/air-gap) en tercer dominio de fallo.
- RPO/RTO por servicio y ensayos documentados.
- Backups fuera del plano (IAM segregado, MFA, acceso mínimo).
- Monitorización de anomalías en repos de backup y alertas.
- Inventario de datos (SaaS incluido) y export/retención definidos.
- ENS/ISO 27001/22301 y evidencias de auditoría al día.
- DR drills al menos semestrales con tiempos y resultados.
Comentario experto — David Carrero (Stackscale – Grupo Aire)
“La mejor póliza no es una, son varias. En Stackscale desplegamos producción activo-activo en dos CPDs distintos y, además, copias inmutables en un tercer sitio. Para backup inmutable o air-gap usamos herramientas como Proxmox Backup Server o Veeam con Object Lock. Lo crucial no es la marca, es el diseño y probar las recuperaciones: sin test, no hay DRP.”
Traducción operativa: producción que sobrevive a la caída de un sitio, copias que no pueden ser alteradas y ensayos cronometrados de conmutación/restauración.
Plantilla de política 3-2-1-1-0 (fragmento)
policy:
copies:
total: 3
media:
- disk (primary)
- object-storage (WORM)
offsite:
enabled: true
location: cpd-c
immutability:
mode: compliance
retention: 30d
rpo: "15m" # por servicio
rto: "60m"
verification:
schedule: weekly
method: restore-test + checksum
target: isolated network
access:
iam: separate-domain
mfa: required
roles:
- backup-admin (no prod)
- restore-operator (break-glass)
Lenguaje del código: PHP (php)SaaS: recordatorio incómodo
- Tu responsabilidad saber dónde están tus datos y cómo se recuperan.
- Pacta por contrato RPO/RTO, export periódica, evidencias de DR y opción de ensayo.
- Mantén copias propias (export/backup) en repositorio WORM.
FAQ
¿Cada cuánto debo probar DR?
Como mínimo 1–2 veces/año y tras cambios significativos; siempre con tiempos (RTO real) y reporte.
¿Activo-activo o activo-pasivo?
Depende de tu RTO y presupuesto. Activo-activo minimiza downtime pero complica coherencia; pasivo reduce coste pero aumenta RTO.
¿Qué uso para inmutabilidad?
S3 Object Lock (compliance), cinta LTO para air-gap, snapshots ZFS con retenciones, y repositorios PBS/Veeam configurados en WORM.
¿Cómo detecto que alguien “mata” mis backups?
Alertas por cambios de políticas, borrados masivos, patrones de cifrado; auditoría IAM, MFA universal y separación de dominios de identidad.
Conclusión
Si tu “nube” cabe en un edificio, no es nube: es un punto único de fallo con mucho hierro. El caso coreano lo demuestra con crudeza. Para no repetirlo: redundancia geográfica, copias inmutables off-site, segregación de accesos y DR drills periódicos. El resto es semántica.
Fuente: Noticias cloud y korea joongang daily
