Construyendo para la producción: Aplicaciones web — Copias de seguridad

Tutoriales
Backups MySQL Ubuntu

Introducción

Después de elaborar un plan de recuperación para las diferentes partes de tu aplicación, deberías establecer el sistema de copias de seguridad que se requiere para apoyarlo. Este tutorial se centrará en el uso de Bacula como solución de copias de seguridad. El beneficio de utilizar un sistema completo de copias de seguridad, como Bacula, es que te proporciona control total sobre qué se copia y restaura a nivel de archivo individual, y puedes programar copias de seguridad y restauraciones de acuerdo con lo mejor para ti.

Los servicios como los de Backups DigitalOcean Droplets (snapshots de tus Dropletas enteras) son fáciles de configurar y podrían ser suficientes para sus necesidades si solo requieres copias semanales. Si optas por las copias de seguridad de DigitalOcean, asegúrate de configurar hot backups de tu base de datos siguiendo la sección Crear Hot Backups de Tu Base de Datos.

En esta parte del tutorial, configuraremos un Bacula para mantener copias diarias de los backups necesarios de los servidores que comprenden nuestra configuración de aplicación (db1, app1, app2 y lb1), definidos previamente en nuestro plan de recuperación. Esencialmente, este es un tutorial que muestra cómo utilizar Bacula para crear copias de seguridad de una pila LAMP. También utilizaremos Percona XtraBackup para crear copias de backup activas de nuestra base de datos MySQL. Finalmente, utilizaremos rsync para crear una copia de nuestros backups en un servidor de un centro de datos remoto. Esto agregará dos servidores a nuestra configuración: backups y remotebackups (ubicados en un centro de datos separado).

Vamos a empezar.

Instalar Bacula en el Servidor de Backups

Configura Bacula en tu servidor backups siguiendo este tutorial: Cómo Instalar el Servidor de Bacula en Ubuntu 14.04.

Luego siga la sección Configuración de la direccionalidad de Bacula (servidor) de esta guía de instrucciones. Necesitarás el nombre del directorio cuando esté configurando los clientes de Bacula (en los servidores que deseas backup). Detengase cuando llegue a la sección Cómo hacer un respaldo de un servidor de Ubuntu 14.04 con Bacula. Deberá tener el nombre del directorio cuando esté configurando los clientes de Bacula (en los servidores que deseas backup). Detengase cuando llegue a la sección Instalar y configurar el cliente de Bacula. Nota que podrías cambiar algunos de los valores predeterminados antes de proceder.

Instalar el cliente de Bacula en cada servidor

Instale el cliente de Bacula en cada servidor que desee respaldar (db1, app1, app2, y lb1) siguiendo la sección Instalar y configurar el cliente de Bacula de esta guía de instrucciones: Cómo hacer un respaldo de un servidor de Ubuntu 14.04 con Bacula. Detengase cuando llegue a la sección Agregar conjuntos de archivos (servidor).

Nota que necesitarás el Nombre del demonio de archivos (generalmente el nombre de la máquina con la extensión “-fd”) y la Contraseña del director (la contraseña que usará el servidor Bacula para conectarse a cada cliente) desde el archivo /etc/bacula/conf.d/clients.conf en cada servidor.

Agregar clientes de Bacula al servidor de copias

En backups, el servidor Bacula, agrega una recurso de cliente al archivo /etc/bacula/conf.d/clients.conf para cada servidor en el que se instaló el cliente de Bacula.

Abra el archivo clients.conf:

  1. sudo vi /etc/bacula/conf.d/clients.conf

Aquí es un ejemplo de definición de recurso de cliente para el servidor de base de datos, db1. Considere que el valor de Name debe coincidir con el nombre del recurso FileDaemon y el Password debe coincidir con la contraseña del director en el servidor de cliente; estos valores pueden encontrarse en /etc/bacula/bacula-fd.conf en cada servidor de cliente de Bacula.

clients.conf — Example Client resource definition
Client {
  Name = db1-fd
  Address = db1.nyc3.example.com
  FDPort = 9102
  Catalog = MyCatalog
  Password = "PDL47XPnjI0QzRpZVJKCDJ_xqlMOp4k46"          # password for Remote FileDaemon
  File Retention = 30 days            # 30 days
  Job Retention = 6 months            # six months
  AutoPrune = yes                     # Prune expired Jobs/Files
}

Cree una definición similar de recurso de cliente para cada uno de los servidores restantes de Bacula cliente. En nuestro ejemplo, habría cuatro recursos de cliente después de terminar: db1-fd, app1-fd, app2-fd, y lb1-fd. Esto configura al director de Bacula, en el servidor backups, para poder conectarse a cada servidor de cliente…

Guardar y salir.

Puedes encontrar más detalles sobre esta sección en la guía Cómo instalar y configurar el cliente de Bacula en la tutorial Cómo hacer copias de seguridad de un servidor Ubuntu con Bacula.

Crear copias hot de tu base de datos

Para asegurarnos de que las copias de seguridad de nuestra base de datos activa sean consistentes (es decir, utilizables), es necesario tomar precauciones específicas. Un método sencillo y efectivo para crear copias hot de MySQL es usar Percona XtraBackup.

Instalar Percona XtraBackup

En tu servidor de base de datos, db1, instala y configura Percona XtraBackup siguiendo esta guía: Cómo Crear Copias Hot de bases de datos MySQL con Percona XtraBackup en Ubuntu 14.04. Deténte cuando llegues al sección Perform Full Hot Backup.

Crear Script de XtraBackup

Percona XtraBackup está listo para crear copias de seguridad activas de su base de datos MySQL, que finalmente serán respaldadas por Bacula (o DigitalOcean Backups), pero las copias de seguridad activas deben programarse de alguna manera. Vamos a configurar la solución más simple: un script de bash y un trabajo de cron.

Cree un script de bash llamado run_extra_backup.sh en /usr/local/bin:

  1. sudo vi /usr/local/bin/run_xtrabackup.sh

Agregue el siguiente script. Asegúrese de sustituir el usuario y la contraseña con lo que estableció cuando instaló XtraBackup:

/usr/local/bin/run_xtrabackup.sh
#!/bin/bash

# pre xtrabackup
chown -R mysql: /var/lib/mysql
find /var/lib/mysql -type d -exec chmod 770 "{}" \;

# eliminar copia de seguridad completa existente
rm -r /data/backups/full

# xtrabackup create backup
innobackupex --user=bkpuser  --password=bkppassword --no-timestamp /data/backups/full

# xtrabackup prepare backup
innobackupex --apply-log /data/backups/full

Guarde y salga. Ejecutar este script (con privilegios de superusuario) eliminará la copia de seguridad existente de XtraBackup en /data/backups/full y creará una nueva copia de seguridad completa. Más detalles sobre la creación de copias de seguridad con XtraBackup pueden encontrarse en la sección Realizar Copia de Seguridad completa activa del tutorial de XtraBackup.

Haga que el script sea ejecutable:

  1. sudo chmod +x /usr/local/bin/run_xtrabackup.sh

Para hacer una copia de seguridad correcta de nuestra base de datos, debemos ejecutar el script XtraBackup antes que Bacula intente hacer la copia de seguridad del servidor de bases de datos. Un buen enfoque es configurar tu trabajo de copia de seguridad de Bacula para que se ejecute el script como un “pre-script” de copia de seguridad, pero optaremos por usar una tarea cron para mantenerlo simple.

Cree un archivo de configuración de cron (los archivos en /etc/cron.d se agregan al crontab del usuario root):

  1. sudo vi /etc/cron.d/xtrabackup

Agregue la siguiente tarea cron:

/etc/cron.d/xtrabackup
30 22    * * *   root    /usr/local/bin/run_xtrabackup.sh

Esto programa la ejecución del script cada día a las 22:30 (hora 22, minuto 30). Seleccionamos esta hora porque Bacula está actualmente programado para ejecutar sus trabajos de copia de seguridad diariamente a las 23:05. Esto le permite 35 minutos para que el script XtraBackup se completen.

Ahora que los backups calientes de la base de datos están configurados, vamos a examinar los conjuntos de archivos de Bacula.

Configure Bacula FileSets

Bacula creará copias de seguridad de los archivos especificados en los conjuntos de archivos asociados con las tareas de respaldo que se ejecutarán. Este capítulo cubrirá la creación de los requeridos respaldos que identifiquemos en nuestros planes de recuperación. Más detalles sobre la adición de conjuntos de archivos a Bacula pueden encontrarse en la sección Agregar conjuntos de archivos (Servidor) del tutorial de Bacula.

En su servidor de respaldos, abre el archivo filesets.conf.

  1. sudo vi /etc/bacula/conf.d/filesets.conf

Conjunto de archivos para servidor de aplicaciones

Los respaldos necesarios para nuestro servidor de base de datos, según nuestro plan de recuperación del servidor de bases de datos, incluyen:

  • Base de datos MySQL: una copia de respaldo creada por nuestro script de XtraBackup alrededor de las 10:30 pm
  • Configuración de MySQL: ubicada en /etc/mysql

También incluiremos el script de XtraBackup: /usr/local/bin/run_xtrabackup.sh, y el archivo crónico asociado.

Con nuestros respaldos requeridos en mente, agregaremos este “Conjunto de archivos de Base de datos MySQL” a nuestra configuración de Bacula:

filesets.conf — MySQL Database
FileSet {
  Name = "MySQL Database"
  Include {
    Options {
      signature = MD5
      compression = GZIP
    }
    File = /data/backups
    File = /etc/mysql/my.cnf
    File = /usr/local/bin/run_xtrabackup.sh
    File = /etc/cron.d/xtrabackup
  }
  Exclude {
    File = /data/backups/exclude
  }
}

Ahora vamos a pasar al Conjunto de archivos del servidor de aplicaciones.

Conjunto de archivos del servidor de aplicaciones

Las copias de seguridad necesarias para nuestros servidores de aplicación, según nuestro plan de recuperación de servidores de aplicación, incluyen:

  • Archivos de la aplicación: ubicados en /var/www/html en nuestro ejemplo

Con nuestras copias de seguridad en mente, agregaremos este “Conjunto de archivos del servidor de documentos de Apache” a nuestra configuración de Bacula:

filesets.conf — Apache DocumentRoot
FileSet {
  Name = "Apache DocumentRoot"
  Include {
    Options {
      signature = MD5
      compression = GZIP
    }
    File = /var/www/html
  }
  Exclude {
    File = /var/www/html/exclude
  }
}

También podrías incluir el archivo de configuración de puertos del Apache, pero es fácilmente reemplazable.

Ahora vamos a pasar al siguiente paso y crear el conjunto de archivos del servidor de equilibrio de carga.

El conjunto de copias de seguridad requeridas para nuestros servidores de equilibrio de carga, según nuestro plan de recuperación de servidores de equilibrio de carga, incluyen:

  • Certificado SSL (PEM) y archivos relacionados: ubicados en /root/certs en nuestro ejemplo
  • Archivo de configuración de HAProxy: ubicado en /etc/haproxy

Con nuestras copias de seguridad en mente, agregaremos este “Conjunto de archivos del servidor de equilibrio de carga” a nuestra configuración de Bacula:

filesets.conf — SSL Certs and HAProxy Config
FileSet {
  Name = "SSL Certs and HAProxy Config"
  Include {
    Options {
      signature = MD5
      compression = GZIP
    }
    File = /root/certs
    File = /etc/haproxy
  }
  Exclude {
    File = /root/exclude
  }
}

Guarde y salga.

Ahora nuestros conjuntos de archivos están configurados. Continuemos con la creación de los Trabajos de copia de seguridad Bacula que utilizarán estos conjuntos de archivos.

Crear Trabajos de Copia de Seguridad Bacula

Crearemos Trabajos de copia de seguridad Bacula que ejecutarán y crearán copias de seguridad de nuestros servidores.

Crear un archivo jobs.conf en /etc/bacula/conf.d:

  1. sudo vi /etc/bacula/conf.d/jobs.conf

Trabajo de Copia de Seguridad del Servidor de Base de Datos

Para nuestro trabajo de copia de seguridad del servidor de base de datos, crearemos un nuevo trabajo llamado “Backup db1”. Lo importante aquí es que especificamos el correcto Cliente (db1-fd) y Conjunto de Archivos (Base de Datos MySQL):

jobs.conf — Backup db1
Job {
  Name = "Backup db1"
  JobDefs = "DefaultJob"
  Client = db1-fd
  Pool = RemoteFile
  FileSet="MySQL Database"
}

Ahora configuraremos los trabajos de copia de seguridad del servidor de aplicación.

Trabajos de Copia de Seguridad del Servidor de Aplicación

Para nuestros servidores de aplicación, crearemos dos trabajos de copia de seguridad llamados “Backup app1” y “Backup app2”. Lo importante aquí es que especificamos los correctos Clientes (app1-fd y app2-fd) y Conjunto de Archivos (Apache DocumentRoot).

Trabajo de App1:

jobs.conf — Backup app1
Job {
  Name = "Backup app1"
  JobDefs = "DefaultJob"
  Client = app1-fd
  Pool = RemoteFile
  FileSet="Apache DocumentRoot"
}

Trabajo de App2:

jobs.conf — Backup app2
Job {
  Name = "Backup app2"
  JobDefs = "DefaultJob"
  Client = app2-fd
  Pool = RemoteFile
  FileSet="Apache DocumentRoot"
}

Ahora configuraremos el trabajo de copia de seguridad del servidor de balanceador de carga.

Trabajo de Copia de Seguridad del Servidor de Balanceador de Carga

Para nuestro trabajo de copia de seguridad del servidor de balanceador de carga, crearemos un nuevo trabajo llamado “Copia de Seguridad lb1”. Lo importante aquí es que especifiquemos el Cliente (lb1-fd) y el Conjunto de Archivos (Certificados SSL y Configuración de HAProxy) correctos:

jobs.conf — Backup lb1
Job {
  Name = "Backup lb1"
  JobDefs = "DefaultJob"
  Client = lb1-fd
  Pool = RemoteFile
  FileSet="SSL Certs and HAProxy Config"
}

Guardar y salir.

Ahora nuestros trabajos de copia de seguridad están configurados. El último paso es reiniciar el Director de Bacula.

Reiniciar Director de Bacula

En el servidor de copias de seguridad, reinicie el Director de Bacula para poner todos nuestros cambios en efecto:

  1. sudo service bacula-director restart

En este punto, deseas probar tus conexiones de cliente y trabajos de respaldo, ambos de los cuales se cubren en la tutoria de cómo respaldar un servidor con Bacula. Este tutorial también cubre cómo restaurar copias de seguridad de Bacula. Nota que la restauración de la base de datos de MySQL requerirá seguir el paso Restore a Backup en la guía de Percona XtraBackup.

Revisión de horario de respaldos

El horario de respaldos de Bacula puede ser ajustado modificando la configuración del directorio de Bacula (/etc/bacula/bacula-dir.conf). Todos los trabajos de respaldo que creamos usan la definición de trabajo “DefaultJob”, que utiliza el plan de ciclo semanal, que está definido como:

  • Respaldo completo el primer domingo de un mes a las 11:05 pm
  • Respaldos diferenciales en todos los demás domingos a las 11:05 pm
  • Respaldos incrementales en otros días, lunes a sábados, a las 11:05 pm

Puedes verificar esto usando la consola de Bacula para checkear el estatus de los trabajos. Debería mostrarte todo los trabajos programados:

Director Status — Scheduled Jobs
Scheduled Jobs:
Level          Type     Pri  Scheduled          Name               Volume
===================================================================================
Incremental    Backup    10  20-May-15 23:05    BackupLocalFiles   MyVolume
Incremental    Backup    10  20-May-15 23:05    Backup lb1         Remote-0002
Incremental    Backup    10  20-May-15 23:05    Backup app2        Remote-0002
Incremental    Backup    10  20-May-15 23:05    Backup app1        Remote-0002
Incremental    Backup    10  20-May-15 23:05    Backup db1         Remote-0002

Libre de cambiar la programación de cualquier trabajo de copia de seguridad. Sería sensato modificar la programación de los servidores de aplicaciones para que ocurra al mismo tiempo que se ejecuta el script de Percona XtraBackup (10:30 pm). Esto evitará que las copias de seguridad de la aplicación y de la base de datos sean inconsistentes con cada otro.

Configure Remote Backups

Ahora estamos listos para configurar un servidor remoto que almacene copias de nuestras copias de seguridad de Bacula. Este servidor remoto debe estar en una región geográficamente separada de su centro de datos de producción para que tengas una copia de tus copias críticas de seguridad incluso si hay un desastre en tu centro de datos de producción. En nuestro ejemplo, usaremos la ubicación de San Francisco (SFO1) de DigitalOcean para nuestro servidor remotobackups.

Veremos una manera sencilla de enviar nuestras copias desde nuestro servidor de backups al servidor remotobackups usando claves públicas SSH, rsync y cron.

En el servidor remotobackups crea una cuenta que se utilizará para la sesión de logueo de rsync.

A continuación, en el servidor de respaldo, genere un par de claves SSH sin contraseña como root. Instale la clave pública en el usuario remotebackups que acaba de crear. Esto se cubre en nuestro tutorial Cómo configurar claves SSH.

En el servidor de respaldo, escriba una orden de rsync que copie los datos de respaldo de Bacula (/bacula/backup) a algún lugar en el servidor de remotebackups. El uso de rsync se cubre en nuestro tutorial Cómo usar Rsync. La orden probablemente se vea algo como esto:

  1. rsync -az /bacula/backup remoteuser@remotebackups_public_hostname_or_IP:/path/to/remote/backup

Añada la orden a un script, como por ejemplo /usr/local/bin/rsync_backups.sh y hágalo ejecutable.

Por último, configurará una tarea cron que ejecute el script rsync_backups.sh como root, después de que los trabajos de respaldo de Bacula generalmente se completen. Esto se cubre en nuestro tutorial Cómo programar tareas rutinarias con Cron.

Después de configurar todo esto, verifique que haya una copia de sus respaldos en el servidor de remotebackups el próximo día.

Otras Consideraciones

No hemos hablado sobre los requerimientos de disco para tus copias de seguridad. Deberás revisar cuánta espacio en disco tu copia de seguridad está usando y reevaluar tu configuración y horario de copias de seguridad basándote en tus necesidades y recursos.

Además de crear copias de seguridad de tus servidores de aplicaciones, probablemente querrás establecer una copia de seguridad para cualquier otro servidor que se agregue a tu configuración. Por ejemplo, deberías configurar Bacula para crear copias de seguridad de tus servidores de monitoreo y logística centralizada después de que los instales.

Conclusión

Ahora tienes copias diarias y una copia remota de esas copias de seguridad de tus servidores de aplicaciones de producción. Asegúrate de verificar que puedes restaurar los archivos y agrega las pasos de restauración de datos a tus planes de recuperación.

Continúe con el siguiente tutorial para comenzar a configurar la monitorización para tu configuración de servidores de producción: Construyendo para Producción: Aplicaciones Web — Monitorización.

Source:
https://www.digitalocean.com/community/tutorials/building-for-production-web-applications-backups