Rôle de sauvegarde Borg

Ce rôle installe Borg backup sur les serveurs et clients borgbackup. Le rôle contient un script d'enveloppement 'borg-backup' pour faciliter l'utilisation sur le client. Les options prises en charge incluent borg-backup info | init | list | backup | mount. Automysqlbackup sera exécuté en tant que commande de pré-sauvegarde s'il est installé. Le rôle prend en charge à la fois le stockage de sauvegarde auto-hébergé et hors site, tel que rsync.net et Hetzner storage box en tant que serveur Borg.

Il est possible de configurer des dépôts en mode ajout seul pour sécuriser les sauvegardes contre la suppression depuis le client.

Ansible 2.9 ou supérieur est requis pour exécuter ce rôle.

Variables requises

Définissez un groupe borgbackup_servers dans votre inventaire avec un ou plusieurs hôtes. Le groupe borgbackup_management n'est nécessaire que si vous souhaitez activer le mode ajout seul et tailler les sauvegardes depuis des hôtes sécurisés.

[borgbackup_servers]
backup1.fiaas.co

[borgbackup_management]
supersecurehost

Définissez des variables de groupe ou d'hôte pour vos points de sauvegarde et la rétention :

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

Avertissement : le / final dans item.home est nécessaire.

Définissez une borg_passphrase pour chaque hôte. host_vars\client1:

borgbackup_passphrase: Ahl9EiNohr5koosh1Wohs3Shoo3ooZ6p

Par défaut, le rôle crée un cronjob dans /etc/cron.d/borg-backup qui s'exécute en tant que root tous les jours à une heure aléatoire entre 0h et 5h du matin à une minute aléatoire. Remplacez les valeurs par défaut si nécessaire :

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

Remplacez borgbackup_client_user si nécessaire, par exemple si vous avez un ordinateur portable avec un répertoire personnel chiffré, vous devrez exécuter la sauvegarde en tant qu'utilisateur de ce répertoire.

Définissez borgbackup_appendonly: True dans les variables d'hôte ou de groupe si vous souhaitez des dépôts en mode ajout seul. Dans ce cas, il est possible de définir un nom d'hôte dans borgbackup_management_station où un script borg prune sera configuré. Seule la station de gestion aura la permission de tailler les anciennes sauvegardes pour (tous) les clients. Cela générera un serveur avec des options de clé ssh --append-only. Si vous définissez borgbackup_appendonly_repoconfig sur True, cela désactivera également la possibilité de supprimer des sauvegardes depuis la station de gestion. (Ou du moins : il n'est pas possible de les supprimer tant que vous ne reconfigurez pas le référentiel et cela n'est pas actuellement pris en charge dans le script de taille) Soyez conscient des limitations du mode ajout seul : les sauvegardes taillées semblent avoir été supprimées, mais ne sont supprimées que dans le journal des transactions jusqu'à ce que quelque chose écrive normalement dans le référentiel)

Assurez-vous de vérifier les paramètres par défaut configurés pour ce rôle, qui contiennent la liste des emplacements par défaut sauvegardés dans backup_include. Remplacez cela dans votre inventaire si nécessaire.

Installation de Borg à partir d'un package

Borg peut être installé à partir d'un package en définissant la variable :

borgbackup_install_from_pkg: true

Sur les systèmes EPEL (RedHat/CentOS), le dépôt epel-release sera ajouté automatiquement en utilisant le rôle geerlingguy.repo-epel.

Utilisation

Configurez Borg sur le serveur et sur un client :

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

Tests

Toutes les fonctionnalités du rôle sont testées à l'aide de molecule avec une connexion Docker locale pour éviter la complexité. Pour plus d'informations sur les tests avec molecule, consultez https://molecule.readthedocs.io/en/latest/. Les tests sont écrits en utilisant Testinfra, voir https://testinfra.readthedocs.io/en/latest/.

En raison de la variété des scénarios, les tests eux-mêmes sont stockés dans molecule/generic_files pour optimiser la réutilisabilité. Ils peuvent être appliqués à des hôtes/groupes en utilisant des groupes.

Commencer à tester est aussi simple que de faire ce qui suit sur n'importe quelle machine avec un moteur Docker local : (depuis le répertoire racine de ce rôle)

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

Assurez-vous de tester toutes les fonctionnalités. Les constructions échouées ne seront pas acceptées lors de l'examen de PR ! Chaque scénario de test exécute au moins un déploiement complet avec un serveur de sauvegarde, effectue une sauvegarde, exécute un test de restauration et divers autres tests mineurs, garantissant la stabilité fonctionnelle.

Scénarios de test

default

molecule test

Ce scénario teste les fonctionnalités les plus courantes sur les plateformes Debian. Il exécute un serveur de sauvegarde sur les 2 dernières versions officielles de Debian.

centos

molecule test -s centos

Ce scénario teste les fonctionnalités les plus courantes sur les plateformes EPEL. Il exécute un serveur de sauvegarde sur les 2 dernières versions officielles de CentOS.

ubuntu

molecule test -s ubuntu

Ce scénario teste les fonctionnalités les plus courantes sur les plateformes Ubuntu. Il exécute un serveur de sauvegarde sur les 2 dernières versions officielles d'Ubuntu.

multiple

molecule test -s multiple

Ce scénario s'assure que la fonctionnalité du rôle fonctionne lorsque 2 serveurs de sauvegarde ou plus sont définis.

lamp

molecule test -s lamp

Tester la fonctionnalité lorsque le rôle fiaas.lamp est appliqué à une machine, garantissant la compatibilité avec un hôte 'Fiaas'. Voir molecule.yml pour plus de détails.

clients

molecule test -s clients

Ce test est le plus grand scénario car il contient des tests pour toutes les plateformes et combinaisons prises en charge. Exemple : Debian 8 + 9 + 10, Fedora 31, ... Comme nous exécutons tous différents systèmes et plateformes, cela peut être étendu en toute sécurité tant que ce scénario continue à fonctionner !

Lecture complémentaire

• Documentation de Borg
• Informations sur le mode ajout seul