Hace poco me han pasado la tarea de organizar el proceso de backup para un servidor de coreo. La herramienta elegida para la tarea ha sido rsync. Me han gustado mucho tres cosas:

• — La posibilidad de usar ssh como el transporte (es decir que no voy a tener otro servicio mas escuchando un puerto adicional. ssh lo tiene todo el mundo).
• — Transferencia cifrada como la consecuencia de uso de ssh
• — Posibilidad de hacer las copias de seguridad incrementares (copiar solo los archivos que se han cambiado desde el backup anterior).

Suponemos que el servidor de backup se llama «backup-server» y el servidor de correo se llama «mail-server». En el servidor de backup hacemos el siguiente script: /root/bcup.sh

#!/bin/bash
rsync -rc -t -e ssh --rsync-path=/usr/bin/rsync --temp-dir=/tmp user@mail-server:/var/mail /mnt/share/mail

En el servidor de correo creamos el usuario «user» con permisos de leer los archivos relevantes al correo. En el servidor de backup tenemos que configurar el acceso al servidor de correo con usuario «user» usando la autentificación basada en claves.

Para hacer el backup periodicamente añadimos esta linea a /etc/crontab:

8 1 * * * root /root/bcup.sh

Ahora sobre los parámetros de rsync que he utilizado:
-e ssh — usar ssh como el transporte
-f — guardar el tiempo de modificación
-r — copia de seguridad recursiva
-c — usar sumas de control para averiguar si el archivo tiene ser copiado
-rsync-path=/usr/bin/rsync — ruta hasta rsync en la maquina de origen
-temp-dir=/tmp — el directorio para guardar los archivos temporales durante del proceso de backup
user@mail-server:/var/mail — usuario, host, y la ruta hacia el directorio para respaldar
/mnt/share/mail — el directorio en el servidor de backup donde vamos a guardar las copias de seguridad

Una situación típica: el proyecto empieza con un servidor muy simple. En seis meses el proyecto crece y pide un servidor grande y vicioso.

En general lo que suelen hacer es comprar una maquina nueva, instalar el sistema operativo y el software necesario, mover el contenido y las bases de datos. Después cambian el DNS y en un par de dias apagan el servidor antiguo.

Aparentemente el proceso es sencillo. Cualquier administrador del sistemas lo tenia que hacer algunas veces. Pero la práctica demuestra que siempre se olvida de algo y al final tenemos que corregir fallos en el servidor que ya esta en producción y sirve el contenido a los clientes.

A veces este procedimiento es inevitable. Por ejemplo, cuando un servidor nuevo esta en un centro de datos diferente. Pero en el caso si los servidores estan en los racks adyacentes podemos probar de transferir el sistema operativo entero. Adelante explico los pasos necesarios de tomar para hacer ese cambio.

Leer mas