Procedimiento para agregar un servidor a los respaldos » History » Version 46

« Previous - Version 46/52 (diff) - Next » - Current version
Daniel Viñar Ulriksen, 09/27/2019 10:08 AM
enlace al role backuppc


Procedimiento para agregar un servidor al servicio de respaldos

BackupPc con Ansible

Los respaldos con ansible se realizan con el role backuppc_client integrado a la configuración del servidor Che.

El playbook permite automatizar las siguientes tareas:
  • configurar un host en un servidor de respaldos, definido por la variable backuppc_server_name, que será respaldado por un usuario unix backuppc,
  • crear un usuario mysql denominado backuppc configurando su contraseña para que no sea solicitada,
  • subir dos scripts, pre_dump.sh y post_dump.sh, configurando las rutas de ejecución por backuppc antes y después de copiar los archivos de un respaldo, y que pueden o no tener necesidad de acceso privilegiado sudo.

Respaldo básico de archivos

Para comenzar a respaldar un contenedor se debe editar el archivo de inventarios de host y agregar al grupo seciu_backup el host que se quiere respaldar.

Nada es estrictamente necesario antes de correr el playbook, pero conviene al menos aclarar qué carpetas se pretenden respaldar, para lo cual conviene agregar al archivo de variables del host a respaldar (en host_vars/<servidor>/vars/XX_backuppc.yml, por ejemplo) las siguientes variables:

backup_state: present  #present/absent
include_files: 
  - /var
  - /etc
  - /usr

backuppc_local_fetch_dir: /var/lib/backuppc  
backuppc_users: "user1,user2" 

Con estos datos agregados podemos ahora si correr el playbook, con el comando que sigue estamos agregando al host yerba a los respaldos

ansible-playbook --limit yerba.interior.edu.uy site.yml -vvvv --tags backuppc_client

Los usuarixs user1, user2 deben estar definidos en el servidor de respaldos como documentado acá.

Luego de finalizado el proceso vamos a tener en el contenedor yerba.interior.edu.uy instalado el paquete rsync, copiada la clave ssh para el acceso del usuario backuppc del servidor y el host o servidor configurado en el servidor de respaldos.

Respaldo de bases de datos backuppc_db_dump

Esta variable esta definida por defecto en null lo que le indica al role que no tenemos bases de datos para respaldar.

Si las bases de datos son postgres (backuppc_db_dump: 'pg') debemos ademas especificar que base de datos deseamos respaldar (backuppc_db_pgsql: 'bd') con estos datos estariamos en condiciones de correr el role y generar el respaldo.

backup_state: present  #present/absent
include_files: 
  - /var
  - /etc
  - /usr

backuppc_db_dump: ''           # mysql/pg/null
backuppc_scripts: true

backuppc_local_fetch_dir: /var/lib/backuppc  
backuppc_users: "ulvida" 

Si se requiere respaldar bases de datos mysql (backuppc_db_dump: 'mysql') vamos a necesitar también el acceso a las mismas y scripts que backuppc ejecute antes de copiar los archivos para hacer un respaldo coherente de las bases.

Los scripts deben ser colocados en host_vars/<servidor>/files/backuppc y deben ser denominados pre_dump.sh y post_dump.sh.

La variable backuppc_db_dump: mysql asegura que se cree un usuario mysql backuppc y que se configure su acceso sin contraseña. La variable backuppc_scripts: true asegura que los precedentes scripts sean subidos al host y sean configurados para ser ejecutados por el servidor de respaldos, respectivamente antes y después de realizar un respaldo.

El contenido de los scripts pre_dump.sh y post_dump.sh queda a consideración de los administradores de servidores.

Ejemplo de scripts para bases de datos

El siguente es un ejemplo para el script pre_dump.sh (por supuesto que hay mil maneras de hacer este respaldo esta es simplemente una). Este respaldo recorre las bases de datos existentes y las respalda una a una, luego comprime todo en un tar.gz y elimina los .sql creados

#!/bin/bash

for DataB in `mysql -e "show databases" | grep -v Database`; do mysqldump --single-transaction $DataB > "$DataB.sql"; done 

tar -czvf dump.sql.tar.gz *.sql

rm *.sql

El siguiente ejemplo de post_dump.sh simplemente borra en la maquina a respaldar el tar.gz que ya fue enviado al servidor de respaldos


#!/bin/bash

rm dump.sql.tar.gz

Scripts con derecho sudo

En el precedente ejemplo, como mysql está configurado para ser accedido desde el usuario backuppc, no es necesario que los scripts tengan derechos privilegiados.

Si adicionalmente agregamos al servidor cliente la variable:

backuppc_scripts_sudo: true

se configurarán los derechos necesarios y los scripts pre_dump.sh y post_dump.sh serán ejecutados con sudo por delante. Esto es necesario, por ejemplo, para el servidor de correo detallado más abajo.

Como siempre, puede ser oportuno mirar el archivo de defaults del role, en el cual vemos tres otras variables que se definen en función de las que presentamos acá:

- backuppc_DumpPreUserCmd y backuppc_DumpPostUserCmd que definen los comandos para la ejecución de los scripts desde el servidor de respaldos,
- backuppc_sudoer que define las autorizaciones sudo del usuario backuppc

Estas variables también pueden ser re-definidas para casos particulares.

Manejo de usuarios de Backuppc

Tendremos la opción de asignar usuarios a los contenedores que queremos respaldar con Backuppc. El usuario administrador backuppc sera utilizado para negociar los respaldos pero quien verdaderamente podrá verlos y restaurar o crear nuevos respaldo son los usuarios que se asignen a cada host por ejemplo

dominio             administrador       usuarios
yerba.interior      backuppc            user1, user2
mate.interior       backuppc            user3

De esta manera user1, user2 podrán manejar unicamente el host yerba el user3 solamente mate y backuppc manejara todos los dominios.
El usuario backuppc no se utilizara como un usuario de la interfaz web solamente es el encargado de respaldar todos los hosts.

En el host_vars vamos a tener la variable backuppc_users donde vamos a poder definir lxs usuarixs que van a administrar dicho servidor respaldado y estxs usuarixs deben estar previamente creados en el servidor Backuppc.

backuppc_users: "user1, user2" 

Estos usuarios deben estar definidos previamente en el servidor de respaldos.

Agregar el servidor de correos

Se realiza como si fuera un servidor común pero se deben modificar las variables en host_vars/nombre_del_servidor/backuppc.yml


backup_state: present  #present/absent
include_files: 
  - /opt.snap     #se le indica a backuppc donde esta el disco montado con los datos del correo

backuppc_mysql_dump: false    # no va a hacer un respaldo de bases de datos
backuppc_scripts: true        # copia las script que respaldan el zimbra
backuppc_scripts_sudo: true   # los scripts requieren privilegios sudo

backup_dir_bash: /var/lib/backuppc     # donde copiar las script

backuppc_users: "" 

En backuppc_users: "" se le indica a backuppc quienes pueden administrar este respaldo. Por default el usuario backuppc.
Si se agrega un usuario debe estar previamente creado en el servidor Backuppc

Script utilizadas para respaldar el correo:


time=`date +%Y-%m-%d_%H-%M-%S`

backup_dir=/path/to/backups/$time

# vol_group - el Volume Group que contiene $zimbra_vol
vol_group=datos

# zimbra_vol - el Logical Volume que contiene /opt/zimbra
zimbra_vol=opt

# zimbra_vol_fs - tipo de archivos de sistema (ext3, xfs, ...) en /opt/zimbra
zimbra_vol_fs=ext4

# lvcreate and lvremove commands path -
lvcreate_cmd=`which lvcreate`
lvremove_cmd=`which lvremove`

# Test for an interactive shell
if [[ $- != *i* ]]
   then say() { echo -e $1; }
     # Colors, yo!
     GREEN="\e[1;32m" 
     RED="\e[1;31m" 
     CYAN="\e[1;36m" 
     PURPLE="\e[1;35m" 
   else say() { true; } # Do nothing
fi

#Una linea agregada para nuestro script adaptado
say $GREEN"Empieza el script pre-respaldo por backuppc.."$PURPLE

# Output date
say $GREEN"Backup started at "$RED"`date`"$GREEN"." 

# Stop the Zimbra services
say $CYAN"Stopping the Zimbra services..." 
say $PURPLE"  This may take several minutes." 
/etc/init.d/zimbra stop

#Chequear si ya existe el volúmen que se intenta crear para que no se produzcan errores. En caso afirmativo, se remueve
if [ -L "/dev/$vol_group/opt_snap" ]; then
  say $RED"¡Advertencia!. El volúmen opt_snap que se intenta crear ya existe. El volúmen será removido y el script continuará" 
  lvremove --force /dev/$vol_group/opt_snap
fi

# Create a logical volume called ZimbraBackup
say $GREEN"Creating a LV called ZimbraBackup:"$PURPLE
$lvcreate_cmd -L60G -s -n opt_snap /dev/$vol_group/$zimbra_vol

# Create a mountpoint to mount the logical volume to
say $GREEN"Creating a mountpoint for the LV..." 
# Tenemos un /opt.snap siempre creado, y respaldamos de ahi

# Mount the logical volume to the mountpoint
say $GREEN"Mounting the LV..." 
mount -t $zimbra_vol_fs -o ro /dev/$vol_group/opt_snap /opt.snap/

# Antes de encender Zimbra Verificar que no exista el archivo y borrarlo
if [ -f "/opt/zimbra/data/postfix/spool/pid/master.pid" ]; then
  say $RED"¡Advertencia!. El archivo master.pid no logró ser suprimido en el anterior apagado de Zimbra. El mismo será removido para conseguir que arranque Zimbra y el MTA y el script continuará" 
  sudo mv /opt/zimbra/data/postfix/spool/pid/master.pid /opt/zimbra/data/postfix/spool/pid/master.pid.old
fi

# Start the Zimbra services
say $CYAN"Starting the Zimbra services..." 
/etc/init.d/zimbra start &

say $GREEN"Fin del script pre-respaldo, acá sigue backuppc.."$PURPLE

Luego de este script Backuppc se copia todo a [[servidores:che|che] que es el servidor de respaldos y luego pasa al script de cierre.


time=`date +%Y-%m-%d_%H-%M-%S`

backup_dir=/path/to/backups/$time

# vol_group - the Volume Group that contains $zimbra_vol
vol_group=datos

# zimbra_vol - the Logical Volume that contains /opt/zimbra
zimbra_vol=opt

# zimbra_vol_fs - the file system type (ext3, xfs, ...) in /opt/zimbra
zimbra_vol_fs=ext4

# lvcreate and lvremove commands path - 
lvcreate_cmd=`which lvcreate`
lvremove_cmd=`which lvremove`

# Test for an interactive shell
if [[ $- != *i* ]]
   then say() { echo -e $1; }
     # Colors, yo!
     GREEN="\e[1;32m" 
     RED="\e[1;31m" 
     CYAN="\e[1;36m" 
     PURPLE="\e[1;35m" 
   else say() { true; } # Do nothing
fi

say $GREEN"Empieza el script post-respaldo por backuppc.."$PURPLE

# Unmount /tmp/ZimbraBackup and remove the logical volume
say $GREEN"Unmounting and removing the LV."$PURPLE
umount /opt.snap/
$lvremove_cmd --force /dev/$vol_group/opt_snap

#say $GREEN"Zimbra backed up to "$CYAN$backup_dir$GREEN"!" 
say $GREEN"Backup ended at "$RED"`date`"$GREEN".\e[0m" 

say $GREEN"Fin del script post-respaldo por backuppc.."$PURPLE

Agregar un servidor manualmente

La configuración de los respaldos de una computadora se inicia a iniciativa de la persona responsable de esa computadora, quien debe leer lo que sigue.

Los pasos que se describen a continuación permitirán tanto que se hagan cotidianamente los respaldos como de darle lo necesario a los responsables del servidor para que puedan acceder a sus respaldos y a diferentes funciones en estos. Los maneja a través de esta interfaz:

Interfaz de entrada en el backuppc

En particular, por esta interfaz puedes:
  • modificar la lista de carpetas que se respaldan cada día, y varios otros parámetros,
  • verificar la realización de los respaldos, las alertas y errores que hayan tenido,
  • acceder a las funciones de restauración de archivos, desde cualquier respaldo hacia cualquier lugar de los servidores que la persona administra.

Solicitudes previas de accesos

El acceso al servidor de respaldos se hace por una interfaz web que sólo está accesible a través de un tunel ssh por la pasarela de administración Ta.

Por ende necesitas una cuenta de usuario unix en ese servidor, que conviene solicitar a los administradores.

También se necesita una cuenta para acceder a la interfaz de backuppc, que por ahora se gestiona en htaccess:
  • si la configuración del respaldo se hace en forma presencial, el administrador de los respaldos te dará el teclado,
  • si estás a distancia, te será necesario hacer los pasos siguientes:
    • si aún no lo tienes, instalar en tu computadora el paquete apache2-utils
    • Ejecutar el siguiente comando con tu propio nombre de usuario:
      htpasswd -c mi_htpasswd <mi_usuario>
      
    • debes hacerle llegar al administrador del servidor de respaldos el archivo mi_htpasswd que esta operación genera, y esto de manera segura, dado que ese archivo contiene un hashcode de tu contraseña. Una manera de hacerlo llegar puede ser ponerlo en un espacio compartido en la pasarela de administración Bourdieu.

Diseño de los respaldos

Los respaldos se desarrollan una vez por día, a iniciativa del servidor de respaldos, cuyo usuario unix backuppc accede en ssh como super usuario en el servidor por respaldar. Hace las siguientes operaciones:
  • Ejecuta eventualmente un script previo a los respaldos, que permitirá hacer todo lo necesario para obtener una versión coherente de los datos por respaldar (por ejemplo, para una base de datos: parando el servicio, haciendo un "dump" de las bases, o una copia "en caliente"),
  • hace una copia del contenido de la lista de carpetas que se definen para respaldar,
  • ejecuta un script de fin de respaldos, para las tareas que sean necesarias.

También, si encuentra algún error, envía un mail a los usuarios unix correspondientes a los responsables del servidor.

Según los servicios que corra el servidor, la estrategia de preservación de datos y de continuidad de servicios que se tengan, conviene diseñar dichos script y dicha lista de carpetas.

Si esto no te queda del todo claro, puedes pasar a las etapas siguientes, pero será oportuno volver iterativamente a esta etapa, que es la que determina que los respaldos que se realicen sean suficientes y consistentes para poder recuperar los datos y los servicios en caso de incidente mayor de pérdida de datos.

Configuración del servidor por respaldar

El servidor por respaldar debe tener un servidor ssh (paquete openssh-server), y el utilitario rsync. (Conviene que el servidor ssh esté configurado coforme a la política correspondiente al respecto.

A continuación se describen los respaldos con un acceso al superusuario root en el servidor, pero el procedimiento también se puede hacer con un usuario con derechos más limitados: sólo de hacer copias con rsync.

Luego, se debe simplemente poner la clave pública del usuario sistema backuppc@dalembert, en el archivo /root/.ssh/authorized_keys, de manera a que tenga acceso para realizar los respaldos.

Esta clave está disponible, con tu cuenta en la pasarela de administración Bourdieu, acá:

sftp://[tu_cuenta]@bourdieu.csic.edu.uy:~/compartido/red/servidores/dalembert/backuppc@dalembert.id_rsa.pub

Para configurarla, es necesario recuperarla en el servidor, y tener acceso super usuario en éste:

root@<mi_servidor>:~# echo -e  "\n## Clave para los respaldo con backuppc desde dalembert\n" >> /root/.ssh/authorized_keys 
root@<mi_servidor>:~# cat backuppc@dalembert.id_rsa.pub | grep backuppc >> /root/.ssh/authorized_keys 

Podemos verificar que nuestra operación se desarrolló con éxito (en el ejemplo, por seguridad no mostramos la totalidad de la clave, que tiene unas cuantas líneas ASCII:

root@<mi_servidor>:~# cat /root/.ssh/authorized_keys 
(... )
## Clave para los respaldo con backuppc desde dalembert
ssh-rsa AAAAB2N (...) lXape6w== backuppc@dalembert

También es posible configurar un respaldo utilizando un usuario con privilegios específicos para los respaldos sin utilizar el usuario root, aquí el como hacerlo.

Configuraciones en el servidor de respaldos

Con la información de diseño de los respaldos y este acceso por clave ssh, los administradores del servidor de respaldo tendrán todo lo necesario apra configurar el servidor, como se describe a continuación:

Se accede en web, pero a través de un tunel ssh, como documentado acá: respaldos.

Para configurar un nuevo host, es necesario tener un unsuario backupPC, con derechos de administración.

Nota: las copias de pantallas son viejas, pero al ingresar la interfaz está ahora en español.

Al ingresar, vemos la consola:

Vamos a la página "Edit Hosts", y presionamos el botón "Add":

Ingresamos el dominio del host que querremos respaldar (1), el nombre (usario backuppc) responsable (2) y las otras personas que tienen acceso a los respaldos (3), y concluímos por "Save" (4):

Al final, para actualizar la lista de hosts del menú, debemos visitar cualquier otra página de la configuración (5)

A través del menú (1), podemos acceder a la configuración del respaldo de nuestro nuevo host(2):

Llegamos a la página de sus respaldos:

peor aún no tenemos ninguno, ni podremos hacerlos mientras no autoricemos el servidor de respaldo a acceder al servidor por respaldar.

Probar el acceso al servidor respaldado

Es indispensable acceder una vez manualmente al servidor por respaldar, de manera a verificar y registrar su clave pública.
Si el responsable del servidor ya configuró la clave necesaria, conviene ejecutar:

root@dalembert:/# su - backuppc
$ ssh root@<servidor_por_respaldar>.csic.edu.uy
The authenticity of host 'davinci.csic.edu.uy (164.73.68.37)' can't be established.
RSA key fingerprint is 5a:df:42:2b:f5:d1:55:c3:bb:89:f7:fd:6b:1b:ad:fa.
Are you sure you want to continue connecting (yes/no)? 

O exactamente el comando que hace el backuppc:
$ ssh -q -x -l root godel.csic.edu.uy

y asegurándose que se conecta correctamente.

Si estás configurando al mismo tiempo el servidor de respaldos y el que se respalda, puedes proceder así:

  1. Como no tenemos acceso distante al usuario root con contraseña (ver Fortalecer el acceso ssh ) empezamos por subir la clave pública a otro usuario (en nuestro ejemplo, ulvida):
    root@dalembert:/# su - backuppc
    $ ssh-copy-id ulvida@godel.csic.edu.uy
    The authenticity of host 'godel.csic.edu.uy (164.73.68.19)' can't be established.
    RSA key fingerprint is df:d6:d3:6f:57:a5:4c:0b:66:42:5c:fd:65:1d:4a:01.
    Are you sure you want to continue connecting (yes/no)? yes
    Warning: Permanently added 'godel.csic.edu.uy,164.73.68.19' (RSA) to the list of known hosts.
    ulvida@godel.csic.edu.uy's password: 
    Now try logging into the machine, with "ssh 'ulvida@godel.csic.edu.uy'", and check in:
    
      .ssh/authorized_keys
    
    to make sure we haven't added extra keys that you weren't expecting.
    
  2. Luego en el servidor a ser respaldado, pasamos esa clave a las que tiene acceso root.
    (operación que, de paso, ya registró conocimiento del servidor distante en la cuenta backuppc)
    root@godel:~# echo -e  "\n## Clave para los respaldo con backuppc desde dalembert\n" >> /root/.ssh/authorized_keys 
    root@godel:~# cat /home/ulvida/.ssh/authorized_keys | grep backuppc >> /root/.ssh/authorized_keys 
    

Podemos verificar que nuestra operación se desarrolló con éxito (en el ejemplo, por seguridad no mostramos la totalidad de la clave, que tiene unas 2 o 3 líneas ASCII:

root@godel:~# cat /root/.ssh/authorized_keys 
(... )
## Clave para los respaldo con backuppc desde dalembert
ssh-rsa AAAAB2N (...) lXape6w== backuppc@dalembert
root@godel:~# 

Scripts de respaldos

Si volvemos a la consola web de backuppc, y vemos la configuración del respaldo de nuestro host(Edit Config: (1) - OjO: hay dos "Edit Config": el del host en curso y el del servidor, más abajo):

podemos ver los parámetros que definen dos scripts que el proceso de respaldo buscará ejecutar antes y despupes de la copia de archivos, denominados respectivamente:
(2):

/usr/local/etc/respaldo/respaldo.sh

(3):
/usr/local/etc/respaldo/fin_respaldo.sh

Estos serviran a ejecutar todos los comandos para realizar el respaldo en un estado coherente, por ejemplo: detención de las bases de datos y/o dump, snapshot de un volumen lógico LVM luego de haber detenido un servicio, etc.

Aunque no los utilicemos, creéemoslos vacíos para evitar errores:

root@godel:~# mkdir -p /usr/local/etc/respaldo/
root@godel:~# touch  /usr/local/etc/respaldo/respaldo.sh
root@godel:~# chmod a+x /usr/local/etc/respaldo/respaldo.sh
root@godel:~# touch  /usr/local/etc/respaldo/fin_respaldo.sh
root@godel:~# chmod a+x /usr/local/etc/respaldo/fin_respaldo.sh

Selección de directorios a ser respaldados

En un primer momento, se deben elegir que directorios se quieren respaldar del servidor en cuestión.

Para indicarle a backuppc que directorios respaldar, dentro del menú del host, se accede a Edit Config->Xfer.

En la sección RsyncShareName se pueden insertar y/o eliminar los directorios a respaldar. Por defecto, backuppc respalda: /var, /etc y /opt.

Es sabido que se generan errores al respaldar directorios vacíos. Por esto es que hay que borrarlos, tal como pasó con Wallace: #2619

Acceso a la interfaz de respaldo y restauración

La interfaz de respaldo y restauración puede ser accedida por el equipo de administración del servidor respaldado.
Deben acceder en tunel via la consola de administración (para lo cual deben tener una cuenta en este):

ssh -L 8443:respaldos-2.csic.edu.uy:443 

También se debe tener un usuario en el servidor de respaldos que (mientras no tengamos un gestor de identidades...) se maneja caso por caso en consola, en el /etc/backuppc/htaccess con el que viene configurado backuppc. Por ej, para definir la cuenta del usuario ulvida, en consola en D'alembert se ingresa

htpasswd /etc/backuppc/htpasswd ulvida

Y ulvida tiene que ingresar ahí mismo su contraeña, (o se le ingresa una contraseña compleja, que se le manda por correo encriptado o por mail interno en ssh al servidor bourdieu)

También se debe configurar la redirección de los correos que pueda enviar backuppc a ese usuario. En /etc/aliases, se debe conbfigurar una entrada:

ulvida: 

Luego ulvida tendrá que acceder por un tunes via bourdieu y visitar el navegador: https://localhost:8443/backuppc

Primer respaldo

Estamos listos a probar nuestro primer respaldo: en la página del host, hay un botón. luego los logs nos indican el desarrollo del respaldo.

Para un respaldo definitivo se debe además, caso por caso:
  • estudiar y prever los scripts precedentemente mencionados,
  • elegir las carpetas que se van a respaldar,
  • probar los respaldos,
  • sobretodo: hacer una prueba de reconstrucción de datos "from scratch"

BackupPC Server Status - Mozilla Firefox_020.png - BackupPC - portada (166 KB) Daniel Viñar Ulriksen, 09/18/2012 09:02 PM

Config Edit - Mozilla Firefox_021.png - BackupPC - hosts (164 KB) Daniel Viñar Ulriksen, 09/18/2012 09:02 PM

Config Edit - Mozilla Firefox_022.png - BackupPC - agregar host (173 KB) Daniel Viñar Ulriksen, 09/18/2012 09:02 PM

BackupPC_ Host Summary - Mozilla Firefox_023.png - BackupPC - acceso nuevo host (174 KB) Daniel Viñar Ulriksen, 09/18/2012 09:02 PM

BackupPC_ Host godel.csic.edu.uy Backup Summary - Mozilla Firefox_024.png - BackupPC - página nuevo host (136 KB) Daniel Viñar Ulriksen, 09/18/2012 09:02 PM

Config Edit - Mozilla Firefox_025.png - BackupPC - scripts pre y post respaldos (130 KB) Daniel Viñar Ulriksen, 09/18/2012 09:19 PM

Backuppc-seleccion-directorios (156 KB) Andrés Pías, 02/21/2014 12:19 PM

Backuppc-seleccion-directorios.png (156 KB) Andrés Pías, 02/21/2014 12:28 PM

backuppc-elegir-directorios.png (157 KB) Andrés Pías, 02/21/2014 12:49 PM

Backuppc_2014-07-08.png - Interfaz de entrada en el backuppc (277 KB) Daniel Viñar Ulriksen, 07/08/2014 05:29 PM