Rôle de sauvegarde

Stratégies de sauvegarde et de restauration pour les projets Coopdevs.

Exigences

Ce rôle utilise Restic avec l'aide de restic-ansible.

Variables du rôle

# Version de Restic
backups_role_restic_version: '0.16.4'

# Emplacement des scripts
backups_role_path: '/opt/backup'
backups_role_script_dir: "{{ backups_role_path }}/bin"

# Nom modifiable du modèle pour générer
#+ le script "prepare", qui sera intégré dans
#+ le script rendu `backups_role_script_path`
backups_role_script_prepare_template: "cron-prepare.sh.j2"

# Si vous modifiez backups_role_script_prepare_template, cela signifie que vous n'utilisez pas
#+ le modèle de script par défaut et donc nous n'avons pas besoin de créer des rôles postgres, etc.
#+ et vous n'aurez peut-être pas besoin des permissions sudo pour tar. Par conséquent, nous désactivons
#+ les tâches correspondantes par défaut. Cependant, si vous souhaitez activer ces tâches,
#+ définissez à true les variables correspondantes :
backups_role_postgresql_enabled:
backups_role_sudoers_enabled:

# Chemin complet vers le script rendu formé par main, prepare et upload.
backups_role_script_path:    "{{ backups_role_script_dir }}/backup.sh"

# Emplacement des fichiers générés par les tâches cron
backups_role_tmp_path: '/tmp/backups'

# Listes des chemins à sauvegarder
backups_role_assets_paths: []

# Utilisateur système, son groupe principal et d'autres groupes.
#+ Qui exécutera les scripts, restic et les tâches cron
#+ et sera propriétaire des répertoires et fichiers
backups_role_user_name: 'backups'
backups_role_user_group: 'backups'
backups_role_user_groups: ''

# Rôle interne en lecture seule pour PostgreSQL pour effectuer la sauvegarde
backups_role_postgresql_user_name: "{{ backups_role_user_name }}"
# Rôle admin interne de Postgres
postgresql_user: "postgres"
backups_role_db_names: [ "postgres" ]

# Nom du dépôt restic utilisé uniquement dans le cas
#+ où nous devons adresser différents dépôts restic
backups_role_restic_repo_name: {{ escaped_inventory_hostname }}

#########################################
### AVERTISSEMENT ! Variables sensibles ci-dessous ###
#########################################
###  Envisagez de les placer à l'intérieur d'un  ###
###  coffre-fort ansible. En exemple voir ###
###  defaults/secrets.yml.example     ###
#########################################

# Mot de passe pour l'utilisateur de sauvegarde PostgreSQL sans privilèges
backups_role_postgresql_user_password:

# Mot de passe du dépôt Restic. Un nouveau mot de passe que vous fournissez pour chiffrer les sauvegardes.
backups_role_restic_repo_password:

# URL du seau distant au format restic
# Exemple pour backblaze :  "b2:nomduseau:chemin/vers/repo". Il se peut que
#   "b2:nomduseau:/" fonctionne pour vous.
# Exemple pour un dépôt local : "/var/backups/repo"
backups_role_restic_repo_url:

# Clé d'application Backblaze, restreinte au seau mentionné ci-dessus
# Plus d'infos dans le fichier secrets d'exemple et
# à https://gitlab.com/coopdevs/b2-bucket-and-key
backups_role_b2_app_key_id:
backups_role_b2_app_key:

Dépendances

• coopdevs.ansible_restic

Utilisation

Vous devez préparer un inventaire pour vos hôtes avec les variables ci-dessus. Par exemple, dans inventory/hosts.

Exemple de playbook PostgreSQL avec sauvegardes

# playbooks/main.yml
---
- name: Installer PostgreSQL avec sauvegardes automatiques
  hosts: servers
  become: yes
  roles:
    - role: geerlingguy.postgresql
    - role: coopdevs.backups_role

Playbook pour restaurer une sauvegarde sur le contrôleur

# playbooks/restore.yml
---
- name: Restaurer une sauvegarde localement
  hosts: servers
  connection: local
  tasks:
  - import_role:
      name: coopdevs.backups_role
      tasks_from: restore-to-controller.yml

Playbook pour restaurer une sauvegarde sur l'hôte

# playbooks/restore-in-situ.yml
---
- name: Restaurer une sauvegarde sur l'hôte
  hosts: servers
  tasks:
  - import_role:
      name: coopdevs.backups_role
      tasks_from: restore-to-host.yml

Restauration d'un instantané en utilisant le playbook ci-dessus

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

Ce playbook n'installera aucun binaire globalement, mais il nécessite néanmoins des droits root. Par conséquent, vous devrez peut-être fournir le mot de passe sudo :

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

Par défaut, il crée un répertoire avec restic et un wrapper utile et restaure le dernier instantané. Enfin, il supprime de manière sécurisée le wrapper, car il contient des informations confidentielles que nous ne voulons pas laisser traîner. Cependant, si vous préférez installer le wrapper et l'utiliser manuellement, vous pouvez exécuter le playbook avec le tag install :

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

Script de sauvegarde personnalisé

Lorsque votre application n'utilise pas PostgreSQL ou que le script de sauvegarde ne répond pas à vos besoins, vous pouvez fournir le vôtre en passant un nouveau modèle à backups_role_script_prepare_template. Vous pouvez utiliser les mêmes méthodes d'aide log et run spécifiées dans cron-main.sh.j2. Vous pouvez vous référer à toutes les variables que vous avez spécifiées dans la déclaration include_role.

Le téléchargement de la sauvegarde vers le stockage d’objets ne peut pas être personnalisé ; vous devez donc toujours spécifier les chemins où votre script dépose les fichiers de sauvegarde avec backups_role_assets_paths. Oui, cette variable devrait être nommée quelque chose comme backups_role_file_to_upload ou similaire :shrug:. Voir cron-upload.sh.j2 pour plus de détails.

Notez que bien que cela ne s'applique pas dans ce cas, cette variable est également utilisée dans cron-prepare.sh pour lister les fichiers à sauvegarder et cela peut être très déroutant. Elle a donc deux usages différents.

Voir https://github.com/coopdevs/donalo/pull/82 ou https://gitlab.com/coopdevs/odoo-provisioning/-/tree/master/roles/backups pour des exemples prêts à l'emploi.

Variables sensibles

Veuillez protéger au moins les variables ci-dessous les "variables sensibles" ci-dessus. Pour ce faire, utilisez Ansible Vault pour chiffrer avec un mot de passe le fichier de configuration contenant ces variables.

Backblaze

Backblaze fournit deux types de clés : compte ou maître, et application. Il n'y a qu'une seule clé de compte qui a pouvoir sur toutes les autres clés et tous les seaux. Nous pouvons avoir plusieurs clés d'application, qui peuvent avoir un accès en lecture/écriture à un seul seau ou à tous.

Nous ne devrions pas utiliser la clé de compte pour accéder à un seau ou réutiliser les clés d'application. Même si les mots de passe de restic sont différents et que les seaux sont différents, un serveur pourrait être capable de supprimer les sauvegardes des autres, ou même de créer davantage de seaux, de les remplir et de faire augmenter la facture.

Nous utilisons donc des clés d'application au lieu de la clé maître. Pour ansible-restic, il transmet simplement les informations d'identification à restic, quel que soit le type de clé. En fait, nous définissons b2_account_key de ansible-restic (qui suggère d'utiliser la clé maître) avec backups_role_b2_app_key de backup-role (qui suggère d'utiliser une clé d'application).

Ce que Restic appelle "clé de compte" apparaît sur le web B2 comme "clé d'application maître".

Si vous souhaitez créer un nouveau seau et une clé d'application restreinte, vous pouvez utiliser le script Backblaze bucket and key.

Restic

Restic créera un "dépôt" pendant le provisionnement Ansible. Cela ressemble à un répertoire à l'intérieur du seau BackBlaze, le chemin à l'intérieur du seau étant la dernière partie de backups_role_bucket_url, séparée par :. Si vous souhaitez le placer à la racine, essayez quelque chose comme b2:monseau:/. Plus d'infos dans les docs de restic. De l'extérieur, vous verrez :
config data index keys locks snapshots

Et si vous le déchiffrez, par exemple, lorsque vous le montez :
hosts ids snapshots tags

Cependant, vous souhaiterez probablement restaurer juste un instantané particulier du dépôt. Pour ce faire, utilisez restic restore. Vous devrez lui fournir l'identifiant de l'instantané que vous souhaitez restaurer et le répertoire cible pour le décharger. Vous pouvez explorer les instantanés en exécutant restic snapshots. Un cas particulier est de restaurer le dernier instantané, où vous pouvez utiliser latest comme identifiant d'instantané.

Pour restaurer juste un fichier de l'instantané dernier plutôt que tout le dépôt, vous pouvez utiliser la sous-commande dump : restic dump latest monfichier > /home/user/monfichier.

N'oubliez pas que toutes les commandes restic doivent savoir où communiquer et avec quelles informations d'identification. Vous pouvez les passer comme paramètres, ou les exporter comme variables d'environnement. Pour ce cas, nous avons besoin de :

export RESTIC_REPOSITORY="b2:nameseau:/"
export RESTIC_PASSWORD="phrase de plus de 7 mots"
export B2_ACCOUNT_ID="notre identifiant de clé d'application"
export B2_ACCOUNT_KEY="notre clé d'application qui est très longue et contient des chiffres et des lettres majuscules"

Licence

GPLv3