--- title: "Corea del Sur aprende por las malas la importancia de las copias de seguridad: un incendio arrasa 858 TB sin respaldo en el G-Drive gubernamental" description: "Un incendio de baterías en el National Information Resources Service (NIRS) de Daejeon el 26 de septiembre ha provocado una de las pérdidas de datos más graves registradas en una administración modern..." url: https://revistacloud.com/corea-del-sur-aprende-malas-importancia-copias-de-seguridad-un-incendio-arrasa-858-tb-sin-respaldo-g-drive-gubernamental/ date: 2025-10-14 modified: 2025-10-11 author: "Silvia A. Feliz" image: https://revistacloud.com/wp-content/uploads/2025/10/nirs-corea-soporte-almacenamiento-quemado.jpg categories: ["Análisis y opinión", "Noticias", "Seguridad"] tags: ["Corea", "datos", "g-drive", "incendio"] type: post lang: es --- # Corea del Sur aprende por las malas la importancia de las copias de seguridad: un incendio arrasa 858 TB sin respaldo en el G-Drive gubernamental Un [incendio de baterías en el **National Information Resources Service (NIRS)**](https://revistacloud.com/corea-pierde-su-nube-gubernamental-tras-un-incendio-sin-copias-de-seguridad-ni-plan-de-recuperacion/) de Daejeon el **26 de septiembre** ha provocado una de las pérdidas de datos más graves registradas en una administración moderna: **858 TB** de información del **G-Drive** —el “disco online” para funcionarios— quedaron **completamente destruidos** y **sin copia de seguridad**. La avería tumbó **96 sistemas** gubernamentales; **95 contaban con respaldo**. El único que no, G-Drive, concentraba material de trabajo de **125.000 empleados públicos** de **74 ministerios**, con un uso estimado del **17 %** del funcionariado central. El foco del incendio estuvo en una sala con **384 paquetes de baterías**, que arrasó gran parte de una planta y dejó fuera de servicio servicios críticos: **correo oficial**, **oficina postal en línea**, **webs ministeriales**, el sistema de **quejas y peticiones** e incluso afectó al **119** (emergencias), según el balance inicial. A **seis días** del siniestro, solo el **16–18 %** de los **647** sistemas alojados en la sede había sido restablecido; el G-Drive seguía irrecuperable por la **ausencia total de backups**. ## Un “disco del Gobierno” sin plan B Creado en **2017** para compartir documentos (con **30 GB** por usuario) y mejorar la seguridad, el **G-Drive** sustituyó progresivamente el almacenamiento local: una **directriz del Ministerio del Interior y Seguridad** instó a **no guardar** material de trabajo en los PC de oficina y **centralizarlo** en esa plataforma. La paradoja es brutal: **el sistema recomendado** para custodiar la documentación **carecía de respaldo**. Una fuente del ministerio llegó a justificar que “**no podía tener copia por su gran capacidad**”. En escala de CPD, **858 TB** no es excepcional: hoy se manejan **petabytes** rutinariamente con replicación y snapshots. Las consecuencias son profundas en áreas como **Gestión de Personal** —usuaria intensiva de G-Drive—: **ocho años** de materiales podrían haberse perdido, incluidos **actas internas, documentación para la Asamblea Nacional** y, potencialmente, **datos personales** (verificaciones, expedientes disciplinarios). Aunque sistemas transaccionales como **e-Person** se alojan en otra sede (Gwangju), **no hay censo exacto** de lo destruido: equipos rastrean PCs, correos y registros físicos para reconstruir lo mínimo operativo. La **Auditoría de la Asamblea** de este mes podría verse comprometida por **incapacidad de remitir** documentación solicitada. ## Copias sí… pero no siempre, ni al día El NIRS informó de que, antes del incendio, **62 %** de los **647 sistemas** se **respaldaban a diario**, mientras que el **38 %** restante lo hacía **mensualmente**. En algunos casos, el **último backup** era del **31 de agosto**, lo que supone la pérdida de **todo septiembre** para esos servicios. Peor aún, el **depósito de almacenamiento** adyacente a la sala siniestrada —donde residían repositorios esenciales para reiniciar— quedó **inaccesible por polvo y ceniza**, frenando la recuperación. El plan oficial es **migrar** los **96 sistemas calcinados** a la sede de **Daegu**; se habló de **cuatro semanas**, pero expertos anticipan **más demora**. ## “Demasiado grande para copiar”: una falsa economía El argumento de la **capacidad** como obstáculo para copiar es **técnicamente insostenible** en 2025. Estrategias sólidas y **probadas** para datos a gran escala incluyen: - **Regla 3-2-1** (tres copias, dos medios, una *off-site*), hoy extendida a **3-2-1-1-0** (una copia inmutable y **cero** errores verificados). - **Versionado y snapshots** frecuentes a nivel de **sistema de archivos** o **almacenamiento** (ZFS, Ceph, soluciones de *object storage* con *object lock*). - **Replicación síncrona/activa-activa** entre **dos CPD** para RPO/RTO cercanos a **0**, complementada con **backups diferidos** en un **tercer sitio** (protege frente a corrupción lógica o ransomware). - **Segmentación por criticidad** y **SLA**: no todos los repositorios necesitan el mismo RPO, pero **ninguno** debe permanecer **sin plan de respaldo**. Con **tiering** de almacenamiento, **deduplicación** y **compresión**, respaldar **centenares de terabytes** ya no es un reto prohibitivo. Lo que sí resulta prohibitivo es **reconstruir ocho años de trabajo**. ## Fallos encadenados: técnica, gobernanza y cultura Lo ocurrido no es solo un accidente eléctrico: revela **brechas sistémicas**: 1. **Diseño**: un servicio **central** sin **redundancia geográfica** ni **copia inmutable**. 2. **Gobernanza**: políticas que **obligan** a usar G-Drive, pero **no exigen** respaldo equivalente. 3. **Operación**: **frecuencias de backup** dispares y ventanas mensuales en sistemas con información dinámica. 4. **Gestión de riesgo**: ausencia de **pruebas de recuperación** periódicas (no “existe” backup hasta que se **restaura**). 5. **Resiliencia física**: co-ubicación de **baterías**, **almacenamiento** y **red** que amplificó el daño. ## Impacto humano y responsabilidades Aunque el incendio **no causó víctimas** directas, un **funcionario implicado en la recuperación** se **suicidó** el **3 de octubre** en Sejong, un recordatorio trágico de la **carga humana** que acompaña a los desastres tecnológicos. Hay **cuatro detenidos** por **negligencia criminal** presunta. A nivel político, la oposición cuestiona la **falta de manuales y auditorías** y exige rendición de cuentas. ## Qué debería cambiar desde hoy - **Mapeo y clasificación** de datos (quién guarda qué, dónde y con qué RPO/RTO). - **Backups inmutables** (WORM / *object lock*) y **retenciones escalonadas** (diarias, semanales, mensuales) con **ensayos de restauración** documentados. - **Doble CPD activo-activo** para plataformas troncales y **tercer sitio** para copias; **separación física** de energía/almacenamiento. - **Telemetrías de integridad** (verificación por bloques, *scrubbing*) y **monitorización de cumplimiento** con alertas ejecutivas. - **Plan de crisis**: runbooks, contactos, *table-top exercises* y pruebas de conmutación **trimestrales**. - **Cultura**: métricas de **resiliencia** (no solo uptime), con **presupuesto protegido** para continuidad de negocio. ## Lecciones para cualquier organización - Si un dato **solo existe en un lugar**, **no existe**. - **RPO = ∞** y **RTO impredecible** son consecuencias inevitables de **no copiar**. - Los incendios de baterías y fallos simultáneos de energía/almacenamiento **sí ocurren**; la pregunta es **cuándo** y **qué quedará en pie**. - La **simplicidad operativa** (versionado + replicación + copia inmutable) **vence** a la perfección teórica que nunca se implementa. --- ### Preguntas frecuentes **¿Por qué 858 TB “no cabían” en un plan de copias?** Con tecnologías actuales (deduplicación, compresión, *object storage*, cintas LTO-9/10 y nubes soberanas) **sí caben**. El problema no era técnico, sino de **priorización y diseño**. **¿Basta con replicar a otro centros de datos?** No. La **replicación** protege de fallos físicos; la **[copia inmutable](https://revistacloud.com/copia-de-seguridad-inmutable/)** protege de **borrados**, **corrupción** y **ransomware**. Se necesitan **ambas**. **¿Cada cuánto hay que probar una restauración?** Como mínimo **trimestral** en sistemas críticos y **mensual** para conjuntos representativos. Sin **ensayo de recuperación**, el backup es una **suposición**. **¿Qué RPO/RTO son razonables para un “Drive” gubernamental?** Para un repositorio de trabajo transversal, **RPO ≤ 24 h** con **snapshots horarios** y **RTO por fases** (lectura básica en horas, escritura plena en < 48 h) son metas alcanzables con arquitectura adecuada. --- **Nota**: Los datos y cronología citados corresponden a los informes oficiales y a la cobertura local tras el incendio del 26 de septiembre en el NIRS de Daejeon, incluyendo estimaciones de sistemas afectados, volúmenes y porcentajes de recuperación publicados en los días posteriores. vía: [chosun](https://www.chosun.com/english/national-en/2025/10/02/FPWGFSXMLNCFPIEGWKZF3BOQ3M/) y [donga](https://www.donga.com/en/article/all/20251004/5885938/1)