Los errores más caros al hospedar Moodle en el Perú no son de servidor, son de criterio: dimensionar por matriculados en lugar de concurrencia, confiar en respaldos que nunca se restauraron, postergar actualizaciones y acumular plugins sin mantenimiento. Como Moodle Certified Partner del Perú, estos son los cinco que más veces hemos tenido que corregir.
Dimensionar por concurrencia, no por matriculados
Un campus con 20,000 matriculados casi nunca tiene 20,000 personas conectadas a la vez, pero sí puede tener 3,000 rindiendo un examen el mismo martes a las 7 p. m. El dimensionamiento correcto se hace sobre ese pico y sobre el tipo de actividad, porque un cuestionario consume mucho más que leer un PDF.
En la práctica, la falla clásica aparece en semana de exámenes: el servidor estaba bien para el día normal y se cae en el único momento que no puede caerse. Se previene midiendo el pico real del semestre anterior y probando con carga antes del ciclo.
Respaldos que nunca se probaron
Un respaldo solo existe cuando se restauró con éxito. Muchas instituciones tienen copias automáticas diarias y descubren, el día del incidente, que la base de datos y los archivos no estaban sincronizados o que el proceso llevaba semanas fallando en silencio.
La regla mínima: copias diarias, retención definida, almacenamiento separado del servidor de producción y una restauración de prueba documentada cada semestre. Pregunta siempre a tu proveedor cuándo fue la última.
No actualizar la plataforma
Quedarse en una versión sin soporte deja la plataforma sin parches de seguridad y bloquea funciones nuevas, además de encarecer el salto futuro. La actualización no es un evento heroico anual: es un proceso planificado, probado en un entorno espejo y aplicado en una ventana acordada.
Si quieres ver qué se gana al mantenerse al día, revisa las novedades de Moodle 5.2.
Plugins abandonados
Cada plugin es código de terceros que hay que mantener. Los problemas aparecen cuando se instalan por entusiasmo, dejan de actualizarse y luego impiden migrar a la siguiente versión de Moodle. Revisa fecha de la última versión, compatibilidad declarada y si hay alternativa en el núcleo.
- Inventaría los plugins instalados y quién los pidió.
- Descarta los que no se usan en ningún curso activo.
- Verifica compatibilidad con la próxima versión antes de actualizar.
- Documenta el responsable funcional de cada uno que se queda.
Trabajar sin entorno de pruebas
Sin un entorno espejo, cada cambio se prueba en producción y con estudiantes dentro. Un entorno de pruebas con datos representativos permite validar actualizaciones, plugins e integraciones sin riesgo, y cuesta una fracción de lo que cuesta una caída en examen.
"Si tu única forma de probar un cambio es aplicarlo en producción, ya estás asumiendo el riesgo más caro del proyecto."
Cómo se estructura una operación gestionada está detallado en hosting e implementación de Moodle, y los rangos de inversión anual en precio de hosting y soporte Moodle en el Perú.
No mirar la plataforma hasta que falla
Un error silencioso es operar sin monitoreo. Sin métricas de tiempo de respuesta, uso de disco, errores del servidor y trabajos programados, el equipo se entera de los problemas por el reclamo de un estudiante. Para entonces la clase ya se perdió.
Lo mínimo razonable: alertas de disponibilidad, aviso cuando el disco supera un umbral, revisión de la cola de tareas programadas y un tablero que alguien mire de verdad cada semana. El monitoreo sin responsable asignado no sirve. Ese seguimiento forma parte de los planes de soporte Moodle.
Descuidar el envío de correos
Moodle depende del correo para avisos de matrícula, recuperación de contraseña, notificaciones de foros e informes. Cuando ese envío se configura sin autenticación de dominio, los mensajes caen en spam o se rechazan, y la institución concluye erróneamente que la plataforma no notifica.
La solución es usar un servicio de envío con el dominio institucional debidamente autenticado y revisar periódicamente los rebotes. Es un detalle pequeño con un efecto enorme en la percepción de la plataforma.
Contratar sin saber qué incluye el servicio
Muchas instituciones comparan precios de hosting que no cubren lo mismo. Antes de firmar conviene tener por escrito qué versión de Moodle se mantiene y con qué frecuencia se actualiza, quién administra el servidor, cómo se reportan incidencias y en qué horario, qué respaldos se hacen y quién es el titular de los datos y de los accesos.
Con esa lista, dos propuestas se vuelven comparables y desaparecen las sorpresas del segundo año. Revisa nuestras soluciones Moodle y conversemos sobre el alcance que necesita tu institución.
Preguntas frecuentes
¿Cuántos usuarios concurrentes soporta un servidor Moodle?
Depende del tipo de actividad, no solo del número. Un examen con preguntas calculadas exige mucho más que una lectura de recursos. Por eso el dimensionamiento se hace sobre el pico previsto y se prueba con carga antes del ciclo.
¿Cada cuánto se debe probar una restauración?
Al menos una vez por semestre y siempre después de un cambio mayor de infraestructura. Un respaldo que nunca se restauró es una suposición, no una copia de seguridad.
¿Es riesgoso actualizar Moodle?
Es más riesgoso no hacerlo. La actualización se prueba primero en un entorno espejo con los mismos plugins y datos, y se aplica en ventana acordada con plan de reversa.
¿Se puede hospedar Moodle en un hosting compartido barato?
Para un piloto pequeño puede alcanzar, pero en la práctica falla en picos de examen y limita los procesos programados. Para uso institucional se necesita infraestructura dedicada y gestionada.
¿Cuánto cuesta un hosting gestionado en el Perú?
Los rangos referenciales por tramo de usuarios están en nuestro artículo de precios de hosting y soporte.
Sigue leyendo: protección de datos personales en Moodle (ley peruana).
Lee también: qué debe incluir un SLA de soporte y mantenimiento de Moodle y cómo actualizar Moodle sin tumbar el semestre.