Construire pour la production : Applications Web — Sauvegardes

Tutoriels
Backups MySQL Ubuntu

Introduction

Après avoir élaboré un plan de récupération pour les différents composants de votre application, vous devez configurer le système de sauvegarde requis pour le soutenir. Ce tutoriel se concentrera sur l’utilisation de Bacula comme solution de sauvegarde. Les avantages d’utiliser un système de sauvegarde complet comme Bacula, c’est qu’il vous donne un contrôle total sur ce que vous sauvegardez et restaurerez au niveau des fichiers individuels, et vous pouvez planifier les sauvegardes et les restaurations selon ce qui est le mieux pour vous.

Des solutions telles que DigitalOcean Droplet Backups (sauvegardes instantanées de votre entire Droplet) sont faciles à mettre en place et peuvent être suffisantes pour vos besoins, si vous avez besoin de sauvegardes hebdomadaires seulement. Si vous optez pour les Sauvegardes DigitalOcean, n’oubliez pas de configurer des sauvegardes à chaud de votre base de données en suivant la section Créer des Sauvegardes à Chaud de Votre Base de Données.

Dans cette partie du tutoriel, nous allons configurer un Bacula pour effectuer des sauvegardes journalières des sauvegardes nécessaires des serveurs composant votre configuration d’application (db1, app1, app2 et lb1), définis précédemment dans notre plan de récupération – en résumé, c’est un tutoriel qui vous montre comment utiliser Bacula pour créer des sauvegardes d’une pile LAMP. Nous utiliserons également Percona XtraBackup pour créer des sauvegardes à chaud de votre base de données MySQL. Enfin, nous utiliserons rsync pour créer une copie de vos sauvegardes sur un serveur situé dans un centre de données distant. Cela ajoutera deux serveurs à votre configuration : backups et remotebackups (situé dans un centre de données séparé).

Commençons.

Installer Bacula sur le serveur de sauvegardes

Configurez Bacula sur votre serveur backups en suivant ce tutoriel : Comment installer le serveur Bacula sur Ubuntu 14.04 .

Suite à cela, veuillez suivre la section Organiser la Configuration du Directeur Bacula (Serveur) du tutoriel : Comment faire une Sauvegarde d’un Serveur Ubuntu 14.04 avec Bacula. Vous aurez besoin du nom du Directeur lors de la configuration des clients Bacula (sur les serveurs que vous souhaitez sauvegarder). Arrêtez quand vous arrivez à la section Installer et Configurer le Client Bacula.

Notez que nous utiliserons le pool RemoteFile pour toutes les jobs de sauvegarde que nous configurons. Cela dit, vous pourriez souhaiter modifier certaines des configurations avant de poursuivre.

Installer le Client Bacula sur Chaque Serveur

Installez le client Bacula sur chaque serveur que vous voulez sauvegarder (db1, app1, app2 et lb1) en suivant la section Installer et Configurer le Client Bacula du tutoriel : Comment faire une Sauvegarde d’un Serveur Ubuntu 14.04 avec Bacula. Arrêtez quand vous arrivez à la section Ajouter des FichiersSets (Serveur).

Notez que vous devez avoir le Nom du démon de fichiers (qui est généralement le nom de l’hôte ajouté par « -fd ») et le Mot de passe du directeur (le mot de passe que le serveur Bacula utilisera pour se connecter à chaque client) dans le fichier /etc/bacula/conf.d/clients.conf sur chaque serveur.

Ajouter des clients Bacula au serveur de sauvegarde

Sur sauvegardes, le serveur Bacula, ajoutez une ressource Client au fichier /etc/bacula/conf.d/clients.conf pour chaque serveur sur lequel vous avez installé le client Bacula.

Ouvrez le fichier clients.conf :

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

Voici un exemple de définition de ressource Client pour le serveur de base de données, db1. Noter que la valeur de Name doit correspondre au nom de la ressource FileDaemon et la valeur de Password doit correspondre au mot de passe de la ressource Director , sur le serveur client — ces valeurs peuvent être trouvées dans /etc/bacula/bacula-fd.conf sur chaque serveur de client 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
}

Créez une ressource Client similaire pour chacun des serveurs restants. En notre exemple, il y aura quatre ressources Client lorsqu’on est terminé : db1-fd, app1-fd, app2-fd, et lb1-fd. Cela configure le serveur Directeur de Bacula, sur le serveur sauvegardes , à pouvoir se connecter à chaque serveur client…

Enregistrer et quitter.

Vous trouverez plus de détails sur cette section dans la section Installer et Configurer le Client Bacula de la tutorielle Comment Sauvegarder un Serveur Ubuntu avec Bacula.

Créer des Sauvegardes à chaud de votre Base de Données

Pour garantir que nous produisons des sauvegardes cohérentes (c’est-à-dire utilisables) de notre base de données active, un soin particulier doit être pris. Une manière simple et efficace de créer des sauvegardes à chaud avec MySQL est d’utiliser Percona XtraBackup.

Installer Percona XtraBackup

Sur votre serveur de base de données, db1, installez et configurez Percona XtraBackup en suivant ce tutoriel : Comment Créer des Sauvegardes à Chaud de Bases de Données MySQL avec Percona XtraBackup sur Ubuntu 14.04. Arrêtez-vous lorsque vous atteignez la section Effectuer une Sauvegarde à Chaud Complète.

Créer un Script pour XtraBackup

Percona XtraBackup est prêt pour créer des sauvegardes chaudes de votre base de données MySQL, qui seront ultérieurement complétées par Bacula (ou par les Sauvegardes de DigitalOcean), mais les sauvegardes chaudes doivent être planifiées d’une certaine manière. Nous allons configurer la solution la plus simple : un script bash et un emploi du temps.

Créez un script bash nommé run_extra_backup.sh dans /usr/local/bin :

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

Ajoutez le script suivant. Assurez-vous de remplacer l’utilisateur et le mot de passe par ce que vous avez configuré lors de l’installation d’XtraBackup :

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

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

# supprimer la sauvegarde complète existante
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

Enregistrez et quittez. Exécuter ce script (avec les privilèges de superutilisateur) supprimera la sauvegarde existante d’XtraBackup à /data/backups/full et créera une nouvelle sauvegarde complète. De plus amples détails sur la création de sauvegardes avec XtraBackup peuvent être trouvés dans la section Effectuer une Sauvegarde Chauffée Complète du tutoriel XtraBackup.

Rendez le script exécutable :

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

Pour effectuer une sauvegarde correcte de notre base de données, nous devons exécuter le script XtraBackup avant que Bacula essaye de sauver la serveur de bases de données. Une bonne solution consiste à configurer votre travail de sauvegarde Bacula pour exécuter le script en tant que « pré-sauvegarde », mais nous choisirons d’utiliser un job cron simplement.

Créez un fichier de configuration de cron (les fichiers dans /etc/cron.d sont ajoutés au crontab du root):

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

Ajoutez les lignes suivantes au fichier de configuration de cron:

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

Ceci planifie l’exécution du script tous les jours à 22h30 (30e minute du 22e heure). Nous avons choisi ce moment car Bacula est actuellement programmé à exécuter ses travaux de sauvegarde tous les soirs à 23h05. Cela permet de disposer de 35 minutes pour que le script XtraBackup se termine.

Maintenant que les sauvegardes en ligne de base de données sont mises en place, examinons les ensemble de fichiers de Bacula.

Configurer les ensemble de fichiers Bacula

Bacula créera des sauvegardes des fichiers spécifiés dans les FileSets associés aux travaux de sauvegarde qui seront exécutés. Cette section couvrira la création de FileSets qui incluent les sauvegardes nécessaires que nous avons identifiées dans nos plans de récupération. Vous trouverez plus de détails sur l’ajout de FileSets à Bacula dans la section Ajouter des FileSets (Serveur) du tutoriel Bacula.

Sur votre serveur de sauvegardes, ouvrez le fichier filesets.conf :

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

Serveur de base de données FileSet

Les sauvegardes nécessaires pour notre serveur de base de données, selon notre plan de récupération du serveur de base de données, incluent :

  • Base de données MySQL : une copie de sauvegarde est créée par notre script XtraBackup dans /data/backups/full, quotidienne à 22h30
  • Configuration MySQL : située dans /etc/mysql

Nous inclurons également le script XtraBackup : /usr/local/bin/run_xtrabackup.sh, et le fichier cron associé.

Avec en tête nos sauvegardes nécessaires, nous ajouterons ce FileSet « MySQL Database » à notre configuration 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
  }
}

Maintenant, passons au FileSet du serveur d’application.

Application Server FileSet

Les sauvegardes nécessaires pour nos serveurs d’application, selon notre plan de récupération des serveurs d’application, incluent :

  • Fichiers de l’application : situés dans /var/www/html par exemple

Avec les sauvegarde requises en tête, nous ajouterons cette « FileSet du serveur Apache » à notre configuration 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
  }
}

Vous pouvez également inclure le fichier de configuration des ports Apache, mais cela est facilement remplacable.

Maintenant, passons à la création du « FileSet du serveur de load balancer ».

Load Balancer Server FileSet

Les sauvegardes nécessaires pour nos serveurs de load balancer, selon notre plan de récupération des serveurs de load balancer, incluent :

  • Certificat SSL (PEM) et fichiers associés : situés dans /root/certs dans notre exemple
  • Fichier de configuration HAProxy : situé dans /etc/haproxy

Avec nos sauvegarde en tête, nous ajouterons ce « FileSet du serveur Apache » à notre configuration 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
  }
}

Sauvegardez et sortez.

Maintenant, nous avons configuré les ensembles de fichiers. Alors, passons à la création des travaux de sauvegarde Bacula qui utiliseront ces ensembles de fichiers.

Créer des travaux de sauvegarde Bacula

Nous allons créer des travaux de sauvegarde Bacula pour utiliser ces ensembles de fichiers.

Créez un fichier jobs.conf dans /etc/bacula/conf.d :

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

Sauvegarde du serveur de base de données

Pour notre travail de sauvegarde du serveur de base de données, nous créerons un nouveau travail nommé « Backup_db1 ». L’important ici est de spécifier le bon Client (db1-fd) et FileSet (MySQL Database) :

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

Maintenant, nous établirons les travaux de sauvegarde pour les serveurs d’application.

Travaux de sauvegarde des serveurs d’application

Pour nos serveurs d’application, nous créerons deux travaux de sauvegarde nommés « Backup app1 » et « Backup app2 ». L’important ici est que nous spécifions le bon Client (app1-fd et app2-fd) et FileSet (DocumentRoot Apache).

Travail app1 :

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

App2 travail :

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

Maintenant, nous configurons le travail de sauvegarde du serveur de balancement de charge.

Travail de sauvegarde du serveur de balancement de charge

Pour notre travail de sauvegarde du serveur de balancement de charge, nous créerons un nouveau travail nommé « Backup lb1 ». L’élément crucial ici est que nous spécifions correctement le Client (lb1-fd) et Fichier de sélection (SSL Certs et configuration HAProxy) :

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

Sauvegardez et sortez.

Maintenant, tous les travaux de sauvegarde sont configurés. La dernière étape consiste à redémarrer le directeur de Bacula.

Redémarrer le directeur de Bacula

Sur le serveur de backups, redémarrezz le directeur de Bacula pour mettre en application toutes les modifications effectuées :

  1. sudo service bacula-director restart

À ce stade, vous voulez tester les connexions clients et les travaux de sauvegarde, qui sont couverts dans le tutoriel Comment faire une sauvegarde d’un serveur avec Bacula. Ce tutoriel également couvre comment restaurer des sauvegardes Bacula. Noter que la restauration de la base de données MySQL nécessitera de suivre l’étape Restaurer une sauvegarde du tutoriel Percona XtraBackup.

Réviser le plan de sauvegarde

Le plan de sauvegarde Bacula peut être ajusté en modifiant la configuration du directeur de Bacula (/etc/bacula/bacula-dir.conf). Toutes les tâches de sauvegarde créées utilisent le job « DefaultJob » qui utilise le « WeeklyCycle » défini comme suit :

  • Sauvegarde complète le premier dimanche de chaque mois à 11h05
  • Sauvegardes différentielles sur tous les autres dimanches à 11h05
  • Sauvegardes incrémentales les autres jours, lundi au samedi, à 11h05

Vous pouvez vérifier cela en utilisant la console Bacula pour voir le statut du directeur. Il devrait afficher tous les travaux programmés :

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 à tous de modifier le calendrier de tout travail de sauvegarde que vous souhaitez. Il serait raisonnable de modifier le calendrier des serveurs d’application pour qu’il se déroule au même moment que la commande du script Percona XtraBackup (10h30). Cela évitera que les sauvegardes de l’application et de la base de données ne soient inconsistantes avec chacune autre.

Configurer les sauvegardes distantes

Nous sommes maintenant prêts à configurer un serveur distante qui stockera des copies de nos sauvegardes Bacula. Ce serveur distante doit être dans une région géographiquement séparée de votre centre de données de production, ainsi vous avez une copie de vos sauvegardes critiques même si il y a une catastrophe au centre de données de production. Dans notre exemple, nous utiliserons la région de San Francisco (SFO1) de DigitalOcean pour notre serveurdistant.

Nous explicons ici une méthode simple pour envoyer nos sauvegardes depuis notre serveurdebackups vers notre serveurdistant en utilisant les clés publiques SSH, rsync, et cron.

Sur le serveurdistant, créez un utilisateur qui sera utilisé pour la connexion rsync.

Suivant, sur le serveur de sauvegarde , générez un couple de clés SSH avec la permission du superutilisateur. Installez la clé publique sur l’utilisateur que vous avez juste créé. Cela est couvert dans notre tutoriel Comment configurer les clés SSH.

Sur le serveur de sauvegarde, écrivez une commande rsync qui copie les données de sauvegarde Bacula (/bacula/backup) vers un endroit sur le serveur de sauvegarde distante. L’utilisation de rsync est couverte dans notre tutoriel Comment utiliser Rsync. La commande sera probablement comme ceci:

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

Ajoutez la commande au fichier de script, par exemple /usr/local/bin/rsync_backups.sh et faites-le executable.

Enfin, vous voulez ajouter un emploi à cron qui exécute le script rsync_backups.sh en tant que root après que les travaux de sauvegarde Bacula habituellement se soient terminés. Cela est couvert dans notre tutoriel Comment planifier des tâches régulières avec Cron.

Après avoir mis tout cela en place, vérifiez que les sauvegardes sont copiées sur le serveur de sauvegarde distante le lendemain.

Autres considérations

Nous n’avons pas discuté des exigences en termes de disques pour vos sauvegarde. Vous devez certainement examiner comment votre système de sauvegarde utilise l’espace disque et modifier votre configuration et votre horaire de sauvegarde en fonction de vos besoins et des ressources disponibles.

En outre, après avoir créé des sauvegardes de vos serveurs d’application, vous devrez probablement configurer Bacula pour créer des sauvegardes des autres serveurs qui sont ajoutés à votre déploiement. Par exemple, vous devez configurer Bacula pour créer des sauvegardes des serveurs de surveillance et de journalisation centralisé une fois que vous les avez mis en place.

Conclusion

Vous devriez maintenant disposer de sauvegardes journalières et d’une copie distante de ces sauvegardes sur vos serveurs de production. Veillez à vérifier que vous pouvez restaurer les fichiers et ajoutez les étapes de restauration de données à votre plan de récupération.

Continuez au prochain tutoriel pour commencer à configurer la surveillance de votre déploiement de serveurs de production : Bâtir pour la production : applications web — Surveillance.

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