Rollback

Si la verificación falla, revertir el despliegue. Usa las variables del runbook.

1. Restaurar la base de datos

Restaurar el dump tomado en el Paso 1 del procedimiento:

ssh -i "$KEY" "$HOST" 'docker exec -i '"$DB"' sh -c \
  "exec mariadb -uroot -p\$MYSQL_ROOT_PASSWORD moodle" \
  < ./moodle_dump_<TIMESTAMP>.sql'

Restaurar siempre un dump tomado en este mismo $HOST. Nunca un dump traído de otro ambiente — ver qué NO incluye la entrega.

2. Revertir el código

Volver a copiar los dos componentes desde el checkout previo (o git checkout de la versión anterior en el árbol del docroot) y re-aplicar el propietario:

for d in local/pccntr8203403_dashboard theme/cdigital; do
  rsync -az --delete -e "ssh -i $KEY" "$SRC_PREVIO/$d/" "$HOST:$DST/$d/"
done
ssh -i "$KEY" "$HOST" 'chown -R '"$OWNER"' \
  '"$DST"'/local/pccntr8203403_dashboard '"$DST"'/theme/cdigital'

3. Purgar cachés

ssh -i "$KEY" "$HOST" 'docker exec '"$WEB"' php /var/www/admin/cli/purge_caches.php'

4. Re-verificar

Repetir la verificación post-despliegue sobre el estado restaurado.

Nota operativa

El host de Pruebas comparte CPU con otra aplicación; bajo carga alta del co-tenant el proxy puede devolver 504 aunque Moodle esté sano. Antes de declarar un fallo de despliegue, confirmar que no se trata de saturación temporal del proxy.