Backups Rolle

Backup- und Wiederherstellungsstrategien für Coopdevs-Projekte.

Anforderungen

Diese Rolle nutzt Restic mit Unterstützung von restic-ansible.

Rollenvariablen

# Restic-Version
backups_role_restic_version: '0.16.4'

# Speicherort der Skripte
backups_role_path: '/opt/backup'
backups_role_script_dir: "{{ backups_role_path }}/bin"

# Überschreibbarer Name der Vorlage zur Erstellung des "prepare" Skripts,
#+ das in das generierte Skript `backups_role_script_path` eingebettet wird
backups_role_script_prepare_template: "cron-prepare.sh.j2"

# Wenn Sie backups_role_script_prepare_template ändern, bedeutet dies, dass Sie nicht die
#+ Standardvorlage verwenden, und wir daher keine Postgres-Rollen usw. erstellen müssen.
#+ Möglicherweise benötigen Sie auch keine Root-Berechtigungen für tar. Daher deaktivieren wir
#+ die entsprechenden Aufgaben standardmäßig. Wenn Sie diese Aufgaben aktivieren möchten,
#+ setzen Sie die entsprechenden Variablen auf true:
backups_role_postgresql_enabled:
backups_role_sudoers_enabled:

# Vollständiger Pfad zum gerenderten Skript, das aus Haupt-, Vorbereitungs- und Upload-Skripten erstellt wird.
backups_role_script_path:    "{{ backups_role_script_dir }}/backup.sh"

# Speicherort der von Cron-Jobs generierten Dateien
backups_role_tmp_path: '/tmp/backups'

# Listen von Pfaden zu sichernden Dateien
backups_role_assets_paths: []

# Systembenutzer, seine Hauptgruppe und zusätzliche Gruppen.
#+ Wer Skripte, Restic und Cron-Jobs ausführt
#+ und die Verzeichnisse und Dateien besitzt
backups_role_user_name: 'backups'
backups_role_user_group: 'backups'
backups_role_user_groups: ''

# Interner Postgresql-Lesezugriffsbenutzer zur Durchführung des Dumps
backups_role_postgresql_user_name: "{{ backups_role_user_name }}"
# Interner Administrationsbenutzer von Postgres
postgresql_user: "postgres"
backups_role_db_names: [ "postgres" ]

# Name des Restic-Repositorys, der nur verwendet wird,
#+ wenn wir verschiedene Restic-Repos ansprechen müssen
backups_role_restic_repo_name: {{ escaped_inventory_hostname }}

#########################################
### WARNUNG! Sensible Variablen unten ###
#########################################
###  Erwägen Sie, sie in ein  ###
###  ansible-vault zu legen.     ###
###  Als Beispiel siehe         ###
###  defaults/secrets.yml.example   ###
#########################################

# Passwort für den unprivilegierten Backup-Benutzer von Postgresql
backups_role_postgresql_user_password:

# Passwort für das Restic-Repository. Ein neues Passwort, das Sie zur Verschlüsselung der Backups angeben.
backups_role_restic_repo_password:

# Remote-Bucket-URL im Restic-Format
# Beispiel für Backblaze:  "b2:bucketname:path/to/repo". Es besteht die Möglichkeit, dass
#   "b2:bucketname:/" für Sie funktioniert.
# Beispiel für lokales Repository: "/var/backups/repo"
backups_role_restic_repo_url:

# Backblaze "Anwendungs"-Schlüssel, der auf den oben erwähnten Bucket beschränkt ist
# Mehr dazu im Beispiel-Geheimnis-Datei und
# unter https://gitlab.com/coopdevs/b2-bucket-and-key
backups_role_b2_app_key_id:
backups_role_b2_app_key:

Abhängigkeiten

• coopdevs.ansible_restic

Verwendung

Sie müssen ein Inventar für Ihre Hosts mit den oben genannten Variablen vorbereiten. Zum Beispiel in inventory/hosts.

Beispiel-Postgresql-Playbook mit Backups

# playbooks/main.yml
---
- name: Installiere Postgresql mit automatischen Backups
  hosts: servers
  become: yes
  roles:
    - role: geerlingguy.postgresql
    - role: coopdevs.backups_role

Playbook zur Wiederherstellung eines Backups auf dem Controller

# playbooks/restore.yml
---
- name: Backup lokal wiederherstellen
  hosts: servers
  connection: local
  tasks:
  - import_role:
      name: coopdevs.backups_role
      tasks_from: restore-to-controller.yml

Playbook zur Wiederherstellung eines Backups auf dem Host

# playbooks/restore-in-situ.yml
---
- name: Backup auf dem Host wiederherstellen
  hosts: servers
  tasks:
  - import_role:
      name: coopdevs.backups_role
      tasks_from: restore-to-host.yml

Snapshot mit dem oben genannten Playbook wiederherstellen

ansible-playbook playbooks/restore.yml -i inventory/hosts -l servers

Dieses Playbook installiert keine Binärdatei global, benötigt jedoch dennoch Root-Rechte. Daher müssen Sie möglicherweise das Passwort für sudo angeben:

ansible-playbook playbooks/restore.yml -i inventory/hosts -l servers --ask-become-pass

Standardmäßig wird ein Verzeichnis mit Restic und einem praktischen Wrapper erzeugt und der neueste Snapshot wird wiederhergestellt. Schließlich wird der Wrapper sicher entfernt, da er Anmeldedaten enthält, die nicht herumliegen sollen. Wenn Sie jedoch lieber den Wrapper installieren und manuell verwenden möchten, können Sie das Playbook mit dem Tag install ausführen:

ansible-playbook playbooks/restore.yml -i inventory/hosts -l servers --tags install

Benutzerdefiniertes Backup-Skript

Wenn Ihre App kein PostgreSQL verwendet oder das Backup-Skript nicht Ihren Bedürfnissen entspricht, können Sie Ihr eigenes Skript bereitstellen, indem Sie eine neue Vorlage an backups_role_script_prepare_template übergeben. Sie können die gleichen Hilfsmethoden log und run verwenden, die in cron-main.sh.j2 beschrieben sind. Sie können auf alle Variablen verweisen, die Sie in der include_role-Deklaration angegeben haben.

Der Upload des Backups in den Objektspeicher kann nicht angepasst werden, und Sie müssen daher die Pfade angeben, wo Ihr Skript die Backup-Dateien hinterlässt, mit backups_role_assets_paths. Ja, diese Variable sollte etwas wie backups_role_file_to_upload oder ähnliches heißen. Siehe cron-upload.sh.j2 für weitere Details.

Beachten Sie, dass, obwohl dies in diesem Fall nicht zutrifft, diese Variable auch in cron-prepare.sh verwendet wird, um die zu sichernden Dateien aufzulisten, was sehr verwirrend sein kann. Sie hat zwei verschiedene Verwendungen.

Siehe https://github.com/coopdevs/donalo/pull/82 oder https://gitlab.com/coopdevs/odoo-provisioning/-/tree/master/roles/backups für produktionsfertige Beispiele.

Sensible Variablen

Bitte schützen Sie mindestens die untenstehenden Variablen, die "sensible Variablen" sind. Dazu verwenden Sie Ansible Vault, um die Konfigurationsdatei mit einem Passwort zu verschlüsseln.

Backblaze

Backblaze bietet zwei Arten von Schlüsseln: Konto- oder Hauptschlüssel und Anwendungs-Schlüssel. Es gibt nur einen Kontoschlüssel, der Vollzugriff auf alle anderen Schlüssel und alle Buckets hat. Wir können viele Anwendungs-Schlüssel haben, die rw-Zugriff auf alle oder genau einen Bucket haben.

Wir sollten den Kontoschlüssel nicht verwenden, um auf einen Bucket zuzugreifen oder Anwendungsschlüssel wiederzuverwenden. Selbst wenn Restic-Passwörter und Buckets unterschiedlich sind, könnte ein Server in der Lage sein, Backups von anderen zu löschen oder sogar weitere Buckets zu erstellen, sie zu füllen und die Rechnung zu belasten.

Daher verwenden wir Anwendungs-Schlüssel anstelle des Hauptschlüssels. Gemäß ansible-restic gibt es einfach die Anmeldedaten an Restic weiter, unabhängig vom Typ des Schlüssels. Tatsächlich setzen wir den b2_account_key von ansible-restic (schlägt vor, den Hauptschlüssel zu verwenden) mit backups_role's backups_role_b2_app_key (schlägt vor, einen Anwendungsschlüssel zu verwenden).

Was Restic als "Kontoschlüssel" bezeichnet, wird im B2-Web als "Hauptanwendungsschlüssel" angezeigt.

Wenn Sie einen neuen Bucket und einen eingeschränkten Anwendungsschlüssel erstellen möchten, können Sie das Backblaze-Bucket-und-Key-Skript verwenden.

Restic

Restic erstellt während der Ansible-Bereitstellung ein "Repository". Dies sieht aus wie ein Verzeichnis innerhalb des BackBlaze-Buckets, wobei der Pfad innerhalb des Buckets der letzte Teil von backups_role_bucket_url ist, aufgeteilt nach :. Wenn Sie es im Stammverzeichnis ablegen möchten, versuchen Sie etwas wie b2:mybucket:/. Mehr dazu finden Sie in den Restic-Dokumenten. Von außen sehen Sie:
config data index keys locks snapshots

Und wenn Sie es entschlüsseln, zum Beispiel beim Einbinden:
hosts ids snapshots tags

Sie möchten jedoch wahrscheinlich nur einen bestimmten Snapshot aus dem Repo wiederherstellen. Verwenden Sie dazu restic restore. Sie müssen ihm die ID des Snapshots geben, den Sie wiederherstellen möchten, und das Zielverzeichnis, in das er geladen werden soll. Sie können Snapshots mit restic snapshots erkunden. Ein besonderer Fall ist die Wiederherstellung des letzten Snapshots, wo Sie latest als Snapshot-ID verwenden können.

Um nur eine Datei aus dem letzten Snapshot anstelle des gesamten Repos wiederherzustellen, können Sie den Befehl zur Sicherung verwenden: restic dump latest myfile > /home/user/myfile.

Denken Sie daran, dass alle Restic-Befehle wissen müssen, wohin sie kommunizieren und mit welchen Anmeldedaten. Sie können sie entweder als Parameter übergeben oder als Umgebungsvariablen exportieren. In diesem Fall benötigen wir:

export RESTIC_REPOSITORY="b2:mybucketname:/"
export RESTIC_PASSWORD="langer Satz mit mindestens 7 Wörtern"
export B2_ACCOUNT_ID="unsere Anwendungsschlüssel-ID"
export B2_ACCOUNT_KEY="unser Anwendungsschlüssel, der sehr lang ist und Zahlen und Großbuchstaben enthält"

Lizenz

GPLv3