Moodle 5.2 en escuelas: cursos, roles y respaldo
Un aula virtual ordenada pide cursos con dueño, roles claros, cron y restauración probada. Mini caso para escuelas técnicas.
Un aula virtual abandonada puede perder más clases que un corte de internet. Moodle 5.2.1 figura como última versión oficial en la página de descargas, con requisitos de PHP 8.3 y bases entre ellas PostgreSQL 16; Moodle Stats registra 147.727 sitios y 523.003.901 usuarios. Para una escuela técnica de Mendoza, esos números sirven menos por tamaño que por disciplina: cursos, roles, tareas programadas y respaldo probado.
Dónde aparece el aula que nadie administra
El problema operativo empieza cuando cada docente arma su curso con criterios distintos y secretaría no sabe qué cerrar al terminar el trimestre. En una escuela agrotécnica del este provincial, una netbook con etiqueta escolar rota puede mostrar el síntoma: tres aulas con el mismo nombre, alumnos duplicados y una entrega que quedó abierta después del acto de fin de curso. La cifra local ayuda a bajar la discusión. La página oficial de estadísticas lista 3.927 sitios Moodle registrados para Argentina, dentro de un mapa global de 236 países. Moodle aparece en registros públicos de uso masivo; el riesgo local está en instalarlo sin dueño operativo, cron y restauración. El sistema heredado suele ser una mezcla de grupos de mensajería, carpetas compartidas y planillas de asistencia. Moodle ordena esa mezcla solo cuando cada dato entra con rol, curso y fecha de cierre.
Cómo funciona por dentro
El flujo mínimo tiene siete pasos. Primero, secretaría crea cohortes o importa alumnos desde un CSV validado. Segundo, el administrador crea cursos, categorías, calendarios y métodos de inscripción. Tercero, Moodle guarda usuarios, cursos, roles, actividades y calificaciones en la base; PostgreSQL conserva esos registros estructurados. Cuarto, docentes cargan recursos, tareas y cuestionarios; los archivos quedan en el área de datos de Moodle y se relacionan con cada actividad. Quinto, roles de manager, editingteacher, teacher y student definen quién administra, califica, participa o consulta, tal como explica la Roles API. Sexto, el cron ejecuta tareas programadas: envíos, cierres, limpieza y procesos pendientes. Séptimo, el backup copia base, archivos y configuración; la prueba restaura un curso y abre una entrega real. Moodle recibe usuarios, cursos y archivos; entrega aulas, calificaciones, reportes y evidencias de actividad. PostgreSQL guarda datos relacionales y auditoría. El almacenamiento de archivos conserva recursos y entregas. El cron ejecuta tareas que no deberían depender de que alguien entre al panel. Si falla la base, no aparece el curso; si falla el área de archivos, aparece el curso sin materiales. La API de backup de Moodle describe planes, tareas y pasos de respaldo para datos de plugins. Ese vocabulario técnico importa porque un backup de curso y una copia del servidor resuelven problemas distintos.
Qué se instala o configura primero
La primera instalación razonable usa Moodle 5.2.1+, PHP 8.3, PostgreSQL 16, Nginx o Apache, certificado TLS, correo saliente, cron cada minuto y almacenamiento separado para copias. Una VM con 4 vCPU, 8 GB de RAM y 150 GB de disco cuesta entre USD 30 y USD 70 por mes, entre $44.850 y $104.650 al dólar oficial usado en esta corrida. El costo no incluye carga de contenidos ni capacitación docente. El primer entregable verificable es más chico: diez cursos modelo, tres roles revisados, un CSV de alumnos, una tarea con entrega, una calificación exportada y una restauración de curso en un entorno aparte. La escuela también necesita un calendario de cierre: fecha de alta, fecha de baja, responsable y carpeta donde queda la evidencia de cada ciclo. Si ese circuito funciona, la escuela puede crecer sin borrar evidencias. UMSA puede usar este patrón en educación, capacitación interna o colegios profesionales con muchos matriculados. El foco queda en operación diaria: quién crea cursos, quién cierra cohortes, quién descarga respaldos y quién firma que la restauración abrió.
Dónde se rompe y cómo probarlo
El primer riesgo es asignar permisos por apuro. La señal es un docente que puede ver cursos de otra especialidad o borrar recursos ajenos. La prueba crea usuarios de secretaría, docente y alumno, entra con cada uno y registra qué botón aparece y qué acción queda bloqueada. El segundo riesgo es cron detenido. La señal son notificaciones atrasadas, tareas que no cierran o reportes que no cambian. La prueba revisa la hora de última ejecución, fuerza una tarea controlada y guarda captura del resultado. El tercer riesgo es respaldar solo la base. La señal aparece cuando las calificaciones vuelven y los archivos entregados no. La prueba restaura base y carpeta de datos en otro servidor, abre una entrega con adjunto y exporta el curso restaurado. Un aula virtual se sostiene cuando una persona puede restaurar una clase antes de explicar por qué se perdió.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.