Cuando el sitio web de una universidad se cae durante horas, no se trata solo de un incidente técnico: afecta directamente a los procesos de solicitud, los portales de estudiantes, los flujos de pago y la reputación de la institución. Drupal es un sistema de gestión de contenido potente y seguro, pero ninguna infraestructura es totalmente inmune a errores humanos, fallos de hardware o ciberataques. Por eso, las copias de seguridad y la recuperación ante desastres son componentes esenciales de cualquier sitio web institucional basado en Drupal.
En esta guía repasamos qué cubre realmente la copia de seguridad en Drupal, qué herramientas se pueden utilizar, conceptos clave como RTO y RPO, escenarios críticos de recuperación ante desastres para instituciones de educación superior, y cómo el enfoque de drupal4edu construye un plan de protección de extremo a extremo.
¿Qué es la copia de seguridad en Drupal y por qué es importante?
La copia de seguridad en Drupal es el proceso de crear regularmente copias seguras de todos los componentes que el sitio necesita para seguir funcionando. Copiar solo los archivos o extraer únicamente un volcado de la base de datos produce una copia de seguridad incompleta. Una copia de seguridad completa de Drupal cubre tres capas fundamentales:
- Base de datos: aquí residen todo el contenido, la información de usuarios, la configuración y los datos de sesión. Sin un volcado de la base de datos, no es posible restaurar el contenido.
- Archivos de usuario: imágenes, PDFs, materiales de curso, fotos del profesorado — todo el contenido multimedia subido. Normalmente se encuentran en
sites/default/files. - Código y configuración: el núcleo de Drupal, los módulos, el código personalizado, los archivos de tema y los archivos de configuración exportada (config sync).
La copia de seguridad no es solo una red de protección ante desastres — también desempeña un papel fundamental en las operaciones planificadas. Antes de una actualización del núcleo de Drupal, al instalar un nuevo módulo, al realizar cambios masivos en las estructuras de permisos o en las configuraciones de visualización, o antes de una migración importante de contenido, se recomienda encarecidamente hacer una copia de seguridad. Incluso las actualizaciones bien probadas pueden comportarse de forma impredecible en un entorno de producción con código personalizado.
¿Por qué es tan importante?
La pérdida de datos no suele empezar con un ciberataque: empieza con un error humano, una actualización fallida, la corrupción del almacenamiento o una interrupción por parte del proveedor de hosting. Por eso "tenemos una copia de seguridad" no es suficiente. Lo que realmente importa es dónde se almacena esa copia, con qué frecuencia se ejecuta y con qué frecuencia se prueba.
Copia de seguridad y recuperación ante desastres no son lo mismo
Estos dos términos suelen usarse indistintamente, pero son conceptos diferentes. La copia de seguridad es el acto de crear una copia de los datos. Un plan de recuperación ante desastres es el conjunto completo de procedimientos que se siguen para restablecer un sitio, con un nivel de servicio definido, dentro de un plazo de tiempo determinado tras una interrupción.
Dicho de otro modo: una copia de seguridad es un archivo; un plan de recuperación ante desastres es un documento escrito. El plan define claramente quién hace qué y cuándo, dónde se almacenan las copias de seguridad, cuánto tiempo tarda la restauración y qué nivel de pérdida de datos es aceptable.
RTO y RPO: las dos métricas clave de la recuperación ante desastres
Un plan de recuperación ante desastres profesional cuenta con dos parámetros críticos:
- RTO (Recovery Time Objective, tiempo objetivo de recuperación): el tiempo máximo aceptable para que el sistema vuelva a estar operativo. Por ejemplo, si el RTO es de 2 horas, el sitio debe volver a estar en línea dentro de las 2 horas siguientes a una interrupción.
- RPO (Recovery Point Objective, punto objetivo de recuperación): la ventana máxima aceptable de pérdida de datos. Si el RPO es de 1 hora, la pérdida de datos que se puede asumir tras la restauración es como máximo de una hora, lo que significa que las copias de seguridad deben ejecutarse al menos cada hora.
En el caso de los sitios universitarios, estas métricas deben definirse de forma más estricta a medida que se acercan los periodos de matriculación, la publicación de resultados de exámenes o los procesos de acreditación. Un sitio que se cae el día de la solicitud daña, de un solo golpe, tanto la experiencia del futuro estudiante como la reputación de la institución.
La regla de copia de seguridad 3-2-1: el estándar del sector
En el mundo de las copias de seguridad, la regla 3-2-1 es el estándar de referencia:
- Debe haber al menos 3 copias de los datos (1 principal, 2 de respaldo).
- Estas copias deben residir en al menos 2 soportes o dispositivos distintos.
- Al menos 1 copia debe conservarse fuera de las instalaciones (offsite).
En el caso de Drupal, esta regla funciona en la práctica así: la primera copia reside en el servidor de producción que ejecuta el sitio, la segunda copia en un servidor de copia de seguridad independiente o en un servicio de almacenamiento en la nube (como Amazon S3 o Azure Blob), y la tercera copia en una ubicación completamente distinta. Una copia de seguridad almacenada en el mismo servidor deja de ser una copia de seguridad en el momento en que el servidor falla.
Métodos de copia de seguridad para sitios Drupal
El ecosistema de Drupal ofrece varios métodos de copia de seguridad. Cuál elegir depende del tamaño del sitio, el tráfico, la capacidad técnica del equipo y la infraestructura de hosting.
Módulo Backup and Migrate
El módulo de copia de seguridad más conocido de Drupal. Admite copias de seguridad de base de datos, archivos y código, definiciones de copia de seguridad programadas, compresión gzip/bzip/zip y cifrado opcional. La interfaz funciona bien en sitios pequeños y medianos, pero, como almacena las copias de seguridad íntegramente en el servidor de producción, no resulta suficiente por sí sola como solución de recuperación ante desastres. Si el servidor se cae, también se pierde el acceso a las copias de seguridad.
Copia de seguridad por línea de comandos con Drush
Drush es la herramienta de línea de comandos de Drupal. Comandos como drush sql-dump para volcados de base de datos y drush archive-dump para archivar código y base de datos juntos permiten scriptar un flujo completo de copia de seguridad. Combinado con cron en el servidor, se puede construir un pipeline de copia de seguridad automatizado y programable. Es una opción orientada a desarrolladores y más fiable que las soluciones basadas en módulos para sitios de gran tamaño.
Copias de seguridad a nivel de servidor (snapshots)
Este es el método de copia de seguridad basado en instantáneas de disco que ofrecen los proveedores de hosting o las plataformas en la nube. Plataformas Drupal gestionadas como Pantheon, Acquia y Platform.sh proporcionan copias de seguridad automatizadas basadas en snapshots. La ventaja: captura una imagen del servidor completo en un momento determinado. La desventaja: algunos proveedores utilizan estas copias de seguridad únicamente para sus propios procesos internos de recuperación ante desastres, lo que significa que no dan al propietario del sitio acceso a restauraciones puntuales. Esto es algo que conviene verificar antes de firmar cualquier contrato.
Módulo Restic Backup
El módulo Restic Backup ofrece un enfoque más moderno y resulta especialmente eficaz para la copia de seguridad de archivos subidos. Las copias de seguridad incrementales y la deduplicación mantienen bajos los costes de almacenamiento. Puede realizar copias de seguridad hacia destinos SFTP o S3. Para sitios universitarios con grandes bibliotecas multimedia, una combinación de Git para el código, Retention Database Backup para la base de datos y Restic para los archivos ofrece una protección integral.
Frecuencia de copia de seguridad y política de retención
La frecuencia de las copias de seguridad depende de la rapidez con la que cambia el sitio. Para un portal universitario con actualizaciones de contenido regulares y muchos usuarios simultáneos, una política de retención práctica podría ser esta:
| Tipo de copia | Frecuencia | Periodo de retención |
|---|---|---|
| Diaria | Cada día | Últimos 7 días |
| Semanal | Cada semana | Últimas 4 semanas |
| Mensual | Mensual | Últimos 6–12 meses |
| Basada en eventos | Antes de actualizaciones/migraciones | Hasta que finalice la tarea correspondiente |
Esta política puede ajustarse aún más según la rapidez con la que cambie el sitio y la sensibilidad de los datos. En los días de publicación de resultados de exámenes o durante los periodos de matriculación, por ejemplo, tiene sentido reducir el intervalo de copia de seguridad a solo unas horas.
Copia de seguridad de Drupal en la educación superior: ¿qué cambia?
Un sitio corporativo y un sitio universitario pueden parecer tener necesidades de copia de seguridad similares a primera vista, pero los detalles de implementación difieren de forma significativa.
- Arquitectura multisite: las universidades suelen alojar decenas de subsitios para el sitio principal, las facultades, los institutos, la biblioteca y los centros de investigación. Cada uno necesita su propia política de copia de seguridad, pero todos deben gestionarse bajo un marco unificado de recuperación ante desastres.
- Integración con LMS: en los sitios Drupal integrados con Moodle, Canvas o plataformas LMS institucionales, la copia de seguridad debe capturar de forma consistente los parámetros de integración y las cachés.
- Datos personales y normativa: los datos de los estudiantes están sujetos a normativa de protección de datos. En los campus de la UE se aplica el RGPD (GDPR), desarrollado en España a través de la LOPDGDD (Ley Orgánica de Protección de Datos Personales y Garantía de los Derechos Digitales); en Estados Unidos se aplica la FERPA; en California, la CCPA; y otras regiones cuentan con sus propios marcos normativos. Las copias de seguridad deben estar cifradas y con acceso controlado.
- Ventanas de tráfico punta: durante los periodos de matriculación, los días de solicitud o la publicación de resultados de exámenes, los umbrales de RTO/RPO deben ajustarse de forma más estricta. El coste de una interrupción durante estas ventanas es varias veces superior al de un día normal.
- Acreditación y auditorías: auditorías como ABET, AACSB u organismos regionales de acreditación pueden exigir que el historial de contenido del sitio se conserve y pueda recuperarse. Aquí resultan esenciales las copias de seguridad de archivo a largo plazo.
Plan de recuperación ante desastres de Drupal, paso a paso
Una copia de seguridad por sí sola no es un plan de recuperación ante desastres. Los pasos siguientes ofrecen un marco de recuperación ante desastres aplicable a escala universitaria.
- Haz un inventario de los activos críticos. Enumera qué sistemas (sitio principal, portal de solicitudes, biblioteca, antiguos alumnos) se encuentran en qué nivel de prioridad.
- Define los valores de RTO y RPO para cada sistema. Esto determina directamente la frecuencia de las copias de seguridad y la elección de tecnología.
- Construye tu arquitectura de copia de seguridad en torno al principio 3-2-1: producción, servidor independiente o nube, y offsite.
- Cifra tus copias de seguridad. Es un requisito de cumplimiento del RGPD, la FERPA y normativas similares — y, en cualquier caso, una copia de seguridad filtrada supone un riesgo de seguridad importante.
- Documenta el procedimiento de restauración. ¿Quién hace qué y en qué orden? Si la persona responsable está de vacaciones, ¿quién se hace cargo?
- Prueba el plan de recuperación ante desastres con una periodicidad regular. Un plan que solo existe sobre el papel suele fallar cuando llega una crisis real.
- Intégralo con el control de versiones. Gestiona tu código en Git, de modo que las copias de seguridad solo necesiten cubrir la base de datos y los archivos.
- Prepara un plan de comunicación. Diseña de antemano cómo se informará a estudiantes, profesorado y prensa durante una interrupción del servicio.
No confíes en copias de seguridad que no has probado
Si tuviéramos que resumir en una sola frase la lección más costosa de este sector, sería esta: una copia de seguridad sin probar no es una copia de seguridad. Muchos equipos han estado ejecutando copias de seguridad durante años, solo para descubrir, en su primer intento de restauración real, que la copia estaba corrupta, incompleta o correspondía a la versión equivocada.
La solución es sencilla. Con una periodicidad regular (trimestral, por ejemplo), restaura un archivo de copia de seguridad real en un entorno de staging. En el sitio restaurado, verifica uno por uno la integridad del contenido, las sesiones de usuario, la configuración y las integraciones. Documenta los resultados, resuelve cualquier problema detectado y mantén un registro histórico de las pruebas.
Errores comunes en las copias de seguridad
- Guardar las copias de seguridad en el mismo servidor: si el servidor se cae, también se pierde el acceso a las copias de seguridad.
- Hacer copia de seguridad solo de la base de datos: sin el código y los archivos de usuario, el sitio no se puede restaurar.
- No cifrar las copias de seguridad: una copia de seguridad filtrada causa un daño equivalente a una brecha en producción.
- No documentar el procedimiento de restauración: improvisar durante una crisis aumenta el riesgo de errores.
- No probar las copias de seguridad: una copia de seguridad defectuosa puede ser más peligrosa que no tener ninguna.
- Descuidar la elección de la herramienta adecuada: las copias de seguridad basadas en módulos se quedan cortas en algunos escenarios críticos — deben combinarse con copias de seguridad a nivel de servidor.