Borg Backup Rolle

Diese Rolle installiert Borg Backup auf borgbackup_servern und -clients. Die Rolle enthält ein Wrapper-Skript „borg-backup“, um die Nutzung auf dem Client zu erleichtern. Unterstützte Optionen sind borg-backup info | init | list | backup | mount. Automysqlbackup wird als Pre-Backup-Befehl ausgeführt, wenn es installiert ist. Die Rolle unterstützt sowohl selbst gehosteten als auch externen Backup-Speicher, wie z.B. rsync.net und Hetzner Storage Box als Borg Server.

Es ist möglich, nur-anfügen Repositories zu konfigurieren, um die Backups vor der Löschung durch den Client zu schützen.

Ansible 2.9 oder höher wird benötigt, um diese Rolle auszuführen.

Erforderliche Variablen

Definieren Sie eine Gruppe borgbackup_servers in Ihrem Inventar mit einem oder mehreren Hosts. Die Gruppe borgbackup_management ist nur erforderlich, wenn Sie den Nur-Anfügen-Modus aktivieren und die Backups von einem gesicherten Host aus verwalten möchten.

[borgbackup_servers]
backup1.fiaas.co

[borgbackup_management]
supersecurehost

Definieren Sie Gruppen- oder Hostvariablen für Ihre Backup-Endpunkte und Retention:

borgbackup_servers:
  - id: fiaas
    fqdn: backup1.fiaas.co
    user: borgbackup
    type: normal
    home: /backup/
    pool: repos
    options: ""
  - id: rsync
    fqdn: yourhost.rsync.net
    user: userid
    type: rsync.net
    home: ""
    pool: repos
    options: "--remote-path=borg1"
  - id: hetzner
    fqdn: username.your-storagebox.de
    user: username
    type: hetzner
    home: ""
    pool: repos
    options: ""

borgbackup_retention:
  hourly: 12
  daily: 7
  weekly: 4
  monthly: 6
  yearly: 1

WARNUNG: Der abschließende / in item.home ist erforderlich.

Definieren Sie ein borg_passphrase für jeden Host. host_vars\client1:

borgbackup_passphrase: Ahl9EiNohr5koosh1Wohs3Shoo3ooZ6p

Standardmäßig erstellt die Rolle einen Cronjob in /etc/cron.d/borg-backup, der jeden Tag zu einer zufälligen Stunde zwischen 0 und 5 Uhr morgens und zu einer zufälligen Minute als root ausgeführt wird. Überschreiben Sie die Standardwerte bei Bedarf:

borgbackup_client_user: root
borgbackup_cron_day: "*"
borgbackup_cron_minute: "{{ 59|random }}"
borgbackup_cron_hour: "{{ 5|random }}"

Überschreiben Sie borgbackup_client_user, wo erforderlich, zum Beispiel wenn Sie einen Laptop mit einem verschlüsselten Home-Verzeichnis haben, müssen Sie das Backup als Benutzer dieses Home-Verzeichnisses ausführen.

Setzen Sie borgbackup_appendonly: True in Host- oder Gruppenvariablen, wenn Sie Nur-Anfügen-Repositories möchten. In diesem Fall ist es möglich, einen Hostnamen in borgbackup_management_station zu definieren, wo ein Borg-Prune-Skript konfiguriert wird. Nur die Management-Station hat die Berechtigung, alte Backups für (alle) Clients zu löschen. Dies wird einen Dienst mit --append-only SSH-Schlüsseloptionen erzeugen. Wenn Sie borgbackup_appendonly_repoconfig auf True setzen, wird auch die Möglichkeit deaktiviert, Backups von der Management-Station zu entfernen. (Oder zumindest: es ist nicht möglich, sie zu entfernen, bis Sie das Repository neu konfigurieren, und dies wird derzeit nicht im Prune-Skript unterstützt.) Seien Sie sich der Einschränkungen des Nur-Anfügen-Modus bewusst: gelöschte Backups scheinen entfernt zu sein, sind jedoch nur im Transaktionsprotokoll entfernt, bis etwas im Normalmodus in das Repository schreibt.

Stellen Sie sicher, dass Sie die konfigurierten Standardwerte für diese Rolle überprüfen, die die Liste der standardmäßig gesicherten Speicherorte in backup_include enthalten. Überschreiben Sie dies in Ihrem Inventar, wo erforderlich.

Installation von Borg aus einem Paket

Borg kann aus einem Paket installiert werden, indem die Variable gesetzt wird:

borgbackup_install_from_pkg: true

Auf EPEL-Systemen (RedHat/CentOS) wird das epel-release-Repository automatisch mit der geerlingguy.repo-epel Rolle hinzugefügt.

Verwendung

Konfigurieren Sie Borg auf dem Server und auf einem Client:

ansible-playbook -i inventory/test backup.yml -l backup1.fiaas.co
ansible-playbook -i inventory/test backup.yml -l client1.fiaas.co

Testen

Alle Funktionen der Rolle werden mit Molecule getestet, indem eine lokale Docker-Verbindung verwendet wird, um Komplexität zu vermeiden. Für weitere Informationen zum Testen mit Molecule siehe https://molecule.readthedocs.io/en/latest/. Die Tests sind mit Testinfra geschrieben, siehe https://testinfra.readthedocs.io/en/latest/.

Wegen der Vielzahl an Szenarien werden die Tests selbst in molecule/generic_files gespeichert, um die Wiederverwendbarkeit zu optimieren. Sie können auf Hosts/Gruppen mit Gruppen angewendet werden.

Der Einstieg in das Testen ist so einfach, dass Sie Folgendes auf einem beliebigen Rechner mit einem lokalen Docker-Engine ausführen können: (aus dem Stammverzeichnis dieser Rolle)

$ virtualenv -p python3 ~/.venv/fiaasco-borgbackup-docu
$ source ~/.venv/fiaasco-borgbackup-docu/bin/activate
$ pip3 install -r requirements.txt
$ molecule test

Stellen Sie sicher, dass Sie alle Funktionen testen. Fehlgeschlagene Builds werden bei PR-Überprüfungen nicht akzeptiert! Jedes Test-Szenario führt mindestens ein vollständiges Deployment mit einem Backup-Server durch, führt ein Backup aus, führt einen Wiederherstellungstest durch und verschiedene andere kleinere Tests, um die funktionale Stabilität zu gewährleisten.

Test-Szenarien

standard

molecule test

Dieses Szenario testet die häufigsten Funktionen auf Debian-Plattformen. Es wird ein Backup-Server auf den 2 neuesten offiziellen Debian-Versionen ausgeführt.

centos

molecule test -s centos

Dieses Szenario testet die häufigsten Funktionen auf EPEL-Plattformen. Es wird ein Backup-Server auf den 2 neuesten offiziellen CentOS-Versionen ausgeführt.

ubuntu

molecule test -s ubuntu

Dieses Szenario testet die häufigsten Funktionen auf Ubuntu-Plattformen. Es wird ein Backup-Server auf den 2 neuesten offiziellen Ubuntu-Versionen ausgeführt.

multiple

molecule test -s multiple

Dieses Szenario stellt sicher, dass die Funktionsfähigkeit der Rolle funktioniert, wenn 2 oder mehr Backup-Server definiert sind.

lamp

molecule test -s lamp

Testfunktionalität, wenn die Rolle fiaas.lamp auf eine Maschine angewendet wird, um die Kompatibilität mit einem 'Fiaas'-Host zu gewährleisten. Siehe molecule.yml für Details.

clients

molecule test -s clients

Dieser Test ist das größte Szenario, da es Tests für alle unterstützten Plattformen und Kombinationen enthält. Z.B. Debian 8 + 9 + 10, Fedora 31, ... Da wir alle unterschiedliche Systeme und Plattformen verwenden, kann dieses Szenario sicher erweitert werden, solange es weiterhin funktioniert!

Weiterführende Literatur

• Borg-Dokumentation
• Informationen zum Nur-Anfügen-Modus