Guía de despliegue y configuración del servicio de Backup
Preparación básica
- Descargar la imagen de aquí.
- Preparar la máquina virtual con los siguientes parámetros:
- Tamaño Volumen: 3GB
- RAM: 256 MB
- Nombre: backup
./createvm backup 3G Backup-1.1_1.tgz 128 192.168.69.23 xenbr0
- Arrancar la máquina virtual
xm create -c /etc/xen/auto/backup
- Entrar como root con clave passwd.root y cambiarla.
Configuración de la máquina
Existen dos opciones de configuración:- Configuración centralizada: Si la máquina va a estar integrada en una infraestructura de gestión ModularIT
- Configuración local: Si la máquina no va a estar integrada en una infraestructura de gestión ModularIT
Configuraciones centralizadas
En el servidor Puppet
- En el grupo de cliente de la máquina, definimos los parametros globales referentes a los servicios de la máquina Backup
## Backup service variables # IP of the backup server $backup_ip = "192.168.69.23"
- Crear la entrada de la máquina que estamos instalando, con su nombre ModularIT
node "devel.backup" inherits "devel" {
# First installation?
$bootstrap = yes
$modularit_name = "devel.backup"
$comment = "Development Backup"
include modularit
}
En el cliente (la máquina que estamos instalando)
- Paramos puppetd y lo arrancamos en modo debug para comprobar que actualiza todo:
/etc/init.d/puppet stop puppetd --debug --no-daemonize --runinterval 60 --fqdn NOMBRE_MODULARIT --server PUPPET_MODULARIT
- Los parametros NOMBRE_MODULARIT y PUPPET_MODULARIT seran facilitados por el responsable del servicio (usted mismo si es ese responsable). Consulte en la lista de correo si tiene dudas.
- Una vez que el puppet completa varios ciclos sin error, lo ejecutamos como servicio
/etc/init.d/puppet restart
- Para comprobar que las notificaciones al Nagios funcionan correctamente, ejecutamos el planificador de PIFIA
/var/lib/pica/bin/scheduler Emergency /var/lib/pica/bin/scheduler Warning
- En el Nagios comprobamos si hay alguna alerta que no genere un OK. En este punto es normal tener alertas critical de AIDE
Configuracion local
Preparación específica de la máquina
La gestión del RAID lo hacemos desde el hierro (dom0) y lo exportamos a la máquina como un disco virtual. Creamos el RAID en el hierro:- Para ver los discos:
fdisk -l
- Asumimos que los discos de backup son sdb y sdc.
- Marcamos las particiones con el tipo fd (Linux RAID):
sfdisk --id /dev/sdb 1 fd sfdisk --id /dev/sdc 1 fd
- Creamos el ARRAY:
mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb1 /dev/sdc1
- Comprobamos que se ha creado:
cat /proc/mdstat
- Debe devolver algo como: md0 : active raid1 sdc1[1] sdb1[0] e indicar que está sincronizando.
- Configuramos /etc/mdadm.conf para asegurarnos que busca elementos de array en los discos correctos:
echo "DEVICE /dev/sd* /dev/hd*" > /etc/mdadm.conf mdadm -Q --examine --brief /dev/sd* >> /etc/mdadm.conf
- Si nos fijamos en el fichero vemos que no se define el array en función de sus elementos (sdb1 y sdc1) sino en función de la etiqueta que escribe. De esa forma si el disco cambia de nombre (nada raro en USB) el mdadm lo sigue encontrando.
- Exportamos el ''/dev/md0'' como un disco más a la máquina virtual.
- En la seccion disk añadimos: phy:/dev/md0,hdc1,w . De esta forma el array se verá dentro de la máquina de backup como la particion /dev/hdc1 .
- Reiniciamos la máquina virtual para que vea los cambios de configuración.
Si vamos a usar cifrado de datos, pasamos al siguiente apartado
- Preparamos el disco de backup en la máquina virtual
- Formateamos el disco:
mkfs -t ext3 /dev/hdc1
- Si el array aún se esta sincronizando (cat /proc/mdstat) esta operación puede tardar bastante (estamos hablando de varias horas, mas de 4 horas para 500G por usb).
- Lo descomentamos en el /etc/fstab y ejecutamos mount -a
La máquina de backup tiene un samba que comparte el directorio de backup. Por defecto se usa el nombre de máquina BACKUP en el grupo de trabajo BACKUP. Por defecto solo el usuario backup tiene acceso a la carpeta Samba.
Establecer la clave samba del usuario backup:
smbpasswd backup
Cifrado del volumen de backup
Para hacer que los datos de backup estén cifrados seguimos los siguientes pasos:
- Comprobamos los bloques del disco y llenamos con datos aleatorios. ¡OJO! Sobreescribe el disco y tarda mucho, fácilmente mas de 8 horas para un disco grande:
badblocks -c 10240 -s -w -t random -v /dev/hdc1
- Opcional si hemos hecho el paso 1. Inicializamos el volumen de backup con datos aleatorios:
dd if=/dev/urandom of=/dev/hdc1 bs=1M
- Inicializamos la clave. ¡OJO! Si la perdemos no hay ningúna forma de acceder a los datos. Así que el fichero de clave hay que guardarlo en un lugar seguro.
dd if=/dev/random of=/etc/cryptsetup-key bs=1 count=256
- Asociamos el dispositivo dm-crypt. Después de esto el dispositivo cifrado será /dev/mapper/backup.
cryptsetup create --key-file /etc/cryptsetup-key backup /dev/hdc1
- Comprobamos los datos de cifrado:
cryptsetup status backup
- Creamos el sistema de ficheros en el dispositivo. No usamos journal para evitar cifrar dos veces, cuando se escriben los datos y cuando se escribe el journal:
mkfs.ext3 -m 1 -O dir_index,filetype,sparse_super /dev/mapper/backup
- Montamos con:
mount -t ext3 /dev/mapper/backup /dat/bck
- Desactivamos con:
umount /dat/bck cryptsetup remove backup
- Si usamos cifrado en el volumen de backup, el volumen no se monta automáticamente al arrancar la máquina de backup. Para facilitar el proceso hay un script llamado cryptbck:
- cryptbck mount: Activa el volumen cifrado y lo monta en /dat/bck.
- cryptbck umount: Desmonta y desactiva el volumen cifrado.
- cryptbck status: Muestra el estado el volumen cifrado.
Creación y Distribución de claves de backup
Si no usas Puppet o PICA para gestionar las máquinas, necesitas generar un par de claves ssh para backup y distribuirlas a todas las máquinas de las que quieras hacer backup. Si usas Puppet o PICA este paso no es necesario porque la gestión y distribución de claves se hace de forma centralizada.- Crear un nuevo par de claves:
modularit-backup-genkey
- Distribuir la clave a una máquina remota (p.ej. ldap):
modularit-backup-sendkey ldap
Preparación del Servicio
Por defecto el histórico que se instala con el /etc/dirvish/master.conf es el siguiente:
# Caducidad copias
expire-default: +30 days #Las copias diarias se guarda durante 15 dias
expire-rule:
#MIN HR DOM MON DOW STRFTIME_FMT
* * * * su +3 months #Se guarda 3 meses la copia de todos los domingos
* * 1-7 * su +1 year #Se guarda una año la copia del primer domingo del mes.
* * 1-7 1,4,7,10 su never #Se guarda siempre la copia del primer domingo de los meses de Enero, Marzo, Julio y Octubre
Necesitamos definir e inicializar los backups y comprobar que la alerta de Backup en el Nagios esta funcionando correctamente. Al trabajar con máquinas virtuales, los backups se harán siempre sobre la máquina dom0 (el hierro), no sobre la máquina de servicio (domU). Para poder hacer el backup de forma segura, hacemos un snapshot del volumen donde tenemos la máquina virtual, montamos este snapshot en un directorio, y hacemos el backup de este directorio. Una vez que se termina el backup, desmontamos y borramos el snapshot.
Es MUY IMPORTANTE tener en cuenta que al trabajar a nivel de volumenes LVM, necesitamos definir un vault para cada volumen de una máquina virtual. Es decir, si tenemos una máquina samba en el volumen /dev/sys/samba y su directorio home está en el volumen /dev/sys/samba_home, debemos definir un vault para cada volumen.
- Ir al directorio /dat/bck
- Crear un directorio para cada backup (vault) con un subdirectorio llamado dirvish. Por ejemplo, vamos a asumir que haremos backups de 3 sistemas: ldap, samba y mail.
mkdir -p ldap/dirvish samba/dirvish mail/dirvish
- En cada subdirectorio dirvish creamos un fichero default.conf con la siguiente sintaxis:
pre-client: cd /root; /var/lib/pica/bin/DirvishSnapshot start ldap /snapshot post-client: cd /root; /var/lib/pica/bin/DirvishSnapshot stop ldap /snapshot client: hierro tree: /snapshotCon el fichero anterior le decimos al dirvish que haga lo siguiente:
- Backup del directorio /snapshot de la máquina hierro.
- Antes de la copia, ejecuta el script DirvishSnapshot, que crea un snapshot (parametro start) del volumen ldap (1er parametro) y lo monta en el directorio /snapshot (2º parametro). Es importante que el directorio sea el mismo que usamos después en la opción tree. Como las copias se hacen una despues de la otra, podemos usar el mismo directorio (/snapshot) para todas las copias.
- Despues de la copia, ejecuta el mismo script con el parámetro stop, que desmonta y elimina el snapshot. Es MUY IMPORTANTE poner el cd /root; porque en caso contrario no se podra desmontar el directorio ni borrar el snapshot, ya que el script se ejecutara desde el directorio /snapshot.
- Para que las copias se efectúen correctamente, debemos forzar la primera ejecución de cada vault (incializar el vault):
dirvish --vault NOMBRE_VAULT --init
- Comprobar que la copia se hace y que no hay ningún fichero de error en el subdirectorio de la fecha actual.
- Una vez definidos e incializados todos los backups (vaults), los añadimos a la opción RunAll del fichero /etc/dirvish/master.conf para que se ejecuten automáticamente.
- Comprobar en el Nagios que el informe de los backups se recibe correctamente y que está en estado OK.
- Podemos forzar la generación del informe de backup con:
/var/lib/pica/alarms/Warning/DirvishChk-picacaller_
Activación SELinux
Para acivar selinux:- En /etc/sysconfig/selinux establecer:
SELINUX=enforcing
- Etiquetar el sistema de ficheros y reiniciar:
fixfiles relabel reboot
- Etiquetar /dat para compartirlo por samba:
chcon -R -t samba_share_t /dat
- O indicar que permitimos compartir cualquier cosa en sólo lectura:
setsebool -P samba_export_all_ro on