Copias de seguridad y restauración en Drupal: cómo montar una estrategia de backup fiable para tu web corporativa

Hay dos tipos de administradores de sistemas: los que hacen copias de seguridad y los que las van a empezar a hacer justo después del primer susto serio. Yo tardé un viernes por la tarde, una actualización de módulo mal dada y un cliente nervioso al teléfono en pasar del segundo grupo al primero. La web corporativa estaba caída, el último backup "decente" tenía once días y, para rematar, cuando fui a restaurarlo descubrí que el volcado de la base de datos estaba truncado. Ese día aprendí la lección que da título a media de este artículo: un backup que no has probado, en la práctica, no existe.

Si gestionas una web en Drupal 10 u 11 para tu empresa, lo que viene es la guía que me habría gustado tener antes de aquel viernes. Nada de teoría abstracta: qué tienes que respaldar de verdad, cada cuánto, con qué herramientas y, sobre todo, cómo asegurarte de que esas copias sirven el día que arde algo.

Qué hay que respaldar en una web Drupal (y no es solo la base de datos)

El error más común es pensar que "hacer backup de Drupal" equivale a exportar la base de datos. Es la pieza más importante, sí, pero una web Drupal son cuatro cosas distintas y necesitas las cuatro para reconstruirla entera.

La base de datos

Aquí vive casi toda tu web: contenidos (nodos, párrafos, comentarios), usuarios y permisos, taxonomías, el estado del sistema, los datos de los módulos. Si pierdes la base de datos, pierdes el grueso del trabajo. Es lo que respaldas con más frecuencia porque es lo que más cambia.

La carpeta de ficheros subidos

En Drupal los archivos que sube la gente (imágenes, PDFs, documentos adjuntos) no están en la base de datos, sino en el sistema de ficheros, normalmente en sites/default/files. La base de datos solo guarda la referencia a esos archivos. Si restauras la base de datos pero olvidas la carpeta files/, tendrás una web llena de imágenes rotas y descargas que dan 404. Lo he visto pasar más de una vez.

El código y las dependencias

El código de Drupal (el core, los módulos contribuidos, tu tema, los módulos a medida) idealmente vive en un repositorio Git y se reconstruye con Composer. Lo crítico aquí son composer.json y composer.lock: ese par de archivos describe exactamente qué versiones tienes instaladas. Con ellos puedes regenerar el directorio vendor/ y todo el árbol de dependencias sin sorpresas. Si trabajas con Git y despliegues, esta parte ya la tienes medio resuelta; aun así conviene tenerla contemplada en el plan, no darla por hecha.

La configuración

Desde Drupal 8 la configuración del sitio (vistas, tipos de contenido, campos, ajustes de módulos) se puede exportar a archivos YAML con drush config:export. Si versionas esa configuración en Git, tienes una capa de seguridad adicional muy potente: puedes reconstruir cómo está montada la web sin depender únicamente del volcado de base de datos. No sustituye al backup completo, pero lo complementa de maravilla.

La regla 3-2-1, sin misticismos

La famosa regla 3-2-1 no es un dogma de gurú, es sentido común envuelto en una cifra fácil de recordar:

• 3 copias de tus datos (la de producción más dos backups).
• 2 soportes o medios distintos (por ejemplo, el disco del servidor y un almacenamiento de objetos).
• 1 copia fuera de las instalaciones, en otra ubicación física o en otro proveedor.

¿Por qué el "1 fuera"? Porque si tu backup está en el mismo servidor que la web, el día que se corrompe el disco, alguien borra el directorio equivocado o el proveedor tiene un incidente serio, te quedas sin web y sin copia a la vez. Que se lo pregunten a quienes tenían todo en el mismo datacenter el día del incendio de OVH en Estrasburgo en 2021. La copia externa es justo lo que te salva de los desastres de los que nadie se cree que vayan a pasarle.

Frecuencia y retención: cada cuánto y cuánto tiempo guardar

No hay una respuesta única; depende de cuánto cambian tus datos y de cuánto te dolería perderlos. Un punto de partida razonable para una web corporativa típica:

• Base de datos: copia diaria. Si es un portal con mucha actividad (e-commerce, intranet, formularios constantes), pásate a varias al día.
• Carpeta files/: diaria o cada pocos días, según cuánto se suba. Aquí van bien las copias incrementales para no mover gigas a diario.
• Código y configuración: cada despliegue queda registrado en Git, así que tu historial de commits ya es tu "backup" de esta capa.

Para la retención, un esquema clásico que funciona muy bien es el de abuelo-padre-hijo: guardas las copias diarias de la última semana, una semanal del último mes y una mensual de los últimos seis meses o un año. Así cubres tanto el "ayer borré algo sin querer" como el "hace tres meses se coló un contenido que necesito recuperar". Define la retención por escrito y deja que el sistema borre las copias viejas solo; los discos llenos de backups antiguos son otra forma de quedarte sin sitio para el backup de esta noche.

Herramientas para hacer backup en Drupal

Tienes varias opciones, y lo normal es combinar un par de ellas.

Drush (la navaja suiza del sysadmin de Drupal)

Para volcar la base de datos desde línea de comandos, Drush es directo y fiable. Un volcado comprimido se hace así:

drush sql-dump --gzip --result-file=/var/backups/drupal/db-$(date +%F).sql.gz

Eso te deja un archivo con la fecha en el nombre, comprimido, listo para mover a otro sitio. Para la carpeta de ficheros, un rsync o un tar del directorio sites/default/files completa la foto.

Backup and Migrate

Es el módulo de toda la vida para quien prefiere gestionar las copias desde la propia interfaz de Drupal. Permite programar backups de base de datos y ficheros, definir perfiles y enviar las copias a destinos externos. Cómodo para equipos que no quieren vivir en la terminal, aunque para volúmenes grandes suele rendir mejor un script bien hecho a nivel de servidor.

Snapshots del hosting

Muchos proveedores ofrecen snapshots automáticos del servidor o instantáneas a nivel de disco. Están bien como red de seguridad adicional y son rapidísimos de restaurar, pero ojo: un snapshot del proveedor vive en el proveedor. No cumple por sí solo el "1 fuera" de la regla 3-2-1, y si pierdes acceso a la cuenta, lo pierdes con ella. Úsalos como complemento, nunca como tu única defensa.

Cron, para que no dependa de tu memoria

El backup que depende de que alguien se acuerde de lanzarlo está condenado. Programa la tarea con cron y olvídate:

0 3 * * * /usr/local/bin/backup-drupal.sh >> /var/log/backup-drupal.log 2>&1

Esa línea ejecuta tu script de copia todas las noches a las tres de la madrugada y guarda un registro. Dentro del script metes el drush sql-dump, el rsync de files/ y el envío al almacenamiento externo. Tres líneas que te ahorran disgustos.

Automatización y almacenamiento externo

La automatización es lo que separa una estrategia real de una buena intención. El objetivo es que, sin que nadie toque nada, cada noche se genere la copia, se comprima, se cifre si toca, se suba a un destino externo y se borren las copias que ya han caducado.

Para el almacenamiento externo, las dos vías más habituales:

• Otro servidor o NAS: si tienes infraestructura propia, mandar las copias por rsync a una máquina distinta (mejor en otra ubicación) es barato y efectivo.
• Almacenamiento de objetos tipo S3: Amazon S3, o compatibles europeos como los de OVH, Scaleway o cualquier proveedor con S3-compatible, son ideales para backups. Pagas por lo que usas, defines reglas de ciclo de vida para mover copias viejas a almacenamiento frío más barato y tienes durabilidad altísima. Una herramienta como rclone te sube el directorio de copias a S3 en una sola línea dentro del script.

Si tus datos son de clientes europeos, elegir un proveedor con servidores en la UE te ahorra dolores de cabeza de cumplimiento. Lo retomo en un momento.

Lo que casi todo el mundo olvida: probar la restauración

Llegamos a la parte que da nombre a este artículo y que, sinceramente, es la más importante de todas. Puedes tener backups diarios, cifrados, replicados en tres continentes... y no servir de nada si nunca has comprobado que se pueden restaurar.

Un backup no verificado no es un backup, es una esperanza. Y la esperanza no levanta una web caída.

Restaura de verdad, en un entorno de staging

La forma seria de comprobarlo es montar un entorno de staging o pruebas y restaurar ahí la copia completa: base de datos, ficheros, código reconstruido con Composer y configuración. Si la web levanta, navega bien, las imágenes cargan y puedes entrar como administrador, tu copia vale. Si algo falla, mejor descubrirlo un martes tranquilo que un viernes en llamas.

La restauración de una base de datos volcada con Drush es tan sencilla como esto en el entorno de pruebas:

gunzip < db-2026-06-09.sql.gz | drush sql-cli

Después, un drush cache:rebuild y a comprobar que todo está en su sitio.

Conviértelo en rutina

Marca en el calendario una prueba de restauración periódica, trimestral como mínimo. Apunta cuánto se tarda en dejar la web operativa: ese número es tu tiempo real de recuperación, y conocerlo cambia por completo las conversaciones con dirección cuando hay un incidente. Documenta los pasos para que cualquiera del equipo pueda ejecutar la restauración, no solo la persona que montó todo y que justo ese día está de vacaciones en la otra punta del país.

RGPD y cifrado: las copias también guardan datos personales

Aquí entra un detalle que muchos pasan por alto. Las copias de seguridad de una web corporativa contienen casi siempre datos personales: usuarios registrados, formularios de contacto, pedidos, comentarios. Y el RGPD no se olvida de las copias por el hecho de que estén comprimidas en un rincón.

Algunas implicaciones prácticas:

• Cifra las copias que contengan datos personales, tanto en tránsito como en reposo. Si una copia viaja a S3, que vaya cifrada; si vive en un disco, que el almacenamiento esté cifrado. Una herramienta como gpg o el cifrado nativo del bucket te lo resuelven.
• Controla el acceso: solo quien deba debe poder leer esas copias. Un backup con todos los datos de tus clientes accesible a medio mundo es una brecha de seguridad esperando a ocurrir.
• Aplica la retención también por privacidad: guardar copias indefinidamente choca con el principio de limitación del plazo de conservación. Borra las viejas, no solo por espacio.
• Ubicación de los datos: si usas almacenamiento externo, ten claro dónde se guardan físicamente las copias, sobre todo si el proveedor está fuera de la UE.

El cifrado, además, te protege del escenario incómodo de que alguien acceda a tus backups: si están cifrados con una clave que solo tú controlas, el contenido sigue a salvo.

Un plan de backup que de verdad funcione

Recapitulando lo esencial sin florituras: respalda las cuatro capas (base de datos, ficheros, código con su composer.lock y configuración), aplica la regla 3-2-1 con al menos una copia fuera, define frecuencia y retención por escrito, automatiza todo con Drush y cron para no depender de la memoria de nadie, manda las copias cifradas a un almacenamiento externo y, lo más importante, prueba la restauración en staging cada cierto tiempo. Un backup que no has restaurado nunca es una lotería, y en producción no se juega a la lotería.

La buena noticia es que montar esto una vez bien hecho te deja tranquilo durante años. La mala es que improvisarlo el día del incidente sale carísimo, en horas, en dinero y en confianza del cliente.

Si quieres asegurarte de que tu web Drupal corporativa está realmente protegida y no solo "tiene backups por ahí", en Tangram revisamos juntos tu estrategia de copias y te ayudamos a dejarla a prueba de viernes por la tarde.