Rôle Ansible Backuppc-Client

Ce rôle, backuppc_client, installe et configure les deux côtés pour les hôtes clients d'un serveur Backuppc. Il fonctionne avec un rôle backuppc_server qui configure le serveur (Cependant, tant que la configuration est standard et qu'Ansible a accès, il peut gérer toute installation de serveur backuppc).

Il fonctionne sur Debian Buster (10) et Stretch (9) pour des configurations avancées (sauvegarde de bases de données), mais pour une configuration de sauvegarde backuppc de base, il peut gérer Ubuntu ou tout autre système basé sur Debian (PR acceptée).

Ce rôle et son homologue backuppc_server sont basés sur le rôle hanxhx/backuppc.

Description

Ce rôle configure les sauvegardes des hôtes sur un serveur BackupPC. Il peut effectuer les actions suivantes :

• Configurer un utilisateur Linux sur le client et une configuration de sauvegarde sur le serveur backuppc, qui accède au client avec cet utilisateur.
• En option, télécharger sur le client des scripts pre_dump et post_dump avec éventuellement des droits sudo, qui sont exécutés respectivement avant et après que backuppc crée des fichiers de sauvegarde. Ces scripts exécutent les commandes nécessaires pour avoir des sauvegardes cohérentes, telles que les sauvegardes de bases de données, les instantanés, etc.
• En option, configurer un utilisateur MySQL avec des droits SELECT sur toutes les bases, pour effectuer une sauvegarde avant la sauvegarde principale.
• En option, mettre en place un script qui dump une base de données PostgreSQL identifiée.

Exigences

Vous devez disposer d'un serveur Backuppc fonctionnel géré dans votre inventaire Ansible, dont le nom sera défini dans la variable backuppc_server_name.

À ce jour, ce rôle gère uniquement les sauvegardes via la méthode rsync (+ ssh).

Compatibilité ascendante

Pour garantir une adoption progressive de cette version du rôle sur tous les hôtes qui l'utilisent dans un environnement cloud, le rôle est compatible avec l'API des variables de la v1.X.0, y compris ses valeurs par défaut. Consultez les fichiers defaults/main.yml et tasks/compatibility.yml, en particulier les commentaires, pour prendre en compte les variables héritées.

La compatibilité des rôles sera abandonnée dans la prochaine version majeure, alors adaptez vos variables d'hôtes dès que possible !

Variables du rôle

Chaque configuration client remplace la configuration globale sur le serveur. Voir defaults/main.yml pour les valeurs ou définitions des variables par défaut. Voici les variables qui peuvent être définies.

Accès client

• backuppc_client_user: utilisateur unix pour que le serveur se connecte au client (par défaut backuppc)
• backuppc_client_group: groupe unix de l'utilisateur unix défini ci-dessus (par défaut backuppc)
• backuppc_client_home: répertoire personnel de l'utilisateur backuppc_client_user qui effectue les sauvegardes sur le client

Configuration du serveur

• backuppc_server_name: nom de domaine du serveur BackupPC qui effectue la sauvegarde et où la clé ssh est récupérée pour être configurée sur le client
• backuppc_server_user: utilisateur unix qui exécute BackupPC sur le serveur. Par défaut, backuppc.
• backuppc_server_group: groupe unix qui exécute BackupPC sur le serveur. Par défaut, www-data.
• backuppc_server_home: répertoire personnel de l'utilisateur unix BackupPC sur le serveur. Par défaut, /var/lib/backuppc.
• backuppc_server_config_dir: répertoire des fichiers de configuration du package BackupPC. Par défaut, /etc/backuppc.

Configuration de la sauvegarde du client sur le serveur

Voici brièvement décrites les variables du rôle qui définissent la configuration BackupPC du client sur le serveur. Pour une documentation complète, voir documentation BackupPC.

Les drapeaux suivants définissent si le client et le serveur sont configurés par le rôle :

• backuppc_backup_state: absent ou présent (par défaut : présent). Si présent, configure les sauvegardes du client sur le serveur, sinon élimine la configuration.
• backuppc_client: s'il est défini sur false (valeur par défaut true), il n'y a pas d'accès ssh ou d'autre configuration sur l'hôte client, seul le serveur est configuré pour sauvegarder l'hôte.

Le fichier de configuration du client sur le serveur BackupPC est construit avec les variables suivantes :

• backuppc_rsync_share_names: liste des points d'arborescence des dossiers sur le client à sauvegarder. Par exemple :

backuppc_rsync_share_names:
- /etc
- /root
- /var
- /usr/local

Avec la méthode rsync, BackupPC effectuera une commande rsync pour chaque élément de cette liste.

• backuppc_include_files:: liste des dossiers à inclure dans la sauvegarde du client (l'option --include de rsync sera construite avec cette variable)
• backuppc_exclude_files:: liste des dossiers à exclure de la sauvegarde du client (l'option --exclude de rsync sera construite avec cette variable)
• backuppc_xfermethod: Méthode de transfert optionnelle (rsync par défaut)
• backuppc_more: Hash optionnel avec des clés/valeurs spécifiques (utile pour des directives personnalisées, telles que la planification et la conservation des sauvegardes). Voir exemple dans le fichier defaults/main.yml.

Les variables suivantes permettent de définir l'exécution des scripts de dump de fichiers pre et post par BackupPC :

• backuppc_pre_dump_script: chemin du fichier du script de dump pré-sauvegarde, que BackupPC exécutera avant de dumper des fichiers pendant une sauvegarde. Sa valeur par défaut est '{{ backuppc_client_home }}/scripts/pre_dump.sh'
• backuppc_post_dump_script: chemin du fichier du script de dump post-sauvegarde, que BackupPC exécutera après avoir dumpé les fichiers pendant une sauvegarde. Sa valeur par défaut est '{{ backuppc_client_home }}/scripts/post_dump.sh'
• backuppc_scripts_local_dir: chemin sur le contrôleur Ansible local où le playbook trouvera les deux scripts précédents pour les installer sur le client. Sa valeur par défaut est '{{ playbook_dir }}/host_vars/{{ inventory_hostname }}/files/backuppc/'. Ainsi, dans la structure des répertoires de votre playbook, vous devrez placer les scripts de dump pré et post, dans des fichiers portant les mêmes noms que leurs chemins respectifs ci-dessus, dans un dossier nommé files/backuppc, à côté du dossier vars de l'hôte que vous configurez :

 host_vars
 └── <votre_hôte>
     ├── files
     │   └── backuppc
     │       ├── post_dump.sh
     │       └── pre_dump.sh
     └── vars
         ├── 10_kvm_virtual.yml
         └── 20_backuppc.yml

• backuppc_scripts: Drapeau vrai/faux pour installer les scripts de dump pré et post décrits précédemment. Ce drapeau est obsolète. Il est conservé pour des raisons de compatibilité, mais dans la prochaine version majeure, il sera supprimé, et les scripts seront installés lorsque leur chemin est défini.

• backuppc_scripts_sudo: drapeau vrai/faux pour donner des droits d'accès sudo aux scripts de dump pré et post.

• backuppc_DumpPreUserCmd et backuppc_DumpPostUserCmd: commandes ssh pour que backuppc exécute les scripts pre_dump et post_dump. Ces variables sont prédéfinies en fonction des drapeaux précédents, mais peuvent être écrasées.

• backuppc_sudoer les commandes autorisées avec sudo pour l'utilisateur backuppc_client_user. C'est une chaîne qui peut être écrasée, à condition qu'elle commence par Cmnd_Alias BACKUPS =, suivi de la liste des commandes shell que l'utilisateur doit exécuter pour effectuer une sauvegarde. Par défaut, cette variable inclut rsync, et éventuellement les scripts de dump pré et post, selon les drapeaux précédents.

Les variables suivantes fournissent des outils pour définir, à l'aide des scripts décrits ci-dessus, le dump des bases de données pour la cohérence des sauvegardes :

• backuppc_db_server_type: variable à trois états qui définit un éventuel dump MySQL ou pgsql avant les sauvegardes. Les trois valeurs possibles sont : pgsql, mysql ou null. Le comportement des scripts et des sauvegardes de bases de données est différent pour MySQL et pgsql. En particulier, pour MySQL, vous devez ajouter vous-même les scripts pre_dump.sh et post_dump.sh qui effectuent le dump des bases de données, tandis que pour PostgreSQL, ces scripts sont construits à partir de modèles (et ne dumpent qu'une seule base de données). Pour PostgreSQL, les droits sur la base de données doivent être précédemment définis, tandis que pour MySQL, la tâche assignera les droits d'accès à la base de données à un utilisateur donné.
• Pour PostgreSQL, les variables sont :
  • backuppc_db_to_dump_name définit la base de données pgsql à sauvegarder,
  • backuppc_db_dump_user définit l'utilisateur pgsql pour accéder à la base de données,
  • backuppc_db_dump_user_pass est le mot de passe de l'utilisateur précédent. La configuration des mots de passe et des privilèges de cet utilisateur sur la base de données doit être effectuée ailleurs dans le playbook.
• Pour MySQL, les variables sont :
  • backuppc_db_server_root_pass doit être défini sur la valeur appropriée si l'utilisateur root de MySQL a un mot de passe défini. Par défaut, la variable est indéfinie. Il convient de noter que, dans les installations récentes de mysql/mariadb, du moins sous Debian, l'installation de mysql ne demande pas de mot de passe root et ne génère pas aléatoirement de mot de passe root. La maintenance de Debian ne se fait plus avec un utilisateur et un mot de passe spécifiques, mais avec l'utilisateur root via un socket unix et non un socket tcp authentifié. Si la variable reste indéfinie, les tâches mysql seront effectuées en utilisant la configuration de maintenance de Debian.
  • backuppc_db_dump_user et backuppc_db_dump_user_pass sont le nom de l'utilisateur MySQL et le mot de passe correspondant, qui seront donnés en accès SELECT sur toutes les bases et seront configurés par défaut dans le fichier .my.cnf dans le répertoire personnel de l'utilisateur unix backuppc_client_user. Ainsi, les scripts pre_dump.sh ou post_dump.sh pourront effectuer n'importe quel dump de base de données en appelant une simple commande mysql.

Les variables suivantes configurent l'accès web pour les sauvegardes de l'hôte client sur l'interface web de BackupPC :

• backuppc_server_web_main_user: utilisateur principal ayant accès aux sauvegardes de l'hôte client via l'interface web BackupPC. Par défaut, backuppc.
• backuppc_server_web_other_users: autres utilisateurs ayant accès aux sauvegardes de l'hôte client via l'interface web BackupPC. Doit être défini sous la forme d'une chaîne listant les utilisateurs séparés par des virgules : "user1,user2". L'accès des utilisateurs doit être configuré sur le serveur BackupPC.

Exemples de scripts MySQL

Pour une sauvegarde MySQL, pour dumper toutes les bases de données avant le dump des fichiers, vous pouvez utiliser les scripts suivants, qui utiliseront l'utilisateur de sauvegarde backuppc configuré par le rôle :

• pre_dump.sh

#!/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

• post_dump.sh

#!/bin/bash
rm dump.sql.tar.gz

Exemple de Playbook

Nous considérons qu'un serveur BackupPC standard fonctionne à bck-server.domain.org, géré par l'inventaire Ansible. Le playbook suivant configure sur ce serveur la sauvegarde des dossiers spécifiés de l'hôte client.domain.org, avec l'accès ssh nécessaire.

- name: Sauvegarde de l'hôte client.domain.org
  hosts: client.domain.org
  become: true
  vars:
  - backuppc_server_name: bck-server.domain.org
  - backuppc_rsync_share_names:
    - /etc
    - /var
    - /opt

  roles:
  - role: udelarinterior.backuppc_client

Licence

GPLv3

Informations sur l'auteur

Rôle original Emilien M amélioré par Víctor Torterola et Daniel Viñar