Registro de pruebas
Pruebas de respaldo y recuperación realizadas en la Academia Deltamontero, con sus resultados, tiempos y hallazgos.
Registro de las pruebas hechas a los scripts de respaldo y recuperación. Cada prueba nueva (por ejemplo, la recuperación con un respaldo real de producción) debe agregarse aquí con su fecha, lo que se hizo, los resultados y los hallazgos.
Resumen
| Fecha | Prueba | Resultado |
|---|---|---|
| 2026-10-06 | Prueba completa en local: repositorio + respaldo → Academia nueva | Correcta. Datos idénticos; unos 13 minutos desde cero. Un hallazgo corregido |
| 2026-10-06 | Respaldo diario y avisos (local) | Correcta. Se corrigió la lectura de la configuración con espacios en la ruta |
| 2026-10-06 | Activación en producción | Correcta. Hallazgo: reloj del servidor adelantado y sin sincronizar |
2026-10-06: prueba completa en local (repositorio + respaldo → Academia nueva)
Respaldo
Con backup.sh: 549 tablas, 10 384 archivos de moodledata, 19 MB, 38 segundos. Sumas de verificación del archivo y de su contenido: correctas.
Imagen
Construida desde el repositorio actual (docker compose build moodle): 11 minutos, sin errores (incluye la verificación de parches).
Restauración en una instalación nueva
Con restore.sh en un proyecto nuevo y vacío (drtest), con contraseñas nuevas y otra dirección (localhost:8081), como un servidor nuevo sin Coolify: 1 minuto 50 segundos.
Verificación
- Conteos idénticos al original: 39 usuarios, 14 módulos, 326 actividades, 248 matrículas, 42 avances, 10 intentos de repasos, 15 calificaciones y 4 810 archivos.
- Se leyeron 300 archivos y todos estaban completos.
- La web respondió: ingreso y portada con 200; las páginas internas piden iniciar sesión.
- La configuración automática del despliegue terminó con 0 errores, con la versión actual del plugin.
- Los tres contenedores quedaron sanos.
Restauración sobre el sistema en uso
En el mismo servidor: 2 minutos 25 segundos, datos idénticos.
Hallazgo corregido: al pedir un proyecto aparte, restore.sh tomaba los contenedores de otro proyecto que estaba corriendo (el de uso) y restauraba sobre él. Ahora respeta el proyecto indicado (regla de COMPOSE_PROJECT_NAME, ver Recuperación).
Tiempo total desde cero: unos 13 minutos (imagen 11 minutos + restauración 2 minutos), más el cambio de DNS.
2026-10-06: respaldo diario y avisos (local)
| Caso | Resultado |
|---|---|
backup-daily.sh normal | Correcto: respaldo de 19 MB verificado y registrado en Moodle. Aviso al super administrador: "Los respaldos se guardan solo en el mismo servidor..." (no hay copia externa configurada) |
backup-daily.sh con falla forzada (contenedor de base inexistente) | Fallo registrado en Moodle, intento de correo (en local no hay servidor de correo; en producción sí) y aviso "El último respaldo automático falló..." |
| Configuración en una carpeta con espacios | Se corrigió la lectura de la configuración cuando la ruta tiene espacios |
No se probó en esta ocasión:
- La copia con rclone (no había rclone en el equipo de pruebas).
setup-backup.sh(necesita un servidor Linux conroot): se probó al ejecutarlo en el servidor (prueba siguiente).
2026-10-06: activación en producción
setup-backup.shen el servidor (Coolify → Terminal → localhost): primer respaldo correcto (549 tablas, 10 342 archivos demoodledata, 23 MB), verificado y registrado en Moodle. El servicio cron está activo.- El servidor está en UTC: la tarea quedó a las 7:00 UTC = 2:00 de Ecuador (
0 7 * * *). Desde esta versión el script convierte la hora solo.
Hallazgo: el reloj del servidor está unos 16 minutos adelantado y sin sincronizar (NTP service: inactive). Es un contenedor de Proxmox: se corrige en el nodo (TI). Afecta a los códigos MFA de los administradores y a los registros.
Pendiente de probar
-
Comprobar el primer respaldo automático:
tail /var/log/delta-lms-backup.log -
Configurar la copia externa y comprobar que se sube y se puede traer de vuelta (ver Respaldos).
-
Repetir la prueba de recuperación con un respaldo real de producción, en otro equipo o en el contenedor nuevo (12030,
192.168.0.191), sin correo o con desvío (ver Recuperación).
Plantilla para nuevas pruebas
| Campo | Qué anotar |
|---|---|
| Fecha y responsable (por rol) | Cuándo y quién la hizo |
| Origen | Archivo de respaldo usado, tamaño, fecha del respaldo |
| Destino | Equipo o servidor, con o sin Coolify, proyecto (COMPOSE_PROJECT_NAME), dirección |
| Tiempos | Construcción de la imagen, restauración, cambio de DNS |
| Verificación | Conteos (usuarios, módulos, matrículas, archivos), ingreso, un módulo, un archivo, un certificado, errores de despliegue, estado de los contenedores, correo |
| Hallazgos | Qué falló y cómo se corrigió |
Recuperación (DRP)
Procedimiento paso a paso para volver a levantar la Academia Deltamontero a partir del repositorio y un respaldo. Requisitos y vacíos actuales, mismo servidor, servidor nuevo con o sin Coolify, verificación, volver atrás, correo SMTP y mudanza al contenedor nuevo.
Monitoreo y avisos
Controles de salud de los contenedores, avisos al super administrador dentro de Moodle, correo de fallo de respaldo y dónde están los registros.