El mantenimiento reactivo (arreglar lo que se rompe cuando se rompe) es necesario, pero no sustituye a un plan con calendario propio. Sin ese calendario, el mantenimiento se convierte en una sucesión de sorpresas: nadie revisa el certificado SSL hasta que caduca, nadie prueba la restauración de un backup hasta que se necesita de verdad, nadie planifica la actualización de versión hasta que ya está muy retrasada.
En esta guía vas a ver un calendario de mantenimiento anual completo, con tareas repartidas entre revisiones mensuales, trimestrales y anuales, para que dejes de depender únicamente de apagar incendios.
Revisiones mensuales
| Tarea | Por qué mensual |
|---|---|
| Ejecutar el informe de Security Checks de Moodle | Detecta configuraciones débiles antes de que se conviertan en un incidente |
| Revisar avisos de seguridad publicados desde la última revisión | Confirma si algún parche crítico requiere acción inmediata |
| Verificar que el cron sigue ejecutándose correctamente | Un fallo silencioso puede llevar semanas sin detectarse si no se comprueba activamente |
| Revisar el uso de espacio en disco | Anticipa problemas de capacidad antes de que causen fallos |
| Probar una restauración de backup en entorno de pruebas | Confirma que las copias de seguridad realmente funcionan, no solo que se generan |
Estas cinco tareas comparten una característica: fallan en silencio. Nadie te avisa de que el cron lleva tres semanas parado ni de que la última copia no restaura. Por eso la cadencia mensual no es un capricho, sino el intervalo máximo que puedes dejar pasar antes de que uno de estos fallos silenciosos se convierta en un problema visible en el peor momento.
En la práctica, así se ejecuta cada una:
- Informe de seguridad. En Administración del sitio › Informes › Comprobaciones de seguridad tienes el chequeo nativo de Moodle. Lo que importa no es que salga alguna advertencia (casi siempre hay alguna en amarillo) sino revisar si ha aparecido algo nuevo en rojo desde la última vez:
config.phpcon permisos de escritura, cuentas de administrador sin autenticación de dos factores, o el modo de depuración dejado activado tras una intervención. Ese último es el error clásico: alguien ponedebugaDEVELOPERpara diagnosticar algo y se olvida de bajarlo, exponiendo rutas y trazas. - Avisos de seguridad. Moodle publica sus avisos de seguridad de forma agrupada (habitualmente una vez al mes) en moodle.org. La revisión mensual consiste en cruzar esa lista con tu versión: si un aviso afecta a tu rama y trae parche, deja de ser una tarea de calendario y pasa a ser una actualización urgente.
- Que el cron corre. En Administración del sitio › Servidor › Tareas › Tareas programadas se ve la última ejecución de cada tarea. El cron de Moodle debe dispararse cada minuto; si la columna de “última ejecución” muestra horas o días de retraso, algo lo tiene parado. Un cron caído no da la cara: simplemente dejan de enviarse notificaciones, de generarse backups programados, de procesarse la cola de mensajes y de actualizarse el seguimiento de finalización. Puedes confirmarlo también desde el servidor:
# ¿Cuándo corrió el cron por última vez? (debe ser hace < 1 min)
sudo -u www-data php /ruta/a/moodle/admin/cli/cron.php- Uso de disco. Vigila sobre todo la partición de
moodledata, que crece con cada archivo subido, sesión y caché. Undf -hbasta para ver el porcentaje; si sube rápido, revisamoodledata/trashdir,moodledata/tempymoodledata/sessions, que se hinchan solos. Quedarse sin espacio enmoodledatano ralentiza Moodle: lo tumba. - Restaurar un backup de prueba. Generar copias no demuestra nada; solo la restauración lo hace. Restaura una copia reciente en un entorno de pruebas y comprueba que el curso vuelve entero, con sus usuarios y calificaciones. Este es un tema con suficiente miga como para tratarlo aparte: lo desarrollamos en cómo verificar que tus backups restauran de verdad.
Buena parte de estas comprobaciones se pueden automatizar con alertas para no depender de que alguien se acuerde de mirar; en soporte y monitorización de Moodle explicamos qué merece la pena vigilar en tiempo real y qué basta con revisar en la ronda mensual.
Revisiones trimestrales
| Tarea | Por qué trimestral |
|---|---|
| Auditar roles y permisos de usuarios | Detecta accesos heredados o excesivos que se acumulan con el tiempo |
| Revisar plugins instalados frente a los realmente usados | Elimina peso innecesario en cada carga de página |
| Revisar contenido multimedia de cursos activos | Detecta imágenes o vídeos sin optimizar que penalizan el rendimiento |
| Comprobar la fecha de caducidad del certificado SSL y su renovación automática | Evita sorpresas de “sitio no seguro” sin previo aviso |
| Revisar el ratio de aciertos del buffer pool de la base de datos | Anticipa si hace falta ajustar la configuración conforme crece el volumen de datos |
Lo trimestral son tareas que no aguantan un año sin mirarse, pero que tampoco cambian de un mes para otro. Son degradaciones lentas: el rendimiento que empeora medio segundo por trimestre, los permisos que se acumulan matrícula tras matrícula. Un trimestre es el intervalo en el que la deriva ya es medible pero todavía barata de corregir.
- Auditar roles y permisos. En Administración del sitio › Usuarios › Permisos › Asignar roles de sistema revisas quién tiene privilegios de gestor o administrador a nivel global. El patrón que vemos entrar por soporte es siempre el mismo: se dio rol de gestor a un profesor “por una tarea puntual” hace dos cursos y ahí sigue. Comprueba también los roles asignados en categorías, no solo los del sistema.
- Plugins usados vs instalados. En Administración del sitio › Plugins › Vista general de plugins ves los plugins adicionales (de terceros) separados de los del núcleo. Cada plugin de terceros es peso en cada carga de página y, sobre todo, un obstáculo en cada actualización: un plugin abandonado por su autor puede bloquear una subida de versión entera. Si un plugin no lo usa ningún curso activo, desinstalarlo es reducir superficie de ataque y de fallo.
- Multimedia de cursos activos. Los vídeos de 500 MB subidos directamente al curso y los PDF de 80 MB sin comprimir son los que penalizan el rendimiento y engordan
moodledata. Localiza los cursos más pesados y valora mover lo grande a un servicio de streaming en vez de servirlo desde Moodle. - Certificado SSL. No basta con que el certificado sea válido hoy; hay que confirmar que la renovación automática funciona. Con Let’s Encrypt el certificado dura 90 días y se renueva por cron: si ese cron falla en silencio, te enteras cuando el navegador ya muestra “sitio no seguro”. Comprueba la fecha de caducidad y que el temporizador de renovación está activo:
# Fecha de expiración del certificado en uso
echo | openssl s_client -connect tudominio.com:443 2>/dev/null | openssl x509 -noout -enddate- Buffer pool de la base de datos. En InnoDB (MySQL/MariaDB) el ratio de aciertos del buffer pool indica cuántas lecturas se sirven desde memoria en vez de tocar disco. Si el ratio baja conforme crece el volumen de datos, es la señal de que
innodb_buffer_pool_sizese ha quedado corto y conviene ampliarlo antes de que el rendimiento se note en las horas punta.
Revisión anual completa
| Tarea | Detalle |
|---|---|
| Evaluar si tu versión de Moodle sigue dentro de la ventana de soporte LTS | Planificar migración con margen, no en el último mes de soporte |
| Revisar el dimensionamiento de servidor frente a la concurrencia real actual | El crecimiento de matrícula puede haber dejado corto el servidor original |
| Auditar el cumplimiento de RGPD/LOPD y, si aplica, de requisitos FUNDAE | Confirmar que la configuración de privacidad y trazabilidad sigue vigente |
| Revisar la checklist completa de hardening de seguridad | Confirmar que ningún ajuste se ha degradado con cambios acumulados durante el año |
| Hacer una prueba de carga completa antes del inicio de curso | Confirmar que el servidor soporta la concurrencia esperada para el nuevo curso |
| Revisar y actualizar la documentación de procesos internos (protocolo de incidencias, contactos de emergencia) | Evitar depender de memoria informal sobre qué hacer en cada situación |
La revisión anual es la que mira las cosas que sí aguantan doce meses, pero que si se descuidan más allá de eso se vuelven caras o directamente bloqueantes.
- Ventana de soporte LTS. Comprueba en qué punto de su ciclo de vida está tu versión. Moodle marca para cada rama una fecha de fin de soporte general (correcciones de errores) y otra, más lejana, de fin de soporte de seguridad; las versiones LTS tienen la ventana de seguridad más larga. Lo que importa es no llegar al último mes de soporte para empezar a planificar: una migración con margen se hace por versiones intermedias sin sobresaltos, mientras que una migración a la desesperada suele saltarse pasos. La ruta concreta la detallamos en la checklist de actualización de Moodle.
- Servidor vs concurrencia real. El servidor que se dimensionó para 300 alumnos puede haberse quedado corto tras dos cursos de crecimiento. Contrasta la concurrencia real que ves en los picos (inicio de curso, entregas, exámenes) con la capacidad que contrataste, no con la matrícula total, lo que importa es cuánta gente coincide, no cuánta está dada de alta.
- RGPD/LOPD y FUNDAE. Confirma que la configuración de privacidad (política, consentimientos, retención de datos) sigue vigente. Si impartes formación bonificada, la trazabilidad que exige FUNDAE (registros de conexión, tiempos, finalización) tiene que estar activa y guardándose, porque es exactamente lo que te pedirán en una inspección y no se puede reconstruir a posteriori.
- Checklist de hardening. A lo largo de un año se acumulan intervenciones, y cada una puede haber degradado un ajuste de seguridad sin que nadie lo note. Repasar la checklist completa confirma que nada se ha relajado por el camino.
- Prueba de carga antes del curso. Simular la concurrencia esperada antes del arranque (no durante) es la única forma de saber si el servidor aguanta el primer día, que suele ser el pico del año.
- Documentar procesos. El protocolo de incidencias y los contactos de emergencia deben estar escritos y actualizados, no en la cabeza de una persona que puede estar de vacaciones justo el día que cae el sitio.
Momentos críticos que merecen revisión reforzada, fuera del calendario regular
- Antes del inicio de cada curso académico: prueba de carga, verificación de backups, y confirmación de que toda la configuración de seguridad sigue en orden tras el periodo de menor actividad del verano.
- Antes de cualquier convocatoria de examen masivo: monitorización reforzada, protocolo de incidencia revisado, y disponibilidad confirmada del equipo de reacción.
- Tras cualquier migración de servidor o actualización de versión: verificación completa del cron, backups, certificado SSL y rendimiento, no solo confirmar que el sitio “carga bien”.
Por qué un calendario formal cambia el resultado
La diferencia entre un centro con un calendario de mantenimiento definido y uno sin él no se nota en un día normal, ambos funcionan igual de bien la mayoría del tiempo. Se nota exactamente en el momento en que algo falla: el centro con calendario ya sabe cuándo se probó el último backup, cuándo se revisó la seguridad por última vez, y qué versión de Moodle está corriendo frente a la ventana de soporte oficial. El centro sin calendario tiene que averiguar todo eso en mitad del incidente, con la presión añadida de no tener ese contexto ya resuelto.
Cómo asignar responsabilidades sin que quede en el aire
Un calendario de mantenimiento sin una persona (o proveedor) con la responsabilidad explícita de ejecutarlo cada mes es, en la práctica, papel mojado. Cada tarea de este calendario necesita un responsable claro y una fecha límite concreta, no solo estar “documentada en algún sitio” sin seguimiento activo.
Errores comunes al implementar un calendario de mantenimiento
- Crear el calendario pero no asignar responsables concretos, quedando en una lista de buenas intenciones sin ejecución real.
- Saltarse revisiones mensuales cuando hay mucho trabajo, acumulando meses sin comprobar backups o seguridad hasta que ya es demasiado tarde.
- No reforzar la vigilancia en los momentos críticos (inicio de curso, exámenes), tratando esas fechas como cualquier otra semana normal.
- No revisar el calendario en sí mismo, dejando tareas obsoletas o repitiendo un plan que ya no corresponde al tamaño actual de la instalación.
Preguntas frecuentes
¿Qué pasa si no tengo tiempo para hacer todas estas revisiones mensuales? Es una señal clara de que el mantenimiento necesita más recursos dedicados (internos o externalizados), no una razón para saltarse las revisiones sin sustituirlas por otra vía.
¿Es necesario un calendario formal si mi Moodle es pequeño? Sí, aunque el tamaño de la instalación sea modesto, el riesgo de un backup que nunca se probó o una versión que quedó sin soporte es el mismo, independientemente del volumen de alumnos.
¿Con qué antelación debo revisar el calendario antes del inicio de curso? Al menos varias semanas antes, para tener margen de corregir cualquier problema detectado (rendimiento, backups, seguridad) antes de que empiece la actividad real.
¿Quién debería ser responsable de ejecutar este calendario? Alguien con la responsabilidad explícita asignada, sea interno o un proveedor externo, sin un responsable claro, el calendario tiende a quedar sin ejecutar en la práctica.
¿Qué pasa si detecto que mi versión de Moodle está a punto de quedar sin soporte durante la revisión anual? Es el momento de planificar la migración con margen, siguiendo la ruta de versiones intermedias necesarias, en vez de esperar a que el soporte expire antes de actuar.
¿Debo revisar el calendario de mantenimiento en sí mismo con el tiempo? Sí, conforme crece tu instalación o cambian tus necesidades (por ejemplo, si empiezas a impartir formación bonificada), el calendario debe ajustarse para reflejar esos nuevos requisitos.
¿Por qué probar la restauración de un backup cada mes y no una vez al año?
Porque una copia que no restaura no da ningún aviso: se genera todos los días con aspecto perfecto hasta el día que la necesitas de verdad. Los motivos por los que una copia deja de restaurar (un cambio de versión de la base de datos, moodledata que dejó de incluirse, un plugin que ya no existe) aparecen en cualquier momento del año. Un mes es el máximo margen razonable para que, si algo se rompió, lo descubras tú en una prueba y no en una emergencia.
¿Cómo sé si el cron de Moodle está realmente parado? Mira en Administración del sitio › Servidor › Tareas › Tareas programadas la columna de última ejecución: si muestra un retraso de horas o días respecto a lo previsto, el cron no está corriendo cada minuto como debería. Un síntoma indirecto muy fiable es que dejan de llegar notificaciones por correo o que los backups programados no aparecen; cuando eso pasa, lo primero que hay que descartar es el cron.
¿Puedo agrupar todas las revisiones en una sola sesión anual y ahorrarme las mensuales? No, y ese es justo el error que este calendario evita. Las tareas están repartidas por cadencia porque cada una tiene un ritmo de deterioro distinto: el cron o un backup roto no aguantan un año sin mirarse, mientras que la ventana de soporte LTS sí. Concentrarlo todo en una revisión anual te deja ciego once meses ante los fallos que más rápido escalan.
¿Qué revisiones son las más críticas si tengo recursos muy limitados? Si tuvieras que quedarte solo con tres, serían las mensuales que fallan en silencio: que el cron corre, que hay espacio en disco y que un backup restaura. Son las que, cuando fallan, lo hacen sin avisar y en el peor momento. El resto del calendario reduce riesgo a medio plazo; estas tres evitan la caída inmediata.
Conclusión
Un calendario de mantenimiento con tareas mensuales, trimestrales y anuales convierte la gestión de Moodle en algo predecible, en vez de una sucesión de sorpresas reactivas. La clave no está solo en definirlo, sino en asignar responsables concretos y revisarlo con la misma disciplina que cualquier otra obligación crítica del centro.
Si prefieres que alguien aplique este calendario por ti de forma sistemática, en Avantys lo llevamos como parte del mantenimiento continuo de cada Moodle que gestionamos. Puedes pedir una auditoría gratuita en Moodle Gestionado.
Artículos relacionados
- Mantenimiento y hosting Moodle: guía completa
- Externalizar el mantenimiento de Moodle: pros y contras
- Checklist de hardening de Moodle
- Backups de Moodle: cómo verificar que restauran de verdad
¿Y si tu Moodle lo lleváramos nosotros?
Actualizaciones, backups verificados, rendimiento y trazabilidad FUNDAE, gestionado de forma continua por una persona que responde. Auditoría gratuita de tu plataforma actual.
