Copias de seguridad con duplicity

Introducción a duplicity

Duplicity es una herramienta de copias de seguridad que combina la eficiencia de rsync para la transmisión y almacenamiento de datos con la seguridad de gpg para el cifrado de los mismos. Además mantiene un histórico eficiente de copias y dispone de múltiples backends donde almacenar los datos.

Tipos de backup

Una de las principales características de duplicity es su eficiencia. Para mantener copias históricas utiliza los mecanismos habituales de la copia completa y la incremental. La incremental envia no sólo los ficheros modificados sino que va más allá y, utilizando el algoritmo de rsync, envia sólo los cambios efectuados. Así se envia y almacena en destino sólo el mínimo necesario. Por supuesto los datos van también comprimidos para, si cabe, reducir más el tamaño.

Cifrado

El cifrado es opcional pero tremendamente sencillo de utilizar. Puede configurarse con claves públicas y privadas con gpg o un cifrado simétrico más sencillo de utilizar. Yo utilizo este por comodidad, utilizando un passphrase complejo para cada configuración de duplicity.

Almacenes (backends)

Una vez indicados el tipo de backup, qué ficheros queremos, la encriptación y algunos datos más nos queda indicar donde guardar la copia de seguridad.

En este apartado, de nuevo, duplicity brilla por su flexibilidad. Permite un mecanismo de extensiones sencillo que ha propiciado la existencia de múltiples backends donde podemos dejar los ficheros. Yo he utilizado fácilmente SSH (quizás el más habitual), FTP y Amazon S3. La lista se va ampliando y se puede consultar en cada versión de duplicity.

Un ejemplo de backends a fecha de mayo de 2016:

  • Azure
  • Backblaze B2
  • Rackspace Cloud Files
  • Copy cloud storage
  • Dropbox
  • FISH
  • FTP
  • Google Docs
  • Google Cloud Storage
  • HSI
  • hubiC
  • IMAP (!)
  • mega
  • onedrive
  • rsync
  • Amazon S3
  • SCP/SFTP
  • Switf (Openstack)
  • Tahoe-LAFS
  • WebDAV
  • pydrive
  • MediaFire

Copia doble de un servidor con duplicity

Bien, una vez introducido duplicity vamos al tema interesante. Como siempre este artículo es un resumen personal a modo de brain unload para mi futura referencia. Hay que cogerlo como tal. Si a alguien le es de utilidad, genial.

He de gestionar bastantes servidores para clientes. Nada grande, normalmente son pequeños servidors VPS o dedicados pero sin grandes pretensiones. Servidores web, de aplicaciones, bases de datos... Para cada servidor me gusta mantener dos copias de seguridad en otros sendos destinos, que pueden ser otros servidores o servicios de alojamiento como Amazon S3 o Backblaze B2.

Script de backup

Suponiendo que hago el backup de un servidor llamado boverals a dos servidores llamados bkp1 y bkp2 lo que tendria son dos scripts en /root con los apropiados y poco imaginativos nombres de duplicity-bkp1 y duplicity-bkp2. Son idénticos excepto por el servidor destino.

#!/bin/bash

export PASSPHRASE=xxxxxxxxxxxxxxxxxxxxxx

flock -n /var/run/duplicity-bkp1 \  
/opt/silence-unless-failed duplicity \
        --full-if-older-than 1M \
        --volsize 250 \
        --include /etc \
        --include /opt \
        --include /root \
        --include /home \
        --include /var \
        --exclude \*\* \
        / rsync://bkp@bkp1.sargue.net//home/bkp/boverals

if [ `date +%d` != "01" ]  
then  
        flock -n /var/run/duplicity-bkp1 \
        duplicity collection-status \
                rsync://bkp@bkp1.sargue.net//home/bkp/boverals /

        flock -n /var/run/duplicity-bkp1 \
        duplicity verify \
                --compare-data \
                rsync://bkp@bkp1.sargue.net//home/bkp/boverals /
fi

flock -n /var/run/duplicity-bkp1 \  
/opt/silence-unless-failed duplicity \
        remove-all-but-n-full 3 \
        --force \
        rsync://bkp@bkp1.sargue.net//home/bkp/boverals

unset PASSPHRASE  

Como se puede ver utilizo un par de herramientas auxiliares aparte de duplicity: flock y silence-unless-failed.

Con flock controlo el caso que una ejecución supere las 24 horas y se encabalgue. Imagino que es casi imposible que pueda pasar pero casi no es suficiente.

El comando silence-unless-failed trabaja como su nombre indica. Se traga la salida de un script a no ser que el resultado de la ejecución sea erróneo. Entonces suelta toda la salida. Al ejectuarse en cron significa que enviará un email. Muy util, parte del conjunto de herramientas phusion server tools.

La variable de entorno PASSPHRASE contiene la contraseña para la encriptación simétrica de las copias de seguridad. Cuando duplicity encuentra dicha variable de entorno la utiliza automáticamente.

Copia en destino via rsync y SSH

El script de ejemplo anterior utiliza dos servidores, el protocolo rsync y el transporte por SSH para almacenar la copia de seguridad. Es uno de los casos más habituales que utilizo, simplemente por motivos de costes. Puedo cruzar copias entre servidores, a ser posible alojados en diferentes centros de datos.

Para poder automatizar las copias lo único necesario en este caso es que el usuario con el que se ejecuta la copia de seguridad local (habitualmente root) pueda conectar sin contraseña por SSH al destino (usuario y servidor). Nada más facil que utilizar validación por certificados.

Restauración

La restauración es tremendamente sencilla:

duplicity restore rsync://bkp@bkp1.sargue.net//home/bkp/boverals directorio  

El comando construye la última versión de la copia utilizando todas las incrementales que sea necesario y deja el resultado en el directorio especificado. Si la copia está encriptada pedirá la contraseña por consola.

Cold backup

Todo estos mecanismos estan muy bien pero tienen un punto debil comun. Improbable, pero no imposible. Al estar todas las copias automatizadas es posible que un atacante que entre en un servidor borre no sólo datos en el propio servidor sino todas las copias de seguridad. Tengamos las que tengamos. En el caso de duplicity es tan sencillo como ejecutar un purgado.

La única solución es disponer de alguna copia de seguridad a la que no pueda borrarse desde los mismos servidores desde donde se realice la copia. Hay múltiples alternativas como copias a destinos de sólo escritura o que tengan una retención fijada. También una copia manual a un deposito seguro.