Durante un incidente real
Compruebo que hay una copia, pero nadie ha medido cuánto tarda en restaurarse ni ha registrado los permisos y el orden de recuperación. Durante el incidente, pierdo tiempo averiguándolo.
Moodle · Continuidad
Tener copias de seguridad y poder recuperar el servicio son dos cosas distintas
Encuentro a menudo organizaciones que hacen copias, pero no han medido cuánto tardarían en recuperar el servicio, cuántas horas de trabajo podrían perder ni si cada copia es coherente consigo misma. Coordino la copia de la base de datos y de los ficheros en un punto coherente y registro la versión exacta del código y la configuración necesarios para restaurarlo. Si los datos y los ficheros se capturan sin esa coordinación, la base de datos puede referirse a un fichero que todavía no estaba en el almacén. Por eso no pregunto «¿hacéis copias?», sino «¿cuándo restaurasteis una por última vez y comprobasteis que el campus funcionaba?».
- Copio tres cosas: base de datos, ficheros subidos y código. Las dos primeras cambian a diario y son las que dan problemas.
- La base de datos debe obtenerse como una instantánea coherente; en MySQL o MariaDB, la opción de transacción única ayuda con las tablas transaccionales. Esa medida no coordina por sí sola la base de datos con moodledata: la coherencia entre ambas copias requiere un procedimiento adicional y debe demostrarse durante la restauración.
- Sin objetivo de tiempo de recuperación ni de pérdida asumible, no hay forma de saber si la estrategia sirve.
- Una copia que no se ha restaurado es una suposición, no una garantía.
Experiencia en continuidad
Copio la base de datos, los ficheros subidos, el código y la configuración con un punto de consistencia común. Fijo los objetivos de recuperación, separo las copias del sistema original y pruebo la restauración para comprobar que el servicio puede volver con datos coherentes.
Mi trayectoriaCuándo descubro el problema
A menudo descubro en un momento crítico que nadie había probado antes la recuperación.
Restauro y descubro que faltan ficheros
Encuentro en la base de datos referencias a archivos que no están en el almacén. He visto este desajuste cuando las dos piezas se copiaron con horas de diferencia mientras la plataforma seguía en uso.
Cuando alguien borra algo por error
He comprobado que recuperar solo un curso, una categoría o unas calificaciones, sin devolver toda la plataforma a ayer, es mucho más difícil de lo que cualquiera habría supuesto.
En una auditoría o certificación
Me piden el procedimiento, los plazos comprometidos y la evidencia del último ensayo. Compruebo que las tres cosas suelen faltar a la vez.
Lo que suele fallar
Seis fallos que he visto convertir una copia existente en una recuperación imposible.
Base de datos y ficheros copiados en momentos distintos
Es el fallo que más veces me he encontrado y el más difícil de detectar hasta que toca restaurar. Diseño la consistencia entre las dos piezas a propósito, no la doy por hecha.
La copia vive en el mismo sitio que el original
Un fallo del almacenamiento, un borrado accidental o un cifrado malicioso se llevan las dos cosas por delante.
Nadie vigila que la copia se haya hecho
El proceso lleva semanas fallando en silencio. Sin una alerta cuando no termina, la primera noticia llega el día del incidente.
El código y las extensiones no están bajo control de versiones
Restauro la base de datos sin conocer la versión exacta ni las extensiones con las que funcionaba. La plataforma no arranca o funciona mal.
El periodo de conservación no cubre el tiempo necesario para detectar un problema
Si guardo solo siete días de copias y descubro una corrupción a las tres semanas, ya están todas contaminadas.
Nadie ha cronometrado la restauración
Ensayo la restauración y obtengo el dato real: frente a una recuperación prometida en dos horas, el volcado tarda cinco en cargarse.
Qué copio y cómo demuestro que se puede recuperar
Trabajo con tres componentes y una prueba de restauración. Mantengo coherentes la base de datos y el directorio de datos porque un desajuste entre ambos puede arruinar la recuperación.
- 01
La base de datos
La base de datos contiene usuarios, cursos, calificaciones, intentos, configuración y las referencias a los ficheros. En MySQL y MariaDB, obtengo una vista coherente de las tablas transaccionales con una única transacción de la herramienta de volcado, aunque continúen las escrituras. Así no congelo la aplicación. Confirmo el motor de cada tabla y evito cambios de esquema durante la copia, porque ambas condiciones pueden romper la coherencia esperada.
- 02
Los ficheros subidos
El directorio de datos guarda lo que suben las personas, y la base de datos apunta a esos archivos por su identificador. Hago que la copia de la base de datos y la de moodledata representen el mismo punto lógico mediante un procedimiento coordinado, y compruebo esa coherencia durante la restauración; iniciarlas a la vez, por sí solo, no basta.
- 03
El código y la configuración
Copio el código y la configuración con menos frecuencia porque cambian poco, pero sin ambos no puedo arrancar la plataforma. Incluyo la versión exacta del núcleo, las extensiones instaladas y el fichero de configuración.
- 04
La restauración
La prueba de restauración es la única parte que demuestra que lo anterior sirve. Restauro la copia en un entorno aparte, arranco la plataforma, entro, abro un curso y compruebo que los ficheros se descargan. Si no ensayo la restauración, no sé cuánto tarda.
Cómo fijar la estrategia
Planteo cinco preguntas y acuerdo las respuestas con quien asume el riesgo, no con quien administra el servidor.
- 01
¿Cuánto tiempo puede estar parado el campus?
Tomo ese número como objetivo de tiempo de recuperación y diseño toda la arquitectura a partir de él. Un objetivo de cuatro horas y otro de quince minutos requieren soluciones y presupuestos completamente distintos.
- 02
¿Cuánto trabajo se puede perder?
Tomo esa respuesta como punto de recuperación. Si me dicen «ninguno el día del examen», descarto la copia nocturna y recurro al registro continuo.
- 03
¿Hay que poder recuperar solo una parte?
Restauro un curso borrado sin devolver toda la plataforma al estado del día anterior. Para ello, aplico una estrategia distinta de la copia completa del sitio.
- 04
¿Quién ejecuta la recuperación y a qué hora?
He comprobado que, si el procedimiento depende de una persona concreta con acceso, el plazo real lo marca su disponibilidad, no el plazo técnico.
- 05
¿Cuándo se ensayó por última vez?
Trato el plazo comprometido como una estimación cuando me responden «nunca» o «hace años». Los ensayos convierten ese compromiso en un dato.
Diez preguntas sobre vuestras copias
La cuarta y la décima son las que más veces encuentro sin respuesta.
- Sé qué se copia exactamente: base de datos, ficheros y código.
- La base de datos y los ficheros se copian de forma coherente entre sí.
- Las copias salen del servidor y viven en otro sitio.
- La última restauración completa se hizo y se cronometró en una fecha que puedo decir.
- Existe una alerta cuando la copia no termina bien.
- Sé cuánto tiempo puede estar parada la plataforma antes de que sea un problema.
- Sé cuántas horas de trabajo se pueden perder sin consecuencias.
- Puedo recuperar un curso borrado sin devolver toda la plataforma atrás.
- La retención cubre el tiempo que tardaría en detectarse un problema silencioso.
- La recuperación no depende de que una persona concreta esté disponible.
Qué cambia con el tamaño
Mido cuánto tarda la estrategia a medida que crece el volumen: el tiempo me indica cuándo deja de servir.
- Bases de datos pequeñas
El volcado completo nocturno entra de sobra en la ventana y la restauración tarda minutos. Saco la copia de la máquina y compruebo que alguien la vigile.
- Cuando el volcado ya no cabe en la ventana
Al llegar a ese límite, paso a copias incrementales o a instantáneas coherentes. He comprobado que insistir en el volcado completo puede perjudicar el rendimiento nocturno.
- Ficheros de gran volumen
En instalaciones con mucho contenido audiovisual, el directorio de datos puede crecer más rápido que la base de datos. Mido ambos por separado y, cuando la copia completa deja de caber en la ventana, paso a sincronización incremental con verificación.
- Varias instalaciones
Replico la estrategia en cada entorno y compruebo si puedo recuperar una organización sin tocar las demás.
Qué exigir sobre continuidad en un pliego
Exijo que consten los plazos y quede constancia del ensayo. Sin ambas cosas, «se harán copias» no compromete a nada.
| Requisito | Evidencia exigible | Criterio de aceptación |
|---|---|---|
| Objetivos de recuperación por escrito | Tiempo máximo de parada y pérdida máxima de datos asumible | Cifras acordadas y reflejadas en el documento que fija los compromisos |
| Consistencia de la copia | Procedimiento que garantice coherencia entre base de datos y ficheros | Restauración de prueba sin referencias a ficheros ausentes |
| Ensayo periódico de restauración | Informe del último ensayo con fecha y tiempos reales | Al menos un ensayo completo al año, con acta |
| Recuperación parcial | Procedimiento para recuperar un curso o un dato concreto | Demostración sobre un curso de prueba |
| Copias fuera del entorno principal | Ubicación y política de retención | Copia accesible aunque el entorno principal no esté disponible |
Supuestos que he visto dar por buenos
Tres creencias razonables que he visto fallar justo cuando más falta hacía que fueran ciertas.
La instantánea de la máquina virtual basta
Con esta copia restauro el servidor entero, pero no un curso concreto ni un dato suelto. Si la hago con la plataforma en uso, puedo capturar la base de datos a medias.
Las copias automáticas de cursos son la copia de seguridad
Restauro contenido con las copias automáticas de los cursos, pero no sustituyo con ellas la copia del sitio. Si las configuro para ello, incluyen a las personas matriculadas y parte de sus datos. Aun así, no cubren la configuración global ni todo lo que queda fuera de los cursos.
El proveedor de alojamiento ya hace las copias
No doy por resuelta la cuestión aunque el proveedor de alojamiento haga las copias. Compruebo qué plazo garantiza, qué contiene la copia, quién puede iniciar la restauración y cuánto tarda. Sin esa información, la organización conserva la responsabilidad, pero carece de los datos necesarios para ejercerla.
Referencias
Fuentes y límites
- Documentación oficialCopia de seguridad del sitio — documentación oficial de Moodle
Las tres piezas a copiar y la recomendación de usar opciones que garanticen la consistencia del volcado. Consultado el 1 de agosto de 2026.
- Documentación oficialRestauración del sitio — documentación oficial de Moodle
Procedimiento de restauración completa de una instalación. Consultado el 1 de agosto de 2026.
- Documentación oficialCopia automática de cursos — documentación oficial de Moodle
Qué cubre la copia automática de cursos, que no equivale a la copia del sitio. Consultado el 1 de agosto de 2026.
Las tres piezas que hay que copiar —base de datos, ficheros y código— son las mismas en las plataformas derivadas de Moodle, como Totara u Open LMS, aunque la ruta del directorio de datos y las herramientas de despliegue cambien. En un servicio gestionado, además, parte de este procedimiento lo ejecuta el proveedor y conviene saber exactamente qué parte. Conviene declarar una diferencia: la documentación oficial detalla qué copiar y cómo hacerlo de forma coherente, pero no insiste en ensayar la restauración. La exigencia de restaurar periódicamente y cronometrarlo es criterio propio, formado en incidentes reales donde la copia existía y el plazo prometido no se pudo cumplir. Los objetivos de recuperación concretos dependen de cada organización y ninguna cifra de esta página debe tomarse como referencia sectorial.
Blog
Casos, pruebas y fuentes.
En el blog desarrollo casos particulares, pruebas y fuentes que amplían esta página de referencia.
Ir a blog.albertolarah.comContacto
Cuánto se tarda en volver cuando algo se cae
Miro qué se copia, con qué frecuencia y dónde se guarda, y cuándo fue el último ensayo de restauración. Sobre todo, cuánto tiempo puede estar parada la plataforma antes de que sea un problema para la organización.
hola@albertolarah.comLinkedIn ↗