“Tenemos backups automáticos” es una de las frases más engañosamente tranquilizadoras en administración de sistemas. Un backup que nunca se ha restaurado no es una garantía, es una suposición, y la única forma de convertir esa suposición en certeza es probar la restauración de verdad, con regularidad, no solo confiar en que el proceso automático “seguro que funciona”.
En esta guía vas a ver por qué un backup sin probar es un riesgo silencioso, cómo montar un proceso de verificación periódica, y qué señales indican que tu backup actual podría no ser tan fiable como crees.
Por qué “está programado” no es lo mismo que “funciona”
Un proceso de backup puede fallar de formas que no generan ningún error visible: un archivo corrupto que se genera correctamente en apariencia pero no se puede leer al restaurar, una configuración que excluye sin querer parte de los datos, o un volcado de base de datos incompleto por falta de espacio en disco durante la ejecución. Ninguno de estos fallos se nota mientras el backup simplemente “se genera”: todos se descubren únicamente al intentar restaurar.
Qué verificar exactamente
Un backup de Moodle completo cubre tres componentes, y cada uno necesita su propia verificación:
| Componente | Qué comprobar al restaurar |
|---|---|
| Código de la aplicación | Que la versión y los archivos coinciden con lo esperado, sin archivos faltantes |
moodledata | Que los archivos subidos por usuarios, backups de curso y caché están completos y accesibles |
| Base de datos | Que el volcado se importa sin errores y que los datos (cursos, calificaciones, usuarios) son consistentes |
Backup de curso (.mbz) y backup de servidor completo no son lo mismo
Este es el malentendido que más caro sale. Muchos administradores creen tener “backups de Moodle” cuando lo que tienen son exportaciones de cursos hechas desde el propio panel. Son dos cosas distintas y no se sustituyen:
Backup de curso (.mbz) | Backup de servidor completo | |
|---|---|---|
| Qué contiene | Un curso: sus actividades, recursos, y opcionalmente entregas y notas de sus alumnos | Todo el Moodle: código de la aplicación, base de datos entera y moodledata completo |
| Cómo se genera | Desde Administración del curso → Copia de seguridad, en la propia interfaz de Moodle | Fuera de Moodle: volcado de BD + copia de ficheros del servidor (o snapshot del hosting) |
| Para qué sirve | Migrar o clonar un curso, guardar una edición antes de tocarla, mover contenido entre plataformas | Recuperar el sitio entero tras un fallo de disco, un hackeo, una migración fallida o un borrado masivo |
| Qué NO recupera | Otros cursos, usuarios globales, configuración del sitio, plugins, temas, roles | Nada: es la copia de referencia para un desastre total |
| Tamaño típico | De unos MB a pocos GB por curso | Tantos GB como pese tu moodledata + la BD (a menudo decenas o cientos) |
La regla práctica: el .mbz es una herramienta de trabajo con el contenido de un curso; el backup de servidor completo es tu seguro contra la pérdida de la plataforma. Si solo tienes lo primero y el servidor se cae, has perdido usuarios, matrículas, configuración y el resto de cursos. Si necesitas el detalle de cómo se genera y restaura un .mbz, lo desarrollamos en backup y restauración completa de un curso; aquí nos centramos en el backup completo, que es el que de verdad te salva de un desastre.
El fallo silencioso: el backup que dejó de generarse hace meses
El escenario más peligroso no es un backup corrupto, es un backup que directamente no existe, pero cuya ausencia nadie ha notado porque “estaba programado”. Los tres culpables que vemos entrar por soporte una y otra vez:
- Disco lleno. El volumen donde se escriben los backups se llenó, y desde ese día cada ejecución falla o genera un archivo truncado. El cron sigue corriendo, así que en apariencia “el sistema está haciendo backups”; en realidad lleva semanas escribiendo ceros.
- Cron parado. Una migración de servidor, un reinicio, o un cambio de usuario del sistema dejó la tarea programada sin ejecutarse. Nadie recibe un aviso: la ausencia de una tarea no genera error, simplemente no pasa nada a la hora prevista.
- Credenciales caducadas. El backup se sube a un almacenamiento externo (S3, FTP, Drive) y la clave o el token expiró. El volcado se genera en local, pero la copia externa (la que de verdad te protege) lleva meses sin actualizarse.
La forma de detectarlo no es “confiar en que está programado”, sino mirar el último archivo real: su fecha de modificación y su tamaño. Si el backup más reciente es de hace tres meses, o pesa una fracción de lo que pesaban los anteriores, el proceso está roto por muy verde que se vea el panel. Esta comprobación cuesta treinta segundos y es la que más incidentes graves evita:
# ¿Cuándo se generó el último backup y cuánto pesa? (ordenado por fecha)
ls -lht /ruta/a/tus/backups | head
# El más reciente, con tamaño legible y fecha completa
ls -l --time-style=full-iso /ruta/a/tus/backups | tail -1Si ese archivo no es de hoy o de ayer (según tu cadencia), deja de leer y arregla el backup antes de seguir con nada más.
Cómo montar una prueba de restauración periódica
La prueba no es “abrir el archivo y ver que no da error”. Es rehacer, paso a paso, lo que harías el día de la catástrofe, y cada paso está ahí por un motivo concreto:
- Levanta un entorno de pruebas aislado, separado de producción, donde restaurar el backup sin ningún riesgo para el sitio real. El porqué: una restauración escribe base de datos y archivos; si la haces por error sobre el Moodle en uso, puedes machacar datos vivos o dejar
config.phpapuntando a la BD equivocada. El entorno aislado convierte un ensayo en algo inofensivo. - Restaura el backup completo (código, base de datos,
moodledata) siguiendo exactamente el mismo proceso que usarías en una recuperación real. El porqué: si el día del incidente vas a improvisar comandos que nunca has ejecutado, estás probando el procedimiento por primera vez bajo presión. El ensayo te da un guion escrito y validado, y saca a la luz los pasos que se te olvidan (permisos de carpetas,purge caches, el usuario de BD que no existe en el destino). - Verifica el acceso entrando como un usuario real de prueba, no solo mirando que la portada carga. El porqué: la portada puede renderizar con la BD a medias. Entrar con una cuenta comprueba que la tabla de usuarios, las sesiones y la autenticación sobrevivieron al volcado.
- Abre un curso con calificaciones y actividades y comprueba que el libro de calificaciones, las entregas y los archivos adjuntos siguen ahí. El porqué: las notas y las entregas viven repartidas entre la base de datos (registros) y
moodledata(los ficheros subidos). Es el punto donde más se nota un backup en el que una de las dos mitades quedó incompleta: ves el curso, pero las entregas dan error 404 o las notas están vacías. - Comprueba la fecha y el tamaño del backup contra lo esperado, un archivo anormalmente pequeño respecto a backups anteriores es una señal de alerta, aunque el proceso automático no haya mostrado ningún error. El porqué: el tamaño es el chivato más barato que tienes. Un volcado que pasa de 4 GB a 40 MB de un día para otro casi nunca es “hemos borrado datos”; es un proceso que se cortó a media ejecución.
- Documenta el resultado de cada prueba: fecha, qué se verificó, y cualquier incidencia encontrada, para tener un histórico de fiabilidad del proceso. El porqué: sin registro no puedes distinguir “hace un mes que funciona” de “nadie lo mira desde marzo”. El histórico también es lo que enseñas a un auditor o a un cliente cuando pregunta si sus datos están de verdad protegidos.
Cómo se genera un backup de servidor completo
Un backup completo tiene dos piezas que se copian por separado y con herramientas distintas: la base de datos y moodledata (el código de la aplicación se recupera reinstalando la misma versión, así que la copia crítica son los datos). Estos son los comandos de referencia, adapta rutas, nombres de base de datos y usuario a tu instalación, nunca los copies literalmente:
# 1) Volcado de la base de datos (Moodle usa MySQL/MariaDB en la mayoría de instalaciones)
# --single-transaction evita bloquear el sitio mientras se genera el volcado
mysqldump --single-transaction --routines --triggers \
-u USUARIO_BD -p NOMBRE_BD | gzip > moodle-bd-$(date +%F).sql.gz
# 2) Copia de moodledata (archivos subidos, backups de curso, caché de usuarios)
# -a preserva permisos; --delete mantiene el destino idéntico al origen
rsync -a --delete /ruta/a/moodledata/ /destino/backup/moodledata/El orden importa: el volcado de BD y la copia de moodledata deberían hacerse lo más juntos posible en el tiempo, para que los registros de la base de datos y los ficheros que referencian estén sincronizados. Un volcado de la BD de las 03:00 con un moodledata copiado a las 06:00 puede dejar entregas cuyo registro existe pero cuyo fichero aún no se había copiado, o al revés.
Con qué frecuencia probar la restauración y cuánto conservar
No hace falta probar cada backup diario individualmente, pero sí conviene establecer una cadencia regular (mensual, por ejemplo) para restaurar el backup más reciente disponible en ese momento y confirmar que el proceso sigue funcionando correctamente. Cualquier cambio relevante en la infraestructura (migración de servidor, actualización de versión, cambio de proveedor de backup) debería ir acompañado de una prueba de restauración inmediata, no esperar al ciclo regular.
La retención es la otra mitad de la cadencia. De poco sirve un backup diario si solo guardas el último: si un problema (una corrupción, un borrado) pasa desapercibido tres días, tu única copia ya es la copia del problema. Un esquema sensato y sencillo de mantener es conservar los últimos 7 diarios, unas 4 copias semanales y varias mensuales. Así siempre tienes un punto de recuperación anterior al momento en que algo se torció, y no dependes de darte cuenta el mismo día. Cuanto más silencioso pueda ser un fallo en tu plataforma, más profundidad de retención necesitas.
Dónde deben vivir los backups
Los backups nunca deberían almacenarse exclusivamente en el mismo servidor que protegen. Si el servidor completo falla (por un problema de hardware, un ataque, o un error humano), un backup guardado solo ahí desaparece junto con todo lo demás. Un almacenamiento externo, separado físicamente o al menos lógicamente del servidor de producción, es una condición básica para que el backup cumpla su función real. La referencia habitual es la regla 3-2-1: tres copias de los datos, en dos soportes distintos, con al menos una fuera del sitio.
Verificación de seguridad al restaurar: no solo integridad
Más allá de comprobar que los datos están completos, conviene verificar el origen de cualquier backup antes de restaurarlo, especialmente si no proviene del propio proceso automatizado del servidor. Existen vulnerabilidades documentadas relacionadas con archivos de copia de seguridad de Moodle manipulados maliciosamente que, al restaurarse, podrían llevar a la ejecución de código no autorizado, un motivo adicional para no restaurar backups de procedencia dudosa sin antes verificarlos en un entorno aislado.
Señales de que tu proceso de backup actual es poco fiable
- Nunca se ha realizado una restauración de prueba completa, ni una sola vez.
- Los backups se almacenan en el mismo servidor que protegen.
- No hay ningún registro documentado de cuándo se probó por última vez la restauración.
- El tamaño de los backups generados varía de forma inexplicable entre ejecuciones.
- Nadie tiene asignada la responsabilidad explícita de revisar que los backups siguen funcionando.
Preguntas frecuentes
¿Con qué frecuencia debería probar la restauración de mi backup? Como mínimo mensualmente, y siempre después de cualquier cambio relevante de infraestructura, versión o proveedor de backup.
¿Un backup automático que nunca ha fallado visiblemente es fiable? No necesariamente: muchos fallos de backup no generan ningún error visible durante la generación, solo se descubren al intentar restaurar.
¿Dónde deberían guardarse los backups de Moodle? Fuera del servidor de producción, en un almacenamiento separado, para que un fallo del servidor no afecte también a las copias de seguridad.
¿Qué pasa si mi backup es más pequeño de lo habitual? Es una señal de alerta que merece investigarse antes de asumir que todo está bien, puede indicar datos excluidos por error o un proceso incompleto.
¿Restaurar un backup de origen desconocido es peligroso? Sí, existen vulnerabilidades documentadas relacionadas con archivos de backup manipulados maliciosamente. Verifica siempre la procedencia antes de restaurar, especialmente en producción.
¿Necesito un entorno de pruebas dedicado solo para verificar backups? Es lo más seguro, aunque puede ser el mismo entorno de staging que usas para otras pruebas, siempre que esté correctamente aislado de producción.
¿Qué debo documentar después de cada prueba de restauración? La fecha de la prueba, qué se verificó exactamente, y cualquier incidencia encontrada, este histórico te permite detectar si la fiabilidad del proceso se degrada con el tiempo.
¿Un backup de curso (.mbz) me sirve como copia de seguridad del sitio?
No. El .mbz guarda el contenido de un curso, pero no los usuarios globales, la configuración del sitio, los plugins ni el resto de cursos. Es útil para migrar o clonar un curso, no para recuperar la plataforma tras un desastre. Para eso necesitas un backup de servidor completo: base de datos más moodledata.
¿Cómo sé si mi backup “programado” lleva meses sin generarse? Mira el archivo real, no el panel. Revisa la fecha de modificación y el tamaño del último backup: si no es reciente según tu cadencia, o pesa una fracción de los anteriores, el proceso está roto aunque nadie haya recibido un error. Disco lleno, cron parado y credenciales caducadas son las tres causas más frecuentes.
¿Tengo que copiar también el código de Moodle o basta con base de datos y moodledata?
Lo crítico e irremplazable es la base de datos y moodledata: son tus datos. El código de la aplicación puedes recuperarlo reinstalando la misma versión de Moodle. Aun así, copiar el código completo (incluidos plugins y temas) ahorra tiempo en la recuperación y evita olvidar qué versión y qué extensiones tenías instaladas.
¿Con qué herramientas se hace un backup de servidor completo?
Normalmente mysqldump (o mariadb-dump) para volcar la base de datos y rsync para copiar moodledata, ejecutados lo más juntos posible en el tiempo para que registros y ficheros queden sincronizados. Muchos paneles de hosting ofrecen snapshots que hacen ambas cosas a la vez; sigan valiendo las mismas reglas de verificación y retención.
Conclusión
Un backup que nunca se ha restaurado es, en la práctica, indistinguible de no tener backup, la única diferencia aparece el día que lo necesitas de verdad, y para entonces ya es tarde para corregirlo. Probar la restauración con regularidad es la única forma real de convertir “tenemos backups” en una garantía verificada, no en una suposición cómoda.
Si prefieres que alguien verifique esto por ti de forma sistemática, en Avantys incluimos pruebas de restauración periódicas como parte del mantenimiento de cada Moodle que gestionamos. Puedes pedir una auditoría gratuita en Moodle Gestionado.
Artículos relacionados
- Mantenimiento y hosting Moodle: guía completa
- Cómo proteger Moodle de ataques y vulnerabilidades
- Backup y restauración completa de un curso de Moodle
- Checklist de hardening de Moodle
¿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.
