Una copia de seguridad que nunca se ha restaurado no es una copia: es una hipótesis. Muchos sitios en producción dependen de un único volcado nocturno alojado en el mismo servidor que los datos que debe proteger, algo que no sobrevive ni a un fallo de disco, ni a un cifrado por ransomware, ni a una maniobra equivocada. Este artículo plantea un método probado para construir una estrategia de copias fiable y, sobre todo, para demostrar que funciona.
La regla 3-2-1 y por qué sigue vigente
La regla 3-2-1 cabe en una frase: tres copias de los datos, en dos soportes diferentes, una de ellas fuera del sitio. Tiene más de veinte años y sigue siendo la referencia porque no protege frente a un riesgo, sino frente a toda una familia de ellos.
| Principio | Qué cubre | Ejemplo concreto |
|---|---|---|
| 3 copias | La corrupción silenciosa y el error humano | Producción + copia local + copia remota |
| 2 soportes | El fallo material de un tipo de soporte | Disco del servidor + almacenamiento de objetos |
| 1 fuera del sitio | El siniestro físico y el ransomware | Bucket S3 en otra región, de solo escritura |
La copia fuera del sitio es la que más se descuida, y es justamente la que salva ante un incendio de la sala de servidores o un cifrado malicioso que alcanza todo lo montado localmente. Una variante reciente, llamada 3-2-1-1-0, añade una copia inmutable y un objetivo de cero errores en la restauración probada.
Elegir una herramienta: rsync, restic o borg
La elección de la herramienta se deriva de la necesidad real, no de la moda. Tres familias cubren la mayoría de los casos de un sitio web.
| Herramienta | Deduplicación | Cifrado | Objetivo ideal |
|---|---|---|---|
| rsync | No | No (mediante el transporte SSH) | Espejo simple de archivos |
| restic | Sí, por bloques | Sí, nativo (AES-256) | Almacenamiento de objetos remoto (S3, Backblaze) |
| borg | Sí, por bloques | Sí, nativo | Servidor de copias dedicado por SSH |
Para un sitio autoalojado que debe enviar sus datos a un almacenamiento de objetos remoto, restic ofrece el mejor compromiso: repositorio cifrado de extremo a extremo, deduplicación que limita el volumen y compatibilidad directa con backends S3. El ejemplo siguiente inicializa un repositorio y luego copia los archivos y una base de datos.
# Variables d'environnement (a stocker hors du depot versionne)
export RESTIC_REPOSITORY="s3:s3.eu-west-3.amazonaws.com/mon-bucket-sauvegardes"
export RESTIC_PASSWORD_FILE="/root/.restic-pass"
# Initialisation, une seule fois
restic init
# Sauvegarde des fichiers du site
restic backup /var/www/monsite --tag fichiers
# Sauvegarde de la base : on evite le fichier intermediaire en clair
mysqldump --single-transaction monsite \
| restic backup --stdin --stdin-filename monsite.sql --tag baseAutomatizar sin sentirse a salvo
Una copia manual nunca se hace el día en que hace falta. La automatización pasa por una tarea programada, ya sea una entrada cron o un timer de systemd, este último con la ventaja de registrar limpiamente y reejecutar una ejecución perdida.
# /etc/systemd/system/backup.timer
[Unit]
Description=Sauvegarde quotidienne du site
[Timer]
OnCalendar=*-*-* 03:30:00
Persistent=true
RandomizedDelaySec=600
[Install]
WantedBy=timers.targetLa política de retención se gobierna del lado de restic, que sabe conservar solo un número elegido de puntos por día, semana y mes, y luego purgar el resto. Este paso es indispensable: sin él, el repositorio crece indefinidamente y la factura de almacenamiento lo sigue.
# Rotation : 7 quotidiennes, 4 hebdomadaires, 6 mensuelles
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --pruneLa clave de cifrado del repositorio nunca debe vivir únicamente en el servidor respaldado. Si ese servidor arde con su única copia de la clave, el repositorio remoto se convierte en un bloque de datos ilegible para siempre. Conserve la clave en un gestor de secretos y en un soporte físico sin conexión.
La prueba de restauración: la única evidencia que cuenta
Es el paso que casi nadie realiza y el único que convierte la intención en garantía. Un repositorio que nunca se ha restaurado puede estar corrupto, incompleto o cifrado con una clave que se ha perdido, sin que ningún panel lo señale.
El día del incidente no es el día para descubrir que la restauración no funciona.
La prueba se realiza en un entorno aislado, nunca sobrescribiendo la producción. El objetivo es doble: comprobar que los datos vuelven y medir cuánto tarda, porque ese plazo es su verdadero punto de recuperación.
# Restauration d'un instantane precis vers un repertoire de controle
restic snapshots
restic restore 4a8f2c1b --target /tmp/restore-test
# Verification d'integrite du depot (a planifier aussi)
restic check --read-data-subset=5%Una restauración mensual, anotada con su fecha y su duración, vale más que mil informes de copia «en verde». Es también el momento de verificar que el procedimiento está documentado con la claridad suficiente para que lo ejecute alguien distinto de su autor, una noche de avería.
Lo que conviene recordar
Una estrategia de copias sólida se reduce a tres decisiones: aplicar la regla 3-2-1 para cubrir todas las familias de riesgo, automatizar con una retención explícita para no depender de la disciplina humana y probar la restauración con regularidad para convertir la hipótesis en certeza. Estos reflejos se integran de forma natural en la gestión de un servidor autoalojado y complementan el endurecimiento del lado de la seguridad.
Mantengo una regla simple para todos mis proyectos y los de mis clientes: una copia cuya restauración no he probado en el último mes no existe en mi panel mental. Hace años perdí media jornada de datos porque el volcado nocturno escribía en un disco que llevaba una semana lleno, sin que nada avisara. Desde entonces, considero la prueba de restauración como el único indicador que no miente, y la planifico igual que las propias copias. — Simon Janvier
Para profundizar: restic.
