Un respaldo de Moodle solo vale lo que vale su última restauración probada. En instituciones peruanas, la diferencia entre un incidente y una crisis suele estar en cláusulas que nadie escribió: qué se respalda, cada cuánto, cuánto se conserva y quién restaura. Somos el Moodle Certified Partner del Perú y operamos plataformas bajo estos criterios.
Qué se respalda realmente
Un respaldo completo de Moodle tiene tres piezas: la base de datos, el directorio de archivos donde viven las entregas y recursos, y el código con plugins y tema. Con la base de datos sola no hay archivos; con los archivos solos no hay notas ni matrículas. Si el contrato no nombra las tres, no describe un respaldo completo.
- Base de datos: usuarios, matrículas, calificaciones, configuración y registros.
- Directorio de archivos: entregas, recursos, imágenes, paquetes de contenido.
- Código y plugins: versión exacta de Moodle, plugins instalados y tema personalizado.
Frecuencia, retención y copias fuera de sitio
La frecuencia define cuánta información puedes perder; la retención define cuán atrás puedes volver. Un esquema diario con retención de varias semanas cubre el caso habitual: un error detectado tarde, un borrado accidental o un plugin que corrompió datos. Ambos números deben estar escritos en el acuerdo.
Igual de importante es dónde se guardan las copias. Un respaldo alojado en el mismo servidor que la plataforma desaparece con el servidor. Exige al menos una copia en ubicación separada y, si tu institución lo requiere, una copia entregada periódicamente a la propia institución.
RPO y RTO en lenguaje claro
RPO es cuánta información aceptas perder, medida en tiempo: si el respaldo es diario, el RPO es de hasta un día. RTO es cuánto tarda la plataforma en volver a estar operativa tras un incidente grave. Ambos son compromisos de servicio, no características técnicas, y se negocian según el calendario académico.
Un consejo práctico: define RPO y RTO distintos para periodos críticos. Durante matrícula o exámenes, la tolerancia baja; en vacaciones, sube. Ese matiz cabe en una línea del acuerdo y evita discusiones cuando ocurre el problema. El resto de compromisos de atención se documenta en el checklist de SLA de soporte.
La prueba de restauración: el punto que casi nadie exige
Restaurar es una operación distinta de respaldar y puede fallar por permisos, versiones o archivos incompletos. Por eso la única evidencia válida de que un respaldo funciona es una restauración ejecutada en un entorno separado, con verificación de acceso, cursos y calificaciones, y con constancia escrita de fecha y resultado.
- Restaurar la copia más reciente en un entorno aislado.
- Verificar inicio de sesión, un curso con calificaciones y un archivo entregado.
- Comprobar que plugins y tema quedaron operativos.
- Registrar duración real de la restauración y compararla con el RTO comprometido.
- Repetir con periodicidad definida, no solo al inicio del contrato.
Este es uno de los errores más comunes al hospedar Moodle: respaldos que existen y nunca se probaron.
Respaldo de curso frente a respaldo de plataforma
Moodle incluye un respaldo de curso que exporta un curso con sus actividades y, opcionalmente, con datos de usuarios. Sirve para duplicar cursos entre semestres o recuperar uno borrado, pero no reemplaza al respaldo de infraestructura: no contiene la configuración del sitio, los usuarios globales ni los plugins.
La buena práctica es combinar ambos: respaldo automático de plataforma a cargo del hosting gestionado y respaldo de curso a cargo del equipo académico antes de cambios grandes.
Cláusulas que debes exigir por escrito
Pide que el contrato diga, con nombre y número, seis cosas: alcance del respaldo, frecuencia, retención, ubicación de las copias, RPO y RTO comprometidos, y periodicidad de la prueba de restauración. Añade quién ejecuta la recuperación y por qué canal se solicita fuera de horario.
Estas cláusulas se revisan junto con el resto del acuerdo de servicio; nuestra página de soporte gestionado de Moodle describe cómo las estructuramos, el artículo sobre soporte y mantenimiento de Moodle detalla las severidades asociadas y el de precio de hosting y soporte Moodle en el Perú ubica el orden de inversión.
Define cuánto puedes perder y cuánto esperar
Un plan de respaldo empieza con dos números acordados con la institución: cuánta información se puede perder como máximo y cuánto tiempo puede estar la plataforma fuera de servicio. No son decisiones técnicas, son decisiones de negocio. Una universidad en semana de exámenes tolera mucho menos que un catálogo de cursos abiertos consultado de vez en cuando.
Con esos dos números, la frecuencia de los respaldos y el tipo de copia dejan de ser una discusión de opinión. Si la institución acepta perder como máximo una hora, el respaldo diario no alcanza y hay que sumar copias más frecuentes de la base de datos. Escribe ambos valores en el contrato de servicio; sin eso, cada incidente se resuelve improvisando.
Probar la restauración, no solo el respaldo
Un respaldo que nunca se restauró es una suposición. Programa al menos dos simulacros al año: levantar una copia en un entorno aparte, verificar que la base y los archivos coinciden, entrar con una cuenta de prueba y revisar un curso con calificaciones y entregas. Anota cuánto demoró el proceso completo, porque ese es tu tiempo real de recuperación.
El simulacro suele revelar detalles que nadie anticipó: archivos grandes que no entraron en la copia, una configuración de correo que apunta al servidor de producción, o un plugin que ya no existe en la versión restaurada. Corregir eso en un ensayo cuesta una mañana; descubrirlo durante una caída real cuesta mucho más.
Las primeras horas de un incidente
Ten escrito quién declara el incidente, quién comunica y por qué canal. Durante una caída, la mitad del desgaste viene de personas pidiendo información a la vez. Un mensaje breve cada cierto tiempo —qué pasó, qué se está haciendo, cuándo hay siguiente actualización— baja mucho la tensión, incluso sin solución todavía.
Después del incidente, documenta la causa y el ajuste que evita la repetición, y comparte ese resumen con las autoridades. Si prefieres que esa rutina esté cubierta por un equipo certificado, revisa soporte y mantenimiento y el resto de nuestras soluciones, y agendemos una reunión para ajustarlo a tu caso.
Preguntas frecuentes
¿Qué incluye un respaldo completo de Moodle?
Tres piezas: la base de datos, el directorio de archivos (moodledata) y el código con los plugins y el tema. Si falta alguna, la restauración no devuelve la plataforma al estado anterior.
¿Cada cuánto deberían hacerse los respaldos?
Un respaldo diario de base de datos y archivos es la base razonable para un campus en operación; en periodos de matrícula o exámenes conviene aumentar la frecuencia de la base de datos. La frecuencia debe estar escrita, no asumida.
¿El respaldo de curso de Moodle reemplaza al respaldo del servidor?
No. El respaldo de curso sirve para copiar o restaurar un curso puntual, pero no incluye usuarios del sitio, configuración global ni plugins. Son mecanismos complementarios.
¿Cómo sé que mis respaldos sirven?
Solo con una prueba de restauración documentada: restaurar en un entorno separado, verificar acceso, cursos y calificaciones, y dejar constancia de la fecha y el resultado. Un respaldo nunca probado es una suposición.
¿Debo pedir copias fuera del proveedor?
Es recomendable en instituciones con requisitos de continuidad o auditoría. Una copia periódica entregada a la institución evita depender de un solo actor ante una disputa contractual o un incidente mayor.
¿Cada cuánto debería respaldar mi Moodle?
Depende de cuánta información aceptes perder. Con clases activas y evaluaciones en línea, una copia diaria de archivos más copias más frecuentes de la base de datos es un punto de partida razonable.
¿Sirve el respaldo de cursos de Moodle como plan de recuperación?
Sirve para mover o reutilizar un curso, no para recuperar la plataforma completa. Un plan real incluye base de datos, archivos y configuración del servidor.
¿Dónde deben guardarse las copias?
Al menos una copia fuera del mismo entorno que la plataforma. Si el respaldo vive junto a lo que respalda, un mismo incidente puede llevarse ambos.