Servidores:backup

Backup

El esquema actual de backup de datos es un esquema cliente-servidor, en el cual el servidor contacta uno a uno a los equipos clientes para solicitarles los datos y almacenarlos. La principal herramienta que se utiliza para esta tarea es rsync, en conjunto con scripts personalizados y tareas automatizadas vía CRON.

El esquema actual se divide en dos ramas: el backup de archivos de sistema, por una parte, y el resguardo de las bases de datos por otro.

En el primer caso, el servidor envía una solicitud al cliente, en la forma de una conexión SSH. El cliente, al recibir esta conexión, lanza un proceso de sincronización de archivos locales y remotos, utilizando rsync, con lo cual envía de vuelta al servidor los archivos a resguardar. El volcado de bases de datos, en cambio, es más sencillo: dado que todo servidor de base de datos está diseñado para recibir conexiones remotas, obtener un volcado de las bases se limita a otorgar los permisos adecuados para permitir el volcado de los datos.

Software

El sistema de backup de los servidores funciona utilizando los siguientes programas:

 * **rsync:** rsync es un software para sistemas Unix que sincroniza archivos y directorios de dos PCs distintas, minimizando la transferencia de datos utilizando. Permite hacer transferencias incrementales de archivos, así como también permite la utilización de compresión.
 * **cron:** cron es un servicio de Unix para planificar el lanzamiento de procesos de manera automática en base a la hora del sistema.
 * **pg_dump/pg_dumpall:** estas utilidades son provistas junto con el motor de bases de datos PostgreSQL, y son utilizadas para obtener un volcado de las bases de datos, ya sea de una única base (pg_dump) o de todas ellas (pg_dumpall).
 * **scripts de bash:** Bash es una shell de Unix, que provee entre sus diversas características el uso de variables, funciones y control de flujo, permitiendo la escritura de programas que son luego interpretados como scripts (es decir, no compilados). Estos scripts son particularmente útiles para la realización de tareas administrativas 
 * **ssh:** (siglas de //Secure Shell//) es una utilidad para abrir terminales en equipos remotos. Debido a que la comunicación es encriptada, es el mecanismo ideal para ejecutar comandos en un servidor remoto. En el caso particular del sistema de backup, se utilizará para enviar comandos a los clientes al momento de iniciar el proceso diario de backup, utilizando un tipo de acceso mediante clave pública.

Esquema de equipos

El sistema de backup actual considera el siguiente esquema de servidores:

 * **200.16.30.4 (Oren):** Servidor público, brinda acceso al sistema PHP-Collab
 * **200.16.30.5 (Redecofi):** uno de los servidores más importantes de la secretaría, maneja tanto las cuentas de e-mail internas como el sitio web de la Secretaría
 * **200.16.30.6 (Kiddo):** Servidor que brinda acceso al sistema de tickets OTRS
 * **200.16.30.7 (Sofie):** Servidor público, brinda acceso al sistema Mapuche
 * **192.168.19.20 (Hanzo):** Servidor interno, corre el sistema SIU-Pilaga de producción 
 * **192.168.19.21 (Budd):** Servidor interno, corre el sistema SIU-Pilaga de pruebas. Funciona actualmente como servidor de backup, por lo que todo el proceso se realiza en este servidor
 * **192.168.19.23 (Elle):** Servidor interno de SIU-Pilaga, con las versiones de archivo de las bases del sistema

Dado este esquema, para cada equipo se mantiene un esquema de backup particular, basado en el volúmen de información que maneja y su importancia. Como regla general, los backups de los servidores más pesados (backups de datos, generalmente) se lanzan en horario nocturno, mientras que los archivos más pequeños (típicamente bases de datos) son actualizados al backup en intervalos más cortos.

Servidor

El servidor de backups es el encargado de contactarse con los clientes para solicitar los archivos. En contraste a los sistemas tradicionales, donde son los clientes los que se comunican con el equipo, este enfoque tiene ciertas ventajas particulares para nuestra situación:

 * La fecha de los distintos equipos varía notablemente (no por error, sino por //diseño//), lo cual dificulta la sincronización entre ellos. Utilizando un único reloj, se evita este problema
 * Es deseable tener un mecanismo que permita realizar backups fuera de programa (por ejemplo, antes de realizar una tarea de mantenimiento en el cableado eléctrico del edificio). Este esquema permite contactar a los servidores en cualquier momento.

Configuración de software

Dado que toda la comunicación que se realiza desde los clientes hacia el servidor utiliza rsync, es preciso configurar el sistema para que funcione correctamente. Una vez instalado rsync (apt-get install rsync), debemos activarlo para que funcione en modo servidor. Para ello, debemos modificar los siguientes archivos: /etc/init.d/rsync - línea 22: RSYNC_ENABLE=true /etc/default/rsync - línea 8: RSYNC_ENABLE=true

Hecho esto, es momento de crear un fichero de configuración, el cual ubicamos en /etc/rsyncd.conf. Dado que una referencia completa de este fichero escapa a los fines de este documento, nos limitaremos a explicar los parámetros utilizados actualmente:

read only=no write only=yes log file=/var/log/rsync.log

Estas tres primeras líneas configuran ciertos parámetros del servidor. La primera línea establece que el servidor no debe funcionar como sólo lectura (lo cual es útil para servidores que deben proveer archivos pero no modificarlos, lo cual no es nuestro caso), la segunda configura el servidor como sólo escritura (lo cuál es útil para evitar que desde otro sistema descarguen una copia de los archivos - sólo queremos que los clientes puedan subir archivos, no descargarlos) y la tercera establece el archivo en el cual se registran los logs del programa.

[mail] path=/backup/actual/mail hosts allow=200.16.30.5 comment=Backup del e-mail del servidor Redecofi Estas líneas definen el comportamiento para el primer caso del backup, el e-mail del servidor redecofi:

 * La primera línea, "[mail]", define un identificador para este backup 
 * La segunda línea define el directorio al cual se brindará acceso, y en el cual se almacenarán los archivos que subamos. 
 * La tercera línea define qué hosts pueden conectarse al servidor. Dado que 200.16.30.5 es la dirección IP del servidor Redecofi, sólo éste servidor podrá consultar estos datos (lo cual evita, por ejemplo, que se pueda subir información desde otro servidor). 

La cuarta y última línea es un comentario que permite identificar al backup. Resulta de utilidad al momento de consultar remotamente los sistemas de backup disponibles en el servidor.

Una vez terminada la configuración, reiniciamos el servicio (/etc/init.d/rsync restart), y nuestro sistema está listo para funcionar como servidor de backup. Ahora que ya hemos configurado el servidor, debemos crear el sistema de directorios sobre el cual trabajaremos. El esquema que hemos utilizado para el servidor actual es el siguiente: /backup /actual /mail /web /bases /... /archivo /scripts

En el directorio actual se guardan los últimos backups. En cada directorio se guardarán los archivos subidos vía rsync, con la excepción del directorio bases, sobre el cuál hablaremos más adelante. En el directorio archivo almacenaremos, en una carpeta cuyo nombre es la fecha actual, los archivos diarios de los backups del sistema. Actualmente se mantienen hasta 5 días de backup, ocupando aproximadamente 86Gb cada día.

Scripts y CRON

Existen actualmente tres scripts de sistema, todos ellos ubicados en el directorio /backup/scripts:

 * **script_archivos.sh:** El script más sencillo, contacta a cada uno de los servidores para lanzar el proceso de envío de archivos vía rsync
 * **script_bases.sh:** Este script crea un volcado actualizado de las bases de datos en cada servidor
 * **script_rotacion.sh:** Script que rota los backups, eliminando los directorios viejos y copiando la versión más actualizada al archiv 

Cada uno de estos scripts se activa mediante entradas en CRON:

 * El primer script se llama una vez por día a la madrugada. Esto asegura que no se sature la red durante la transferencia de archivos
 * El segundo script se llama una vez por hora en el intervalo de 8:00 a 18:00 hs. 
 * El tercer script, finalmente, se llama una vez por día, aproximadamente al terminar el primer script sus tareas

Scripts - script_bases.hs

1. !/bin/bash

DIR_BACKUP="/backup/actual/bases"

1. 200.16.30.4 removido, hasta que se decida qué hacer con él

SERVIDORES="192.168.19.20 192.168.19.21 192.168.19.23 192.168.19.24 192.168.19.26 200.16.30.4 200.16.30.5 200.16.30.6 200.16.30.7" HORA=`date +%Y-%m-%d.%H-%M`

1. Cantidad de backups a mantener:
2. 9 servidores, 1 backup por hora, durante 11 horas = 99 archivos

CANT=99

1. Funcion que mantiene los primeros $CANT archivos en un directorio,
2. siguiendo un orden alfabetico

function borra_viejos() {

       while (( $# > $CANT )); do
               rm -rf "$1"
               shift
       done

}

script_rotacion.hs

1. !/bin/bash

1. Directorio de backup actual y directorio destino

SRC='/backup/actual' DEST='/backup/archivo' DGP='/backup/actual/dgp.web'

1. Fecha actual

FECHA=`date +%Y-%m-%d`

1. Cantidad de dias de backup a mantener
2. Tiene que ser uno mas, por el directorio "lost+found"
3. 24/08: resulta que también tiene que ser uno menos, ya que de otra
4. forma puedo quedarme sin espacio al subir (asumiendo que primero borre
5. los viejos y después copie los archivos, que es lo que agrego en este cambio)

CANT=6

1. Funcion que elimina los backups viejos,
2. mateniendo los últimos $CANT backups
3. IMPORTANTE: solo funciona si los archivos del directorio
4. estan almacenados por orden alfabetico

function borra_viejos() {

       while (( $# > $CANT )); do
               rm -rf "$1";
               shift
       done

}

1. Borra los backups desactualizados

borra_viejos ${DEST}/*

1. Borrando archivos viejos de la DGP

borra_viejos ${DGP}/bk_dgprrhh* borra_viejos ${DGP}/bk_haberes* borra_viejos ${DGP}/bk_sitio* borra_viejos ${DGP}/bk_siu* borra_viejos ${DGP}/bk_sueldos* borra_viejos ${DGP}/bk_toba_1_4* borra_viejos ${DGP}/bk_todo*

1. Guardamos la copia diaria de los archivos

cp -rp ${SRC} ${DEST}/${FECHA}/

script_archivos

1. !/bin/bash

ssh 192.168.19.20 ssh 192.168.19.21 ssh 192.168.19.23 ssh 192.168.19.24 ssh 192.168.19.26 ssh 200.16.30.4 ssh 200.16.30.6 ssh 200.16.30.7 ssh 200.16.30.9

1. Este va al ultimo porque toma mucho tiempo

ssh 200.16.30.5

script_hizo_backup.py

1. !/usr/bin/python

import time import os.path import sys from string import atoi

year = repr(time.localtime()[0]) mes = repr(time.localtime()[1]) dia = repr(time.localtime()[2])

if atoi(mes) <10:

       mes = '0'+mes

if atoi(dia) <10:

       dia = '0'+dia

fecha = year+"-"+mes+"-"+dia if os.path.isdir("/backup/archivo/"+fecha):

       print "OK - Se hizo el backup"
       sys.exit(0)

else:

       print "CRITICAL - No se hizo el backup completo"
       sys.exit(2)

Crontab

Editamos como root crontab -e y ponemos

1. m h dom mon dow command

00 00 * * * /backup/scripts/script_archivos.sh

00 8-18 * * * /backup/scripts/script_bases.sh

00 4 * * * /backup/scripts/script_rotacion.sh

Archivos

El envío de los archivos de sistema al servidor se realiza mediante rsync. En concreto, una vez que se configuró el servidor de rsync adecuadamente, el comando que se utiliza para sincronizar un directorio es similar al siguiente: /usr/bin/rsync --verbose --numeric-ids --hard-links --owner --group --progress --stats --compress --recursive --times --perms --delete /var/www 192.168.19.25::redecofi.web

En este código, /var/www 192.168.19.25::redecofi.web indica que se hará una copia de seguridad del directorio /var/www (y sus sub-directorios), contactando al servidor rsync ubicado en 192.168.19.25 (la IP de nuestro servidor de backup) bajo el identificador de módulo redecofi.web.

Ahora bien, queda pendiente aún la cuestión de cómo lanzar este proceso desde el servidor. La solución implementada es la autenticación vía SSH con //clave pública// y //comandos forzados//

 * La autenticación por clave pública es una alternativa al uso de contraseñas, mediante la cual el cliente y el servidor intercambian una clave. Al conectarse el cliente al servidor en sucesivas ocasiones, basta con enviar su copia de la clave para ingresar al servidor, sin necesidad de contraseña
 * El acceso por comandos forzados es un tipo de acceso mediante el cual un servidor SSH otorga ingreso a la PC local, pero sólo permite ejecutar ciertos comandos, definidos de forma individual 

Para implementar esto, debemos modificar el acceso SSH de los servidores para que permitan estas opciones. Editamos entonces el archivo /etc/ssh/sshd_config, modificamos las siguientes opciones, y luego reiniciamos el servidor con el comando /etc/init.d/ssh restart:

 * **PermitRootLogin**: debe modificarse de no a forced-commands-only
 * **RhostsRSAAuthentication**: de modificarse de no a yes
 * **AllowUsers**: si esta opción está presente, agregar root@192.168.19.25 a la lista de usuarios a los que se les permite el acceso

Una vez hecho esto, debemos setear el acceso con clave pública del servidor de backup a las PCs clientes (siguiendo esta guía, pero teniendo cuidado de asegurar que el usuario que intercambie la clave sea el usuario root). Como paso siguiente, debemos modificar la clave pública intercambiada con el servidor para que permita un único comando, a saber, la copia vía rsync. Esto se hace editando el fichero /root/.ssh/authorized_keys2, y editarlo de modo tal que quede como en el siguiente ejemplo:

from="192.168.19.25",command="/usr/bin/rsync --verbose --numeric-ids --hard-links --owner --group --progress --stats --compress --recursive --times --perms --delete /var/www 192.168.19.25::redecofi.web" ssh-rsa <clave pública>== root@yubari

Hecho esto, sólo resta comprobar que el comando funcione adecuadamente - para ello, simplemente intentamos acceder como root vía ssh, con el comando ssh <servidor>. Si vemos una lista de ficheros que pasa por la terminal, es señal de que el procedimiento ha sido exitoso.