Imagina que, de la noche a la mañana, se borran los archivos de trabajo de tres cuartos de millón de empleados públicos. No es un guion distópico: ocurrió en Corea del Sur. Un incendio en el National Information Resources Service (NIRS) de Daejeon destruyó el G-Drive gubernamental —un servicio “en la nube” donde 750.000 funcionarios guardaban su documentación desde 2018— y dañó 96 sistemas críticos. ¿La puntilla? No existían copias externas del G-Drive por la arquitectura elegida (almacenamiento de gran capacidad y bajo rendimiento sin réplica fuera del CPD), de modo que todo lo allí guardado se perdió para siempre. Algunas áreas podrían recuperar informes finales a través del sistema OnNara, pero el resto son horas de productividad volatilizadas.
Más allá del titular, el caso ilustra algo incómodo: a veces llamamos “cloud” a lo que no lo es. Una nube no es un único centro de datos con un gran “NAS”; es redundancia geográfica, automatización de réplicas, recuperación ante desastres y pruebas periódicas para que, si todo falla, no se lleve por delante la información.
¿Podría ocurrir en España?
En España existe el Esquema Nacional de Seguridad (ENS) —RD 311/2022— que, en su nivel Alto, obliga a disponer de un Plan de Recuperación ante Desastres (DRP) y a realizar copias de seguridad adecuadas (el clásico 3-2-1 como referencia mínima). En principio, las AAPP deberían estar certificadas en ENS, aunque la realidad es que no todas lo están y la implantación no siempre es homogénea. Como recordaba David Bonilla en redes, la legislación también obliga a reutilizar código público y, sin embargo, tenemos 17 sistemas de salud distintos; así que conviene mantener el escepticismo: norma no siempre significa cumplimiento efectivo.
Qué salió mal en Corea (y qué nos enseña)
- “Cloud” monolítico: G-Drive vivía en un solo CPD.
- Sin backups externos: el diseño de almacenamiento no permitía replicar fuera.
- Crítica sin aislamiento: 96 sistemas críticos afectados por el mismo incidente físico.
- Dependencia total: ministerios que obligaban a usar G-Drive como única vía quedaron más expuestos.
Lección: si un incendio (o inundación, fallo eléctrico, sabotaje, error humano) puede llevarse tu plataforma, entonces no tienes nube, tienes un CPD grande con marketing.
Buenas prácticas mínimas (para AAPP y empresas)
- Regla 3-2-1 (mejor 3-2-1-1-0):
3 copias, 2 medios distintos, 1 fuera de sitio; añade 1 copia inmutable/aislada (WORM, S3 Object Lock, cinta) y 0 errores verificados en restauras de prueba. - Redundancia geográfica “activa”: al menos dos ubicaciones en modo activo-activo o activo-pasivo conmutables; latencia y playbooks probados.
- Separación de dominios de fallo: energía, refrigeración, red, racks y proveedores diferentes cuando sea posible.
- Backups “fuera del plano”: no dependas del mismo dominio de identidad/monitoreo para acceder a copias; credenciales segregadas y MFA.
- Inmutabilidad y air-gap: políticas WORM y/o cintas o repositorios “sellados” que impidan cifrado por ransomware.
- RPO/RTO realistas: define cuánto puedes perder (RPO) y en cuánto debes volver (RTO). Documenta prioridades por servicio.
- Pruebas periódicas: simula desastres (mesa y técnicos), valida restauras y cronometra; sin ensayo, el plan es papel.
- Inventario y dependencia: ten claro dónde reside cada dato (SaaS incluido), quién lo protege y cómo se restaura.
- Governanza y auditoría: ENS, ISO 27001 (seguridad) y ISO 22301 (continuidad), registros de acceso, retenciones legales y data lifecycle.
- Diseño de almacenamiento: evita monolitos: usa objetos con versionado, replicación cruzada y borrado por etapas; para ficheros críticos, snapshots con retenciones largas.
“Cloud” de verdad: activo-activo + copias fuera
Comentario de David Carrero, cofundador de Stackscale (Grupo Aire), empresa de infraestructura cloud privado y bare-metal:
“La mejor póliza no es una, son varias: producción activo-activo en dos centros de datos distintos y, además, copias inmutables en un tercer emplazamiento. Así, si un sitio cae, conmutas; y si todo va mal, restauras de una copia que no ha podido ser alterada.”
“En Stackscale desplegamos entornos activo-activo (o activo-pasivo) geo-redundantes, y los complementamos con copias en otro CPD. Para backup inmutable o air-gap trabajamos con herramientas como Proxmox Backup Server o Veeam, que permiten retención WORM, verificaciones de restauración y alertas de anomalous behavior. La clave no es el software, es el diseño y probar las recuperaciones: sin test, no hay DRP.”
Traducido a un plano práctico, la receta combina:
- Producción que sobrevive a la caída de un sitio.
- Backups en un tercer dominio de fallo, inmutables y verificados.
- Runbooks de conmutación y restauración que se ensayan.
¿Y si mi “nube” es SaaS?
Sigue siendo tu responsabilidad saber cómo y dónde se respaldan tus datos. Pide por contrato:
- Ubicaciones y replicas (zonales/regionales).
- RPO/RTO del proveedor y tus objetivos.
- Exportabilidad periódica (para custodia propia).
- Derecho a probar restauraciones o evidencias de prueba.
- Capas de inmutabilidad y retención compatible con tus obligaciones.
Lista de verificación exprés (para no repetir Daejeon)
- Dos sedes mínimas para producción (activo-activo o conmutación probada).
- Backups en tercer emplazamiento, inmutables (WORM/air-gap).
- RPO/RTO definidos por servicio y ensayados.
- Restauras probadas trimestral o semestralmente (no sólo logs de “backup OK”).
- Segregación de identidades/credenciales de backup + MFA.
- Monitorización de anomalies (borrados masivos, cifrados, cambios de políticas).
- ENS/ISO al día y evidencias de auditoría.
- SaaS bajo control: export, retención e independencia del proveedor.
Conclusión
Corea nos recuerda la verdad incómoda: si tu “nube” cabe en un sólo edificio, no es nube, es un punto único de fallo con mucho hierro. En España tenemos marco legal (ENS) y buenas prácticas consolidadas (3-2-1-1-0), pero la diferencia la marca la ejecución: redundancia real, copias externas inmutables y pruebas de recuperación. No es glamour, es disciplina. Y es lo único que evita que, cuando arda el CPD —o simplemente falle—, se queme también nuestra memoria digital.
Preguntas frecuentes
¿Qué es exactamente la regla 3-2-1-1-0?
3 copias, 2 medios distintos, 1 fuera de sitio; 1 inmutable/aislada (WORM/air-gap); 0 errores verificados en restauras de prueba.
¿Activo-activo vs. activo-pasivo?
Activo-activo reparte carga y sobrevive al fallo inmediato; activo-pasivo conmutará, pero hay downtime. Tu RTO y presupuesto mandan.
¿Cada cuánto probar el DRP?
Al menos 1–2 veces al año y tras cambios relevantes (infra, versiones, datos). Cronometra y documenta.
¿Herramientas recomendadas para backup inmutable?
Soluciones como Proxmox Backup Server o Veeam permiten repositorios WORM, detección de anomalías, verificación de restauras y retenciones granulares. Lo esencial es su integración en un diseño multi-CPD y ensayos periódicos.
Fuente: Noticias cloud y korea joongang daily
