Copias de seguridad entre servidores mediante rsync

He encontrado un artículo que tenia para uso interno desde hace tiempo y que pensaba que habia publicado por aquí en su momento. La verdad es que lo he buscado por el blog y no he dado con el, así que supongo que no está de mas publicarlo. Aquí va:

Resumen de decisiones de arquitectura

  • Se mantendrá una replica de los directorios /etc, /home, /root, /usr y /var del servidor en una estación de trabajo remota.
  • Se sincronizará diariamente, manteniendo siempre una copia completa.
  • No es necesario mantener un histórico de los datos.

Introducción

Mediante rsync podemos disponer de una copia de seguridad completa diaria, sin un coste de ancho de banda ni recursos de disco muy altos, ya que cada día se transmiten únicamente las diferencias.

Instalación

Necesitamos los paquetes rsync en ambas máquinas (servidor y estación de trabajo que recoje los backups). Aparte, también necesitamos otros paquetes pero que ya suelen estar instalados: openssl, openssh, ...

Usuarios de backup

Usuario para rsync

Para las transferencia rsync, creamos un usuario específico en la estación de trabajo. Se recomienda crear un usuario no privilegiado para esta función.

genie:~# adduser --home /bkps/bkpsb1 bkpsb1 --disabled-password  
Adding user `bkpsb1'...  
Adding new group `bkpsb1' (1003).  
Adding new user `bkpsb1' (1003) with group `bkpsb1'.  
Creating home directory `/bkps/bkpsb1'.  
Copying files from `/etc/skel'  
Enter new UNIX password:  
Retype new UNIX password:  
passwd: password updated successfully  
Changing the user information for bkpsb1  
Enter the new value, or press ENTER for the default  
Full Name []: mirror/backup sb1  
Room Number []:  
Work Phone []:  
Home Phone []:  
Other []:  
Is the information correct? [y/N] y  

Acceso SSH por certificado

El acceso SSH para rsync requiere certificado (para poder ser usados en batch). Dado que vamos a hacer un backup más o menos general de la máquina, el usuario sobre el que se ejecutará rsync en el servidor ha de ser root, puesto que no hay ningún otro usuario que tenga suficientes privilegios para leer todas las partes del sistema de ficheros necesarias.En el servidor, para la cuenta root creamos una identidad ssh (no poner passphrase):

sb1:~/.ssh# ssh-keygen -t dsa  
Generating public/private dsa key pair.  
Enter file in which to save the key (/root/.ssh/id_dsa):  
Enter passphrase (empty for no passphrase):  
Enter same passphrase again:  
Your identification has been saved in /root/.ssh/id_dsa.  
Your public key has been saved in /root/.ssh/id_dsa.pub.  
The key fingerprint is:  
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx root@sb1.ejemplo.com  

Y añadimos la linea creada en el fichero .ssh/iddsa.pub del servidor al fichero .ssh/authorizedkeys del usuario local de la estación de trabajo (donde se recibirán los backups). En este caso el que hemos creado antes bkpsb1.

genie:~# cd /bkps/bkpsb1  
genie:/bkps/bkpsb1# chown bkpsb1.bkpsb1 .ssh  
genie:/bkps/bkpsb1# chmod 700 .ssh  
genie:/bkps/bkpsb1# ls -la  
total 20  
drwxr-xr-x  3 bkpsb1 bkpsb1 4096 Dec 22 12:03 .  
drwxrwsr-x  7 root   staff  4096 Dec 22 12:02 ..  
-rw-r--r--  1 bkpsb1 bkpsb1  704 Dec 22 12:02 .bash_profile
-rw-r--r--  1 bkpsb1 bkpsb1 1290 Dec 22 12:02 .bashrc
drwx------  2 bkpsb1 bkpsb1 4096 Dec 22 12:03 .ssh

marbles:/bkps/bkpsb1/.ssh# ls -l  
total 4  
-rw-------  1 bkpsb1 bkpsb1 609 May 17 13:51 authorized_keys

Si se utiliza la directiva AllowUsers en la configuración de ssh (/etc/ssh/sshdconfig) deberá añadirse a este usuario a la lista de usuarios permitidos para acceder por ssh. Adicionalmente podemos proteger aún más el acceso incluyendo from="69.44.61.38" al principio de la linea con el certificado en el fichero authorizedkeys. De manera que quedaría de forma similar a:

genie:/bkps/bkpsb1# cat .ssh/authorized_keys  
from="69.44.61.38" ssh-dss AA............  

Para probarlo podemos ejecutar desde el servidor como root: ssh bkpsb1@ns1.ejemplo.com

Script de backup

Se documentará la instalación del mecanismo de copia de seguridad incremental mediante la herramienta rsync ejecutándose via un canal encriptado ssh. En realidad, más que una copia de seguridad es un "mirror" de ciertos directorios de un servidor. No es una copia de seguridad convencional, en el sentido de copiar los ficheros que hayan cambiado. La idea es mantener una copia de los directorios escogidos del servidor en una estación de trabajo que recibirá estos backups. Se describe la instalación de este mecanismo para realizar la copia de seguridad de un servidor desde una estación de trabajo remota.

Programación de los backups (cron)

Según requerimientos se han de realizar backups incrementales diariamente y totales semanalmente.Creamos los enlaces pertinentes en el sistema de directorios estándar de cron.

#!/bin/bash
#

lockfile="/etc/backup/inprogress"

if [ ! -e $lockfile ]; then  
trap "rm -f $lockfile; exit" INT TERM EXIT  
touch $lockfile

rsync -azq --delete /etc /home /root /usr /var bkpsb1@ns1.ejemplo.com:/bkps/bkpsb1

rm $lockfile  
trap - INT TERM EXIT  
else  
echo "$0 already running."  
fi  

Restauración de datos (parcial)

Supongamos el servidor sb1 almacenando una copia por rsync del servidor marbles. Esta copia se efectua por la noche mediante script ejecutado en marbles como usuario root enviando info mediante rsync sobre ssh como usuario bkpmarbles en sb1. Se guarda bajo /bkps/bkpmarbles.

Queremos restaurar el directorio /compartido

rsync -azP -e ssh bkpmarbles@sb1.ejemplo.com:/bkps/bkpmarbles/compartido/ /compartido