Recuperación de Moodle tras falla crítica de servidor

El problema

Durante un mantenimiento planeado de gestión de volúmenes lógicos (LVM), un comando incorrecto provocó una falla en el sector de arranque del servidor. El sistema de archivos no podía montarse, y varios reinicios del equipo técnico local agravaron el daño. La base de datos MariaDB, en una versión antigua compatible con CentOS, quedó parcialmente corrupta. El backup más reciente disponible tenía dos meses de antigüedad. 1.500 estudiantes quedaron sin acceso a la plataforma un viernes en la tarde.

Diagnóstico

El análisis de logs confirmó corrupción del sector de arranque LVM y filesystem no montable. La base de datos estaba parcialmente recuperable, y el código de recuperación de MariaDB estaba presente pero incompleto.

Proceso de recuperación

Fase 1 — Salvamento (4 horas)

Extracción del disco corrupto a un servidor de recuperación, uso de herramientas de recuperación de filesystem, dump parcial de la base de datos con recuperación de errores, y extracción de archivos de usuario con verificación de integridad. Resultado: 95% de tablas válidas recuperadas, 99% de archivos de usuario íntegros.

Fase 2 — Infraestructura nueva (2 horas)

Aprovisionamiento de un servidor nuevo en Ubuntu 20.04 LTS, instalación de Moodle 4.1 con PHP 8.1 y MariaDB 10.6 (versión moderna con mejor tolerancia a corrupción), configuración de Nginx con SSL y backup remoto automático.

Fase 3 — Migración de datos (8 horas)

Importación de la base de datos recuperada con validación tabla por tabla, migración de archivos de usuario mediante transferencia segura, y reconstrucción de registros de finalización de cursos a partir del historial de logs disponible.

Fase 4 — Testing e integración (6 horas)

Pruebas de acceso con usuarios reales, validación de funcionalidades docentes, comparación cuantitativa de usuarios y registros de actividad recuperados, y pruebas de carga simulando 500 usuarios concurrentes con tiempos de respuesta estables por debajo de 200ms.

Fase 5 — Despliegue en producción (2 horas)

Migración de DNS, comunicación a usuarios y soporte intensivo en vivo durante las primeras horas posteriores al restablecimiento del servicio.