Respaldos

El respaldo de la Academia lo hace el servidor, no Moodle: todos los días guarda la base de datos y los archivos subidos en un solo archivo verificado, y le avisa a Moodle cómo salió. Los scripts están en infrastructure/scripts/ y viajan dentro de la imagen de Moodle en /opt/delta-lms.

Qué hay que protegerCopy Anchor Link

Si se pierden los volúmenes mariadb_data y moodledata, se pierde la información aunque el código esté en GitHub. Por eso el respaldo cubre exactamente esos dos.

Estado del plan de respaldoCopy Anchor Link

Objetivo: perder como máximo un día de datos (RPO 24 h) y volver a estar en línea en unas 2 horas (RTO), contando la construcción de la imagen.

Formato del respaldoCopy Anchor Link

delta-lms_backup_2026-09-28_024132.tar         ← archivo único
delta-lms_backup_2026-09-28_024132.tar.sha256  ← checksum (restore.sh lo exige)
  └─ delta-lms_backup_.../
       database.sql.gz     mariadb-dump --single-transaction --routines --triggers (utf8mb4)
       moodledata.tar.gz   sin cache/ localcache/ sessions/ temp/ trashdir/ (Moodle los regenera)
       manifest.txt        fecha, versión de Moodle, wwwroot, collation, nº de tablas y archivos
       SHA256SUMS          checksums de los archivos internos
       env.backup          solo con --with-env

El manifiesto guarda, entre otros: fecha, servidor, proyecto de Compose, contenedores, nombre y cotejamiento de la base, número de tablas, versión de Moodle, dirección de origen (source_wwwroot), número de entradas de moodledata, si se usó el modo de mantenimiento y si incluye las variables.

Activar el respaldo diarioCopy Anchor Link

El repositorio es privado, así que los scripts no se clonan en el servidor: viajan dentro de la imagen de Moodle (/opt/delta-lms) y se copian al servidor desde el contenedor. Requiere haber hecho un Redeploy con una versión que los incluya.

C=$(docker ps --filter label=com.docker.compose.service=moodle --format '{{.Names}}' | head -n1); mkdir -p /opt/delta-lms && docker cp "$C":/opt/delta-lms/. /opt/delta-lms/ && bash /opt/delta-lms/infrastructure/scripts/setup-backup.sh

Para actualizar los scripts después de otro Redeploy, se vuelve a ejecutar la misma línea. Volver a ejecutar setup-backup.sh también actualiza la configuración.

Qué deja instalado setup-backup.shCopy Anchor Link

Si el servicio cron del servidor no está activo, el script lo avisa:

systemctl enable --now cron

Opciones de setup-backup.shCopy Anchor Link

La hora: Ecuador frente a UTCCopy Anchor Link

El servidor está en UTC. setup-backup.sh recibe la hora en hora de Ecuador (UTC-5, sin horario de verano) y la convierte sola a la hora del reloj del servidor, sea cual sea su zona. Con el valor por defecto, 2:00 de Ecuador queda como 7:00 UTC (0 7 * * * en /etc/cron.d/delta-lms-backup).

Qué hace el respaldo diarioCopy Anchor Link

backup-daily.sh (lo ejecuta el cron del servidor):

1. Ejecuta backup.sh: base de datos + moodledata en un .tar con su .sha256, y conserva los últimos BACKUP_KEEP en el servidor.
2. Verifica el sha256 del archivo nuevo.
3. Si RCLONE_REMOTE está configurado, copia el respaldo fuera del servidor y borra allá las copias de más de OFFSITE_KEEP_DAYS días. Si no, registra el aviso "sin copia externa".
4. Le avisa a Moodle cómo salió con local/deltamodules/cli/backup_status.php. Si falló, Moodle envía un correo a los super administradores y al correo de soporte, y el super administrador ve el aviso en su Área personal.

Una ejecución correcta termina en el registro con === Respaldo diario: correcto (<archivo>, <bytes> bytes) ===.

backup.sh paso a pasoCopy Anchor Link

Si un archivo cambia mientras se copia moodledata (el sitio está en uso), solo sale un aviso: la base sigue siendo consistente.

Respaldo manualCopy Anchor Link

infrastructure/scripts/backup.sh                         # → <repo>/backups (en .gitignore)
infrastructure/scripts/backup.sh /var/backups/delta-lms  # otro destino
infrastructure/scripts/backup.sh --keep 30               # retención (defecto 14; 0 = no borrar)
infrastructure/scripts/backup.sh --maintenance           # modo mantenimiento durante la copia

En el servidor, con los scripts ya copiados:

/opt/delta-lms/infrastructure/scripts/backup.sh /var/backups/delta-lms

Códigos de salidaCopy Anchor Link

La página Respaldos de la AcademiaCopy Anchor Link

En Moodle: Administración del sitio → Cursos → Copias de seguridad → Respaldos de la Academia. Es de solo lectura y muestra:

Copia fuera del servidorCopy Anchor Link

Si el servidor (o el nodo Proxmox) se daña, los respaldos guardados en él se pierden con él. La copia externa está programada en el script pero falta elegir y configurar el destino.

La copia va cifrada con un remoto crypt de rclone. La clave de cifrado se guarda en el gestor de contraseñas: sin ella, la copia no se puede abrir.

Configurar la copia en Cloudflare R2Copy Anchor Link

rclone config create r2 s3 provider=Cloudflare access_key_id=<ID> secret_access_key=<CLAVE> \
    endpoint=https://<ID_DE_CUENTA>.r2.cloudflarestorage.com
rclone config create r2crypt crypt remote=r2:delta-lms-backups password=<CLAVE_DE_CIFRADO> --obscure

bash /opt/delta-lms/infrastructure/scripts/setup-backup.sh --remote r2crypt:

Para traer una copia externa al servidor:

rclone copy r2crypt:<archivo>.tar . && rclone copy r2crypt:<archivo>.tar.sha256 .

Respaldo manual en Coolify sin setup-backup.shCopy Anchor Link

La forma recomendada es setup-backup.sh. A mano, sin .env (las credenciales se leen de los contenedores):

C=$(docker ps --filter label=com.docker.compose.service=moodle --format '{{.Names}}' | head -n1)
sudo mkdir -p /opt/delta-lms && sudo docker cp "$C":/opt/delta-lms/. /opt/delta-lms/
sudo mkdir -p /var/backups/delta-lms
sudo crontab -e
# 0 2 * * * /opt/delta-lms/infrastructure/scripts/backup.sh /var/backups/delta-lms >> /var/log/delta-lms-backup.log 2>&1

Coolify puede renombrar contenedores y volúmenes (por ejemplo moodle-<uuid> o <uuid>_moodledata). Los scripts los encuentran por etiqueta y por los montajes del contenedor, así que no hay que configurar nombres. Si hay más de un despliegue en el mismo servidor, defina COMPOSE_PROJECT_NAME=<uuid>.

Probar un respaldo sin tocar la base en usoCopy Anchor Link

Para comprobar que un archivo se puede cargar, sin tocar la instalación en uso, se carga en una base MariaDB temporal:

F=backups/delta-lms_backup_X.tar; N=$(basename "$F" .tar)
export MARIADB_ROOT_PASSWORD=$(openssl rand -hex 16) MYSQL_PWD=$MARIADB_ROOT_PASSWORD
docker run -d --name bk-test-db -e MARIADB_ROOT_PASSWORD mariadb:11.4
# esperar ~20 s
docker exec -e MYSQL_PWD bk-test-db mariadb -uroot -e "CREATE DATABASE t CHARACTER SET utf8mb4"
tar -xOf "$F" "$N/database.sql.gz" | gzip -dc | docker exec -i -e MYSQL_PWD bk-test-db mariadb -uroot t
docker exec -e MYSQL_PWD bk-test-db mariadb -uroot -N -e "SELECT COUNT(*) FROM information_schema.tables WHERE table_schema='t'; SELECT COUNT(*) FROM t.mdl_user"
docker rm -f bk-test-db

La prueba completa (restaurar todo en una instalación aparte) está en Recuperación y los resultados de las pruebas hechas, en Registro de pruebas.