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 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:
- Diseño: un servicio central sin redundancia geográfica ni copia inmutable.
- Gobernanza: políticas que obligan a usar G-Drive, pero no exigen respaldo equivalente.
- Operación: frecuencias de backup dispares y ventanas mensuales en sistemas con información dinámica.
- Gestión de riesgo: ausencia de pruebas de recuperación periódicas (no “existe” backup hasta que se restaura).
- 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 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.
