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/id_dsa.pub del servidor al fichero .ssh/authorized_keys 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/sshd_config) 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 authorized_keys. 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