Es una situación más común de lo que parece: se lanza la actualización de Moodle, algo se corta a mitad de camino y al día siguiente nadie puede entrar. A veces aparece un mensaje de error crítico, otras una pantalla en blanco. Y muchas veces el primer intento de arreglo, restaurar un respaldo, no resuelve nada. Esta guía explica cómo pensar el problema para no empeorarlo.
Primero: dejá de probar cosas sobre el sitio real
Cada restauración, cada archivo copiado encima y cada intento de volver a ejecutar la actualización modifica el estado de la plataforma. Antes de seguir, hacé una copia de los tres elementos que importan: los archivos del código, la base de datos y la carpeta de datos (moodledata). Con esas tres copias a salvo, cualquier prueba posterior se puede hacer sin riesgo.
Por qué una actualización deja el sitio roto
- Requisitos del servidor: una versión de PHP o de base de datos que no cumple lo que pide la versión nueva, o una extensión de PHP que falta.
- Archivos del núcleo incompletos o mezclados: parte del código es de la versión vieja y parte de la nueva, por una copia interrumpida o por pisar carpetas.
- Plugins incompatibles: un plugin de terceros que no soporta la versión nueva puede impedir que el sitio arranque.
- Límites del servidor: memoria o tiempo de ejecución insuficientes para completar la actualización de la base de datos.
- Estructura de carpetas: desde Moodle 5.1, el servidor web debe apuntar a la carpeta
/public/. Si no se ajustó la configuración, el sitio no carga.
Un error crítico del núcleo suele ser compatible con una actualización que no llegó a completarse: archivos ausentes o incompatibles entre sí. Pero conviene confirmarlo mirando los registros, no suponerlo.
Por qué restaurar el respaldo no siempre alcanza
Moodle compara la versión del código con la versión que está registrada en la base de datos. Si se restaura solo uno de los dos, o si el respaldo es de un momento distinto al de los archivos actuales, queda un desfase y el sitio sigue sin arrancar. Tampoco ayuda restaurar sobre una instalación que ya tiene archivos de otra versión.
Por eso la recuperación se hace mejor en un entorno aparte: se arma una copia, se recupera ahí el núcleo, se verifica que la base de datos y los archivos coincidan y se prueba el acceso antes de tocar nada en producción.
Lista de verificación antes de pedir ayuda
- Anotá la versión de origen y la de destino.
- Guardá el mensaje de error exacto y una captura.
- Revisá los registros de errores de PHP y del servidor web.
- Anotá qué restauraciones o cambios ya se intentaron.
- Hacé una copia de archivos, base de datos y moodledata antes de seguir.
Cómo se recupera sin perder datos
- Preservar la instalación original y trabajar siempre sobre copias.
- Recuperar el núcleo y restablecer el acceso en un entorno de pruebas.
- Verificar la base de datos y su correspondencia con la carpeta moodledata.
- Revisar los plugins y su compatibilidad con la versión recuperada.
- Probar acceso, cursos, usuarios, matrículas, roles y materiales.
- Pasar a producción con respaldo previo y un plan para volver atrás.
Es el procedimiento que seguimos en la recuperación de la plataforma de una asociación profesional de Argentina, que quedó inaccesible al intentar actualizar a Moodle 5.3. Podés ver el caso en nuestra página de Moodle Argentina.
Cómo evitar que te pase
Antes de actualizar, comprobá los requisitos de la versión nueva, hacé un respaldo completo y probá todo en una copia del sitio. Si querés revisar los requisitos de las versiones recientes, tenemos las guías de Moodle 5.2 y de Moodle 5.3. Y si preferís que lo hagamos nosotros, mirá nuestro servicio de Moodle y la guía de mantenimiento de Moodle.