Antes se quemaba a las brujas únicamente porque se creía que lo eran, sin más prueba que la creencia misma. Hoy parece que la historia se invirtió: ahora son las brujas las que queman a los profesores. Y lo hacen solo porque son brujas, porque creen que con señalar les alcanza para denostar a alguien, y que la hoguera pública es un derecho que no necesita justificación. Simple y sencillamente cambiaron las antorchas por las redes sociales y los micrófonos, pero la lógica es la misma: la sospecha convertida en sentencia.
Una representación de las antiguas cazas de brujas y de cómo una acusación podía convertirse en una condena colectiva.
Habitualmente escribo sobre Moodle, sobre inteligencia artificial y sobre actividades para profesores o consejos técnicos para quienes trabajamos con tecnología . Hoy me aparto de esos temas, porque ahora que el profesor injustamente acusado por hacer su trabajo, al momento no se ha demostrado que sea culpable, ha sido restituido en sus actividades laborales por la gobernadora de Veracruz, es justo señalar lo siguiente:
Me indigna ver cómo un profesor puede ser señalado públicamente por algo tan grave sin que, al menos hasta donde se ha hecho público, se presenten pruebas que permitan sostener la acusación. Y lo digo como profesor.
Quienes estamos frente a un grupo sabemos lo difícil que se ha vuelto ejercer esta profesión. Cada actividad que diseñamos, cada instrucción que damos y cada dinámica que proponemos tiene como único propósito que nuestros alumnos aprendan. Yo no entro a un salón pensando en cómo hacerle daño a un alumno. Pero sí lo hago pensando en qué tendré que hacer para explicarles el tema del día. Porque yo soy de los que se paran de cabeza, si es preciso, para que algo les quede claro a mis alumnos.
Sin embargo, ahora parece que también tendré que preguntarme si una actividad será malinterpretada, si alguien se sentirá ofendido, si un padre de familia decidirá que detrás de una instrucción existe alguna intención que jamás estuvo ahí o si, de pronto, terminaré expuesto públicamente por algo que hice dentro de mi espacio de trabajo. Y, dadas las circunstancias, creo que no soy el único con este temor. Y aquí hay algo que me parece todavía más preocupante:
¿En qué momento una acusación se convirtió en una prueba?
Si un profesor cometió algo que constituye un delito, que se investigue. Sobre todo si se trata de atentar contra un menor. Es algo que no tolero. Si existen pruebas, que se presenten. Si alguien tiene elementos para demostrar una conducta ilegal, que los lleve ante las autoridades correspondientes.
Pero si no hay pruebas, ¿por qué debemos aceptar automáticamente la acusación como la única verdad?
Cuando la acusación se convierte en sentencia
Porque este problema no se limita a un profesor. Hoy alguien puede decir: “Ese maestro hizo algo contra mi hija”. Otro puede decir: “Ese político es narco”. Otro puede decir: “Esa persona cometió tal delito”. Y parece que basta con decirlo.
Una representación simbólica de la presión pública contra profesores acusados antes de que se demuestren los hechos.
¿Y las pruebas? ¿Dónde están las pruebas? Parece de risa loca, pero ahora la pregunta no es “¿y dónde está el policía?”. Ahora es, o al menos así debería serlo: “¿y dónde están las pruebas?”
No estoy defendiendo a un político ni a una madre que haya hecho una acusación. No estoy en contra de ninguno de los antes mencionados. Tampoco pretendo determinar desde fuera quién tiene la razón en un caso que debe investigarse, y solo por las autoridades competentes. Estoy defendiendo algo mucho más sencillo:
El derecho de cualquier persona a no ser condenada públicamente únicamente porque alguien decidió señalarla.
El derecho a no ser condenado sin pruebas
Porque si una acusación es cierta, las pruebas deberían poder sostenerla. Y si no puede sostenerse, entonces también debería existir una consecuencia para quien acusa irresponsablemente. De lo contrario, cualquiera puede destruir la reputación de otra persona con unas cuantas palabras y después simplemente continuar con su vida.
¿Narcopolítico? Pruébalo. Si no puedes sostenerlo, ¡TAMBO!
Acusar a un profesor también tiene consecuencias
“El maestro dejó una actividad que atenta contra mi hija”. Pruébalo. Si no puedes comprobarlo, ¡TAMBO!
En este caso en específico, queda de manifiesto que quien acusa jamás ha tomado un libro entre sus manos. Y debería hacerlo, si no para cultivarse, al menos para saber qué es lo que su hija verá en clase y ahorrarse el ridículo nacional.
Pero, sobre todo, para ahorrarles a los acusados el mal sabor de boca solo porque cree que el único fin que tiene un croquis es saber cómo llegar a la casa de la alumna a la que se va a violentar. Ridículo. Está comprobado que la mayoría de quienes abusan de los menores son familiares cercanos o personas cercanas a los niños por la naturaleza de su profesión, pero no necesariamente profesores. Y, sobre todo, no les piden un croquis. Por duro que parezca, piden otras cosas y, para desgracia del menor, cuando esto sucede, los padres o tutores no se dan por enterados.
¿Acusar sin pruebas? ¡TAMBO! ¿Difamar y luego hacerse el desentendido? ¡TAMBO! ¿Destruir una reputación para después seguir como si nada? ¡TAMBO, TAMBO y TAMBO!
Tampoco se trata de ponerme del lado de nadie por la simple y sencilla razón de hacerlo. Se trata de entender que la libertad de hablar también debería venir acompañada de responsabilidad por lo que decimos. Y quizá muchos no pensamos en esto hasta que le ocurre a alguien cercano. Hasta que el señalado es un amigo, un familiar, un compañero o nosotros mismos. Solo hasta entonces preguntamos: ¿y las pruebas? Y es que eso es algo que deberíamos preguntar desde el principio. Se trate de quien se trate.
Una sociedad en la que cualquiera puede acusar a cualquiera sin tener que demostrar nada termina convirtiendo la acusación en una sentencia. Y eso, independientemente de quién sea el acusado, debería preocuparnos a todos.
¿Y por qué digo todo esto? Porque yo soy profesor. Y sé perfectamente que detrás de una actividad que preparo, de una instrucción que doy y de cada minuto que paso frente a mis alumnos, hay un propósito muy distinto al que las personas sin quehacer y sin oficion ni beneficio podrían imaginar:
(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.
Cuando el soporte técnico comienza con una IA y la solución parece quedar sepultada.
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;
Para recuperar una instalación de Moodle, necesitas conservar el código, la base de datos y los archivos almacenados en moodledata.
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.
Mientras la IA responde las consultas, el equipo de soporte parece estar de vacaciones. Una sátira sobre la atención técnica automatizada.
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.
La larga espera del soporte técnico de Hostinger. Así se sintió esperar una respuesta útil del soporte técnico mientras mi Moodle seguía caído.
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.
