BackupPC-Client Ansible-Rolle

Diese Rolle, backuppc_client, installiert und konfiguriert beide Seiten für Client-Hosts eines BackupPC-Servers. Sie arbeitet mit der Rolle backuppc_server, die den Server konfiguriert (jedoch kann sie, solange die Konfiguration standardmäßig und Ansible Zugriff hat, jede Installation eines BackupPC-Servers handhaben).

Die Rolle funktioniert auf Debian Buster (10) und Stretch (9) für erweiterte Konfigurationen (Datenbank-Backups), aber für die grundlegende BackupPC-Dumpkonfiguration kann sie auch unter Ubuntu oder anderen Debian-basierten Systemen eingesetzt werden (Beiträge sind willkommen).

Diese Rolle und ihre Partnerrolle backuppc_server basieren auf der Rolle hanxhx/backuppc.

Beschreibung

Diese Rolle konfiguriert die Backups von Hosts in einem BackupPC Server. Sie kann folgende Aktionen ausführen:

• Ein Linux-Benutzer auf dem Client einrichten und eine Backup-Konfiguration auf dem BackupPC-Server, der sich mit diesem Benutzer am Client anmeldet.
• Optional skripte für vor und nach dem Dump (pre_dump und post_dump) mit möglichen sudo-Rechten hochladen, die jeweils vor und nach dem Backup von BackupPC ausgeführt werden. Diese Skripte führen notwendige Befehle aus, um konsistente Backups zu gewährleisten, wie Datenbank-Dumps, Snapshots usw.
• Optional einen MySQL-Benutzer mit SELECT-Rechten für alle Datenbanken einrichten, um vor dem Backup einen Dump durchzuführen.
• Optional ein Skript einrichten, das eine bestimmte PostgreSQL-Datenbank dumpt.

Anforderungen

Sie benötigen einen laufenden BackupPC-Server, der in Ihrem Ansible-Inventar verwaltet wird und dessen Name in der Variablen backuppc_server_name definiert wird.

Aktuell verwaltet diese Rolle Backups nur über die rsync (+ ssh) Methode.

Rückwärtskompatibilität

Um einen reibungslosen und schrittweisen Übergang zu dieser Version der Rolle über alle Hosts in einer Cloud-Umgebung zu gewährleisten, ist die Rolle rückwärtskompatibel mit der API der v1.X.0 Variablen. Dazu gehören auch die Standardwerte. Sehen Sie die Dateien defaults/main.yml und tasks/compatibility.yml für Kommentare zu Legacy-Variablen.

Die Rückwärtskompatibilität der Rolle wird in der nächsten Hauptversion fallen gelassen, passen Sie daher Ihre Host-Variablen-API so schnell wie möglich an!

Rollenvariablen

Jede Clientkonfiguration überschreibt die globalen Einstellungen auf dem Server. Sehen Sie defaults/main.yml für Standardwerte oder Definitionen. Im Folgenden sind die möglichen Variablen aufgeführt.

Client-Zugriff

• backuppc_client_user: Unix-Benutzer, mit dem sich der Server mit dem Client verbindet (Standardwert backuppc)
• backuppc_client_group: Unix-Gruppe des oben definierten Unix-Benutzers (Standardwert backuppc)
• backuppc_client_home: Heimatverzeichnis des backuppc_client_user, der die Backups auf dem Client durchführt

Serverkonfiguration

• backuppc_server_name: Domainname des BackupPC-Servers, der das Backup durchführt und von dem der SSH-Schlüssel für den Client abgerufen wird
• backuppc_server_user: Unix-Benutzer, der BackupPC auf dem Server ausführt. Standardmäßig backuppc.
• backuppc_server_group: Unix-Gruppe, die BackupPC auf dem Server ausführt. Standardmäßig www-data.
• backuppc_server_home: Heimatverzeichnis des BackupPC-Unix-Benutzers auf dem Server. Standardmäßig /var/lib/backuppc.
• backuppc_server_config_dir: Verzeichnis der BackupPC-Paketkonfigurationsdateien. Standardmäßig /etc/backuppc.

Client-Backup-Konfiguration auf dem Server

Hier sind kurz die Variablen beschrieben, die die BackupPC-Konfiguration des Clients auf dem Server definieren. Für eine vollständige Dokumentation siehe die BackupPC-Dokumentation.

Die folgenden Flags definieren, ob Client und Server von der Rolle konfiguriert sind:

• backuppc_backup_state: absent oder present (Standard: present). Wenn vorhanden, konfiguriert es die Backups des Clients auf dem Server, sonst wird die Konfiguration entfernt.
• backuppc_client: Wenn auf false gesetzt (Standardwert true), gibt es keinen SSH-Zugriff oder andere Konfigurationen auf dem Client-Host, nur der Server wird konfiguriert, um den Host zu sichern.

Die Konfigurationsdatei des Clients auf dem BackupPC-Server wird mit den folgenden Variablen erstellt:

• backuppc_rsync_share_names: Liste von Verzeichnissen auf dem Client, die gesichert werden sollen. Zum Beispiel:

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

Mit der rsync-Methode führt BackupPC einen rsync-Befehl für jedes Element dieser Liste aus.

• backuppc_include_files:: Liste von Verzeichnissen, die in das Backup des Clients eingeschlossen werden sollen (die --include-Option von rsync wird mit dieser Variablen erstellt)
• backuppc_exclude_files:: Liste von Verzeichnissen, die vom Backup des Clients ausgeschlossen werden sollen (die --exclude-Option von rsync wird mit dieser Variablen erstellt)
• backuppc_xfermethod: Optionale Übertragungsmethode (standardmäßig rsync)
• backuppc_more: Optionales Hash mit spezifischen Schlüssel/Wert-Paaren (nützlich für benutzerdefinierte Direktiven, wie die Backup-Planung und -Aufbewahrung). Siehe Beispiel in der Datei defaults/main.yml.

Die folgenden Variablen ermöglichen die Ausführung von vor- und nach-Dump-Skripten durch BackupPC:

• backuppc_pre_dump_script: Pfad zu der Datei des vor Dump-Skripts, das BackupPC vor dem Dumping von Dateien während eines Backups ausführt. Der Standardwert ist '{{ backuppc_client_home }}/scripts/pre_dump.sh'
• backuppc_post_dump_script: Pfad zu der Datei des nach Dump-Skripts, das BackupPC nach dem Dumpen von Dateien während eines Backups ausführt. Der Standardwert ist '{{ backuppc_client_home }}/scripts/post_dump.sh'
• backuppc_scripts_local_dir: Pfad im lokalen Ansible-Controller, wo das Playbook die beiden vorherigen Skripte findet, um sie auf dem Client zu installieren. Der Standardwert ist '{{ playbook_dir }}/host_vars/{{ inventory_hostname }}/files/backuppc/'. Daher müssen Sie in der Verzeichnisstruktur Ihres Playbooks die vor und nach Dump-Skripte in Dateien mit denselben Basenamen wie hier angegeben ablegen, in einem Ordner namens files/backuppc, neben dem vars-Ordner des Hosts, den Sie konfigurieren:

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

• backuppc_scripts: Flag für Skripte (true/false). Wenn true, installiert es die zuvor beschriebenen vor und nach Dump-Skripte. Dieses Flag ist veraltet. Es wurde zur Rückwärtskompatibilität beibehalten, wird aber in der nächsten Hauptversion entfernt, und die Skripte werden installiert, wenn ihr Pfad definiert ist.

• backuppc_scripts_sudo: true/false-Flag, um sudo-Zugriffsrechte für vor und nach Dump-Skripte zu gewähren.

• backuppc_DumpPreUserCmd und backuppc_DumpPostUserCmd: SSH-Befehle für den BackupPC, um die pre_dump- und post_dump-Skripte auszuführen. Diese Variablen sind vordefiniert, können jedoch überschrieben werden.

• backuppc_sudoer: die Befehle, die für den backuppc_client_user-Benutzer mit sudo autorisiert sind. Es ist eine Zeichenfolge, die überschrieben werden kann, solange sie mit Cmnd_Alias BACKUPS = beginnt, gefolgt von der Liste der Shell-Befehle, die der Benutzer ausführen muss, um ein Backup durchzuführen. Vordefiniert umfasst diese Variable rsync und gegebenenfalls die vor und nach Dump-Skripte, je nach vorherigen Flags.

Die folgenden Variablen bieten einige Werkzeuge, um mit den oben beschriebenen Skripten die Dumps von Datenbanken für konsistente Backups zu definieren:

• backuppc_db_server_type: Drei-Zustands-Variable, die eventuelle MySQL- oder pgSQL-Dumps vor Backups definiert. Die drei möglichen Werte sind: pgsql, mysql oder null. Das Verhalten der Skripte und der Datenbank-Backups ist unterschiedlich für MySQL und pgSQL. Insbesondere müssen Sie für MySQL selbst die Skripte pre_dump.sh und post_dump.sh hinzufügen, die die Datenbanken dumpen, während diese Skripte für PostgreSQL aus Vorlagen erstellt werden (und sie dumpen nur eine Datenbank). Bei PostgreSQL müssen die Rechte auf die Datenbank zuvor definiert werden, während bei MySQL Aufgaben die Zugriffsrechte auf die Datenbank einem bestimmten Benutzer zuweisen.
• Für PostgreSQL sind die Variablen:
  • backuppc_db_to_dump_name definiert die pgsql-Datenbank, die gesichert werden soll,
  • backuppc_db_dump_user definiert den pgsql-Benutzer zum Zugriff auf die Datenbank,
  • backuppc_db_dump_user_pass ist das Passwort des vorherigen Benutzers. Die Einrichtung von Passwörtern und Rechten dieses Benutzers auf der Datenbank muss an anderer Stelle im Playbook erfolgen.
• Für MySQL sind die Variablen:
  • backuppc_db_server_root_pass sollte auf den entsprechenden Wert gesetzt werden, wenn der MySQL root-Benutzer ein definiertes Passwort hat. Standardsmäßig ist die Variable undefiniert. Es ist zu beachten, dass bei neueren MySQL/MariaDB-Installationen, zumindest auf Debian, bei der Installation kein Root-Passwort angefragt und nicht zufällig generiert wird. Die Wartung von Debian erfolgt nicht mehr mit einem bestimmten Benutzer und Passwort, sondern mit dem Benutzer root über einen Unix-Sock und nicht über einen TCP-authentifizierten Sock. Wenn die Variable undefiniert bleibt, werden die MySQL-Aufgaben mithilfe der Debian-Wartungskonfiguration durchgeführt.
  • backuppc_db_dump_user und backuppc_db_dump_user_pass sind der Name des MySQL-Benutzers und das entsprechende Passwort, das SELECT-Zugriff auf alle Datenbanken erhält und als Standard in der .my.cnf-Datei im Heimatverzeichnis des backuppc_client_user Unix-Benutzers konfiguriert wird. Daher können die Skripte pre_dump.sh oder post_dump.sh jeden Datenbank-Dump mit einem einfachen MySQL-Befehl durchführen.

Die folgenden Variablen konfigurieren den Webzugriff auf die Backups des Client-Hosts über die Weboberfläche von BackupPC:

• backuppc_server_web_main_user: Hauptbenutzer mit Zugriff auf die Backups des Client-Hosts über die BackupPC-Weboberfläche. Standardmäßig backuppc.
• backuppc_server_web_other_users: Andere Benutzer mit Zugriff auf die Backups des Client-Hosts über die BackupPC-Weboberfläche. Muss als Zeichenfolge definiert werden, die Benutzer durch Kommas getrennt auflistet: "benutzer1,benutzer2". Der Benutzerzugriff muss auf dem BackupPC-Server konfiguriert werden.

Mysql-Skriptbeispiele

Für ein MySQL-Backup, um vor dem Dateidump alle Datenbanken zu dumpt, können Sie die folgenden Skripte verwenden, die den MySQL-BackupPC-Benutzer nutzen, der von der Rolle konfiguriert wurde:

• 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

Beispiel-Playbook

Wir gehen davon aus, dass wir eine Standard-BackupPC-Instanz auf bck-server.domain.org haben, die über das Ansible-Inventar verwaltet wird. Das folgende Playbook konfiguriert auf diesem Server das Backup der angegebenen Ordner des Hosts client.domain.org, mit dem erforderlichen SSH-Zugriff.

- name: Backup client.domain.org Host
  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

Lizenz

GPLv3

Autorinfo

Originalrolle Emilien M erweitert von Víctor Torterola und Daniel Viñar