(y qué aprendí de un soporte técnico que no ayudó)
Recuperar Moodle puede convertirse en un verdadero desafío cuando una plataforma deja de funcionar y el soporte técnico no ofrece una solución efectiva. En mi caso, mi instalación de Moodle, alojada en Hostinger, dejó de responder hace unas semanras, lo que me obligó a investigar el origen del problema, reconstruir el entorno local y realizar las pruebas necesarias para recuperar Moodle, recuperar toda mi plataforma de aprendizaje. Esta experiencia también me permitió documentar las dificultades que encontré al solicitar asistencia técnica: desde las respuestas automatizadas por inteligencia artificial hasta la intervención súper mega tardía del personal humano.
Reporté el problema al ¿soporte técnico de Hostinger? y comenzó un ciclo de semanas: respuestas genéricas, listas de comprobaciones para que yo mismo hiciera el diagnóstico y, finalmente, la conclusión de que la caída se debía al consumo de recursos y que, por tal razón, me correspondía resolverlo.
Me dedico profesionalmente al mantenimiento y la recuperación de Moodle, así que la ayuda que necesitaba no era por falta de capacidad, sino por tiempo y por principio: pago por un servicio de hosting (y lo sigo pagando), y lo razonable es que quien lo presta resuelva los problemas de su propia infraestructura. Como eso no ocurrió, lo hice yo: primero reinstalé Moodle en local y después lo migré de vuelta al servidor. Me tomó semanas en tiempo de calendario, la mayoría esperando una ayuda que no llegó, pero el trabajo real fueron unas cuantas horas, el sábado 19 de septiembre. Este artículo es la guía que me habría gustado tener desde el primer día.
1. Antes de tocar nada: tener en cuenta qué componentes tiene Moodle
Una instalación de Moodle son tres piezas independientes y fundamentales. Recuperarla exige saber dónde está cada una:
- El código: los archivos de Moodle dentro de tu hosting.
- La base de datos: donde viven cursos, usuarios, calificaciones y configuración.
- El directorio moodledata: archivos subidos, caché, sesiones y copias de seguridad de cursos. Idealmente está fuera del directorio público.
Si tienes las tres, puedes reconstruir tu sitio casi en cualquier lugar. Si te falta una, la recuperación se complica mucho.
2. Diagnóstico seguro, sin cambios destructivos
Estas son las comprobaciones que me sugirió el soporte. Son razonables como punto de partida, pero no reemplazan una revisión hecha por quien administra el servidor:
- Revisar los archivos de Moodle en busca de archivos faltantes o dañados. Compara con una copia limpia de la misma versión.
- Consultar el registro de errores (PHP, base de datos, memoria, permisos). En el panel de hosting suele estar en la sección de logs.
- Verificar la conexión con la base de datos y revisar config.php sin editarlo todavía: usuario, contraseña, nombre de la base de datos y wwwroot.
- No restaurar ni sobrescribir nada mientras investigas. Si vas a restaurar, hazlo desde una copia conocida como válida.
Para ver el error real, puedes activar temporalmente la depuración en config.php, antes de la línea require_once(__DIR__ . ‘/lib/setup.php’);:
php
@error_reporting(E_ALL | E_STRICT);
@ini_set(‘display_errors’, ‘1’);
$CFG->debug = (E_ALL | E_STRICT);
$CFG->debugdisplay = 1;
Es de vital importancia quitarlo después del diagnóstico: no debe quedar activo en producción.
3. Las causas más comunes de una caída
- Límites de recursos del hosting: CPU, memoria RAM, número de procesos, entradas simultáneas o E/S de disco. En planes compartidos es una causa muy frecuente.
- Versión de PHP incompatible tras una actualización automática del servidor.
- Permisos incorrectos en moodledata o en el código.
- Base de datos inaccesible o dañada, o cambios en las credenciales.
- Caché corrupta o sesiones acumuladas.
- Cron mal configurado, que ejecuta tareas pesadas de forma constante.
- Tráfico no deseado: bots, rastreadores o intentos de acceso por fuerza bruta a la página de login. Sucede aunque tú no uses el sitio.
- Mantenimiento o incidencias del proveedor, siempre que afecten al servidor donde realmente está tu cuenta (más abajo explico por qué esto importa).
Que tú no uses Moodle no significa que nadie lo esté consultando, y un sitio «inactivo» puede consumir muchos recursos sin que lo notes.
4. Pasos de recuperación
Paso 1. Respalda todo antes de restaurar Moodle desde una copia de seguridad
Escritura
Antes de realizar cualquier cambio, descarga el código de Moodle, exporta la base de datos y copia el directorio moodledata. Si cuentas con una copia de seguridad válida, podrás restaurar Moodle desde una copia de seguridad y recuperar los datos necesarios para reconstruir tu plataforma. Aunque el sitio no cargue, es posible que estos componentes sigan intactos.
Paso 2. Activa el modo mantenimiento
Obviamente, si el sitio responde parcialmente:
bash
php admin/cli/maintenance.php –enable
Paso 3. Purga las cachés:
bash
php admin/cli/purge_caches.php
Paso 4. Revisa permisos
Como referencia general, carpetas en 755 y archivos en 644, con moodledata escribible por el usuario del servidor web.
Paso 5. Verifica la compatibilidad de PHP
Cada versión de Moodle exige un rango de versiones de PHP. Confirma en la documentación oficial que la tuya sigue siendo compatible.
Paso 6. Si nada funciona, reconstruye en local
Fue lo que hice:
- Instala un entorno local (XAMPP, Laragon o Docker).
- Descarga la misma versión de Moodle que tenías.
- Importa tu base de datos y copia tu moodledata.
- Ajusta config.php (base de datos, wwwroot y dataroot).
- Verifica que todo funciona antes de subir nada al servidor.
Paso 7. Migra de vuelta al servidor
Una vez comprobado que Moodle funciona correctamente en el entorno local, puedes migrar Moodle a otro servidor o devolverlo al alojamiento original. Para ello, sube el código, importa la base de datos, copia moodledata, actualiza los parámetros de config.php y purga las cachés. Finalmente, verifica que la plataforma cargue correctamente y que los cursos, usuarios y archivos estén disponibles.
Buena parte de este último paso no la hice desde el administrador de archivos del panel de hosting, sino por consola SSH. Subir el código, ajustar permisos, ejecutar la purga de cachés y validar la conexión con la base de datos es mucho más rápido y preciso así, aunque exige sentirse cómodo trabajando por línea de comandos y tener claro qué se está ejecutando en un servidor de producción, sin margen para el ensayo y error.
5. Cuándo conviene pedir ayuda
Todo lo anterior se puede hacer por cuenta propia, pero no siempre conviene. Si no sabes exactamente en qué estado está tu base de datos, si no tienes respaldo de moodledata, si hay un curso en marcha o si simplemente no puedes permitirte semanas de prueba y error, lo más rentable es que alguien con experiencia lo haga por ti. Yo recuperé mi propio sitio en unas cuantas horas. Si tu Moodle está caído y necesitas que lo revise o lo migre, escríbeme a ismael.o.r@gmail.com. También puedes escribir a info@blog.ismael-ochoa.com, y lo vemos. En mi sitio oficial, https://ismael-ochoa.com, en la parte baja, hay un formulario de contacto mediante el cual puedes compartir tus datos. Contestaré dentro de las primeras veinticuatro horas posteriores a la recepción de tu correo.
6. Mi experiencia con la atención al cliente de Hostinger: primero una IA, mucho después una persona
Mi experiencia con la atención al cliente de Hostinger fue bastante frustrante. El proceso comenzaba con una inteligencia artificial que proporcionaba listas de comprobaciones genéricas, sin resolver el problema. Solo después de cientos de mensajes conseguí que interviniera un agente humano, quien tampoco logró ofrecerme una solución.
El soporte técnico mediante IA puede ser útil para resolver consultas sencillas, orientar al usuario y proporcionar instrucciones iniciales. Sin embargo, en mi caso, la automatización terminó convirtiéndose en una sucesión de diagnósticos y comprobaciones que tuve que realizar por mi cuenta, sin que se resolviera el problema de fondo. La intervención humana llegó después de una larga conversación y tampoco produjo una solución.
Además, el asistente me señaló una ventana de mantenimiento programado en el servidor IN-921, del 8 de septiembre a las 21:00 UTC al 9 de septiembre a las 00:00 UTC. Me dijo que ya había terminado, pero que mi Moodle podía seguir afectado por una incidencia intermitente, y me pidió no hacer cambios mientras esperaba unas comprobaciones automáticas entre 1 y 10 minutos.
Más tarde, semanas después, para ser claros, me indicaron que ese mantenimiento fue en servidores en India y que mis archivos están en servidores de Estados Unidos, por lo que era imposible que me hubiera afectado. La primera pista que me dieron no tenía relación con mi caso.
Lo que aprendí de esto:
- Pregunta desde el principio en qué servidor y región está tu cuenta, y verifica que cualquier incidencia que te mencionen realmente te alcance.
- Exige que tu caso pase a una persona con conocimientos técnicos en cuanto las respuestas se vuelvan genéricas, en lugar de seguir alimentando el ciclo con el primer nivel. Así lo hice yo, pero por cuestión de tiempo, el ciclo volvía a iniciar con la IA de por medio.
7. Cómo evitar que vuelva a pasar
- Haz copias de seguridad propias y externas. No dependas únicamente de las del proveedor. Guarda base de datos, código y moodledata en otro lugar (nube, disco externo).
- Monitorea el uso de recursos desde el panel de tu hosting. Si tocas el límite con frecuencia, tu plan puede ser insuficiente para Moodle.
- Protege el login con captcha, límites de intentos o bloqueo de bots.
- Revisa la frecuencia del cron y qué tareas programadas se ejecutan.
- Documenta tu instalación: versión de Moodle, versión de PHP, ubicación de moodledata y datos de la base de datos.
- Considera un plan más adecuado: para Moodle en producción, un VPS o un hosting con recursos garantizados suele ser más estable que un plan compartido.
8. Cómo exigir un mejor soporte técnico
Cuando pagas por un servicio, es razonable esperar más que una lista de tareas para hacer tú mismo. Esto me habría servido desde el inicio:
- Reporta con evidencia: fecha y hora de la caída, capturas del error, versión de PHP y ubicación de la instalación.
- Pide por escrito datos concretos: qué límite se superó, en qué fechas y con qué valores. Si el argumento es «consumo de recursos», deberían poder mostrarte gráficas o registros que lo demuestren.
- Pregunta qué proceso o archivo generó el consumo. Sin eso no puedes corregir nada.
- Escala el caso si las respuestas son genéricas.
- Conserva todas las conversaciones: son tu respaldo si necesitas reclamar o cambiar de proveedor.
Un epílogo con algo de humor
Después de resolverlo yo mismo en horas, tras semanas de esperar ayuda, le dije al chat de soporte que lo justo sería que me pagaran a mí por el trabajo que ellos no pudieron hacer en semanas. Como el asistente no lo entendió a la primera, le pedí que reconociera, con diez adjetivos calificativos, cómo había sido la atención (con la condición de no usar los que yo mismo había mencionado). Esta fue su lista: deficiente, tardía, lenta, repetitiva, confusa, insuficiente, improductiva, descoordinada, frustrante y decepcionante.
Advertencia honesta: esa lista salió porque yo se la pedí a un chatbot, así que no es una admisión oficial de nada. El mismo asistente aclaró que no cuenta con la capacidad para autorizar ni prometer ningún pago. Me quedo con la lección: reclama por la vía formal, con evidencia y por escrito. No busco necesariamente una compensación económica, pero sí me parece razonable que un proveedor reconozca semanas de indisponibilidad con algún gesto concreto, como un mes de servicio sin costo.
Conclusión
Recuperar mi Moodle me costó semanas de espera y unas cuantas horas de trabajo que no estaban dentro de mis planes. Me quedo con aprendizajes claros: entender las tres piezas de la instalación, tener copias propias, verificar que las explicaciones del proveedor realmente apliquen a tu servidor y vigilar el consumo de recursos, incluso cuando el sitio parece inactivo. No fue falta de conocimiento sobre qué respaldar: cuando el tiempo se dedica primero a los proyectos de los clientes, el propio suele quedar al final de la lista.
Si tu Moodle dejó de funcionar, empieza por respaldar todo, diagnostica con calma y no dependas de una sola vía de recuperación. Y si no quieres perder semanas, escríbeme y lo resolvemos.
