Théorie et pratique des sauvegardes avec Borg

À notre grande surprise, il n'y avait pas un seul élément sur le merveilleux outil Open Source pour la sauvegarde de données - Borg (à ne pas confondre avec le progéniteur éponyme Kubernetes!) . Depuis que nous l'utilisons en production depuis plus d'un an, je partagerai dans cet article les «impressions» que nous avons acquises sur Borg.

Contexte: Expérience avec Bacula et Bareos

En 2017, nous en avions assez de Bacula et Bareos, que nous utilisions depuis le tout début de notre activité (soit environ 9 ans de production à l'époque). Pourquoi? Pendant le fonctionnement, nous avons accumulé beaucoup de mécontentement:

• SD (Storage Daemon) se bloque. Si vous avez configuré le parallélisme, la maintenance SD devient plus compliquée et son gel bloquera les sauvegardes supplémentaires dans les délais et la possibilité de récupération.
• Il est nécessaire de générer des configurations pour le client et le directeur. Même si nous automatisons cela (dans notre cas, Chef, Ansible et notre propre développement ont été utilisés à des moments différents), nous devons surveiller que le réalisateur, après son rechargement, a effectivement récupéré la configuration. Ceci est seulement suivi dans la sortie de la commande de rechargement et dans l'appel de messages après (pour obtenir le texte d'erreur lui-même).
• Planifiez des sauvegardes. Les développeurs de Bacula ont décidé de suivre leur propre chemin et ont écrit leur propre format de calendrier, que vous ne pouvez pas simplement analyser ou convertir en un autre. Voici des exemples de planifications de sauvegarde standard dans nos anciennes installations:
  • Sauvegarde complète quotidienne le mercredi et incrémentielle les autres jours:
    Run = Level=Full Pool="Foobar-low7" wed at 18:00
Run = Level=Incremental Pool="Foobar-low7" at 18:00
  • Sauvegarde complète des fichiers wal 2 fois par mois et incrémentation toutes les heures:
    Run = Level=Full FullPool=CustomerWALPool 1st fri at 01:45
Run = Level=Full FullPool=CustomerWALPool 3rd fri at 01:45
Run = Level=Incremental FullPool=CustomerWALPool IncrementalPool=CustomerWALPool on hourly
  • Le schedule généré pour toutes les occasions (à différents jours de la semaine toutes les 2 heures), nous avons obtenu environ 1665 ... à cause de ce que Bacula / Bareos devenait périodiquement fou.
• Bacula-fd (et bareos-fd) ont des répertoires avec beaucoup de données (disons 40 To, dont 35 To contiennent des fichiers volumineux [100+ Mo] et les 5 To restants contiennent de petits fichiers [1 Ko à 100 Mo ]) une lente fuite de mémoire commence, ce qui est une situation très désagréable en production.
  
  
• Sur les sauvegardes avec un grand nombre de fichiers, Bacula et Bareos sont très dépendants des performances du SGBD utilisé. De quels disques dispose-t-il? Dans quelle mesure savez-vous comment l'adapter à ces besoins spécifiques? Et dans la base de données, au fait, une (!) Table non partitionnable est créée avec une liste de tous les fichiers dans toutes les sauvegardes et la seconde - avec une liste de tous les chemins dans toutes les sauvegardes. Si vous n'êtes pas prêt à allouer au moins 8 Go de RAM pour la base + 40 Go de SSD pour votre serveur de sauvegarde - préparez-vous immédiatement pour les freins.
• La dépendance à la base de données mérite un point de plus. Bacula / Bareos pour chaque fichier demande au réalisateur s'il existait déjà un tel fichier. Le directeur, bien sûr, rampe dans la base de données, dans ces tables très énormes ... Il s'avère que la sauvegarde peut être bloquée simplement par le fait que plusieurs sauvegardes lourdes ont démarré en même temps - même si le diff y est de plusieurs mégaoctets.

Il serait injuste de dire qu’aucun problème n’a été résolu, mais nous en sommes arrivés au point où nous étions vraiment fatigués de diverses solutions de contournement et voulions une solution fiable «ici et maintenant».

Bacula / Bareos fonctionnent très bien avec un petit nombre (10-30) d'emplois uniformes. Une petite chose s'est-elle cassée une fois par semaine? Ce n'est pas grave: ils ont confié la tâche à l'officier de service (ou à un autre ingénieur) - ils l'ont réparée. Cependant, nous avons des projets dans lesquels le nombre d'emplois est de plusieurs centaines et le nombre de fichiers qu'ils contiennent est de centaines de milliers. En conséquence, 5 minutes par semaine pour corriger la sauvegarde (sans compter plusieurs heures de paramètres avant cela) ont commencé à se multiplier. Tout cela a conduit au fait que 2 heures par jour, il était nécessaire de réparer les sauvegardes dans tous les projets, car littéralement partout quelque chose était insignifiant ou sérieusement cassé.

Ensuite, quelqu'un pourrait penser qu'un ingénieur dédié dédié à cela devrait faire des sauvegardes. Certes, il sera aussi barbu et sévère que possible, et de son regard, les sauvegardes sont réparées instantanément, pendant qu'il sirote calmement du café. Et cette idée peut être vraie en quelque sorte ... Mais il y a toujours un mais. Tout le monde ne peut pas se permettre de réparer et de surveiller les sauvegardes 24 heures sur 24, et plus encore - un ingénieur affecté à ces fins. Nous sommes juste sûrs qu'il vaut mieux passer ces 2 heures par jour sur quelque chose de plus productif et utile. Par conséquent, nous sommes passés à la recherche de solutions alternatives qui «fonctionnent tout simplement».

Borg comme une nouvelle façon

La recherche d'autres options Open Source s'est étalée dans le temps, il est donc difficile d'estimer le coût total, mais à un moment donné (l'année dernière), notre attention s'est tournée vers le « héros de l' occasion» - BorgBackup (ou simplement Borg). Cela a été en partie facilité par l'expérience réelle de son utilisation par l'un de nos ingénieurs (sur le lieu de travail précédent).

Borg est écrit en Python (la version> = 3.4.0 est requise) et le code exigeant en termes de performances (compression, chiffrement, etc.) est implémenté en C / Cython. Distribué sous une licence BSD gratuite (3 clauses). Il prend en charge de nombreuses plates-formes, y compris Linux, * BSD, macOS, ainsi qu'au niveau expérimental Cygwin et sous-système Linux de Windows 10. Pour installer BorgBackup, des packages sont disponibles pour les distributions Linux populaires et d'autres systèmes d'exploitation, ainsi que des codes source, qui peuvent également être installés via pip, - des informations plus détaillées à ce sujet peuvent être trouvées dans la documentation du projet .

Pourquoi Borg nous a-t-il tant corrompu? Voici ses principaux avantages:

• Déduplication : réelle et très efficace (exemples ci-dessous). Les fichiers d'un même référentiel Borg (c'est-à-dire un répertoire spécial dans un format spécifique à Borg) sont divisés en blocs de n mégaoctets et les blocs Borg répétés sont dédupliqués. La déduplication se produit précisément avant la compression.
• Compression : après déduplication, les données sont également compressées. Différents algorithmes de compression sont disponibles: lz4, lzma, zlib, zstd. La fonctionnalité standard de toute sauvegarde, mais ce n'est pas moins utile.
• Travail sur SSH : sauvegardes Borg sur un serveur distant via SSH. Côté serveur, il suffit d'installer Borg et c'est tout! À partir d'ici, des avantages tels que la sécurité et le chiffrement suivent immédiatement. Vous ne pouvez configurer l'accès que par des clés et, de plus, l'exécution par Borg d'une seule de ses commandes lors de son entrée sur le serveur. Par exemple, comme ceci:
  
  

   $ cat .ssh/authorized_keys command="/usr/bin/borg serve" ssh-rsa AAAAB3NzaC1yc… 

• Il est livré à la fois en PPA (nous utilisons principalement Ubuntu) et en binaire statique . Borg sous la forme d'un binaire statique permet de l'exécuter presque partout où il y a au moins une glibc minimalement moderne. (Mais pas partout - par exemple, il n'a pas été possible de démarrer sur CentOS 5.)
• Nettoyage flexible des anciennes sauvegardes . Vous pouvez définir le stockage des n dernières sauvegardes et 2 sauvegardes par heure / jour / semaine. Dans ce dernier cas, la dernière sauvegarde en fin de semaine sera laissée. Les conditions peuvent être combinées en stockant 7 sauvegardes quotidiennes pour les 7 derniers jours et 4 sauvegardes hebdomadaires.

La transition vers Borg a commencé lentement sur de petits projets. Au début, il s'agissait de simples scripts cron qui faisaient leur travail tous les jours. Cela a duré environ six mois. Pendant ce temps, nous avons dû obtenir des sauvegardes plusieurs fois ... et il s'est avéré que Borg n'avait pas du tout besoin d'être réparé littéralement! Pourquoi? Parce que le principe simple fonctionne ici: "Plus le mécanisme est simple, moins il y aura de cassures."

Pratique: comment sauvegarder avec Borg?

Prenons un exemple simple de création d'une sauvegarde:

1. Téléchargez la dernière version binaire sur le serveur de sauvegarde et la machine que nous allons sauvegarder à partir du référentiel officiel :
   
   

    sudo wget https://github.com/borgbackup/borg/releases/download/1.1.6/borg-linux64 -O /usr/local/bin/borg sudo chmod +x /usr/local/bin/borg 

   
   Remarque : Si vous utilisez une machine locale pour le test à la fois en tant que source et en tant que récepteur, alors toute la différence ne sera que dans l'URI, que nous transmettrons, mais nous nous souvenons que la sauvegarde doit être stockée séparément, et non sur la même machine.
2. Sur le serveur de sauvegarde, créez l'utilisateur borg :
   
   

    sudo useradd -m borg 

   
   Simple: sans groupes et avec un shell standard, mais toujours avec un répertoire personnel.
3. Une clé SSH est générée sur le client:
   
   

    ssh-keygen 

4. Sur le serveur, ajoutez la clé générée à l'utilisateur borg :
   
   

    mkdir ~borg/.ssh echo 'command="/usr/local/bin/borg serve" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDNdaDfqUUf/XmSVWfF7PfjGlbKW00MJ63zal/E/mxm+vJIJRBw7GZofe1PeTpKcEUTiBBEsW9XUmTctnWE6p21gU/JNU0jITLx+vg4IlVP62cac71tkx1VJFMYQN6EulT0alYxagNwEs7s5cBlykeKk/QmteOOclzx684t9d6BhMvFE9w9r+c76aVBIdbEyrkloiYd+vzt79nRkFE4CoxkpvptMgrAgbx563fRmNSPH8H5dEad44/Xb5uARiYhdlIl45QuNSpAdcOadp46ftDeQCGLc4CgjMxessam+9ujYcUCjhFDNOoEa4YxVhXF9Tcv8Ttxolece6y+IQM7fbDR' > ~borg/.ssh/authorized_keys chown -R borg:borg ~borg/.ssh bin local / / borg servir" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDNdaDfqUUf / XmSVWfF7PfjGlbKW00MJ63zal / E / MXM + vJIJRBw7GZofe1PeTpKcEUTiBBEsW9XUmTctnWE6p21gU / JNU0jITLx + vg4IlVP62cac71tkx1VJFMYQN6EulT0alYxagNwEs7s5cBlykeKk / QmteOOclzx684t9d6BhMvFE9w9r + c76aVBIdbEyrkloiYd + vzt79nRkFE4CoxkpvptMgrAgbx563fRmNSPH8H5dEad44 / Xb5uARiYhdlIl45QuNSpAdcOadp46ftDeQCGLc4CgjMxessam + 9ujYcUCjhFDNOoEa4YxVhXF9Tcv8Ttxolece6y + IQM7fbDR'> ~ borg / .ssh mkdir ~borg/.ssh echo 'command="/usr/local/bin/borg serve" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDNdaDfqUUf/XmSVWfF7PfjGlbKW00MJ63zal/E/mxm+vJIJRBw7GZofe1PeTpKcEUTiBBEsW9XUmTctnWE6p21gU/JNU0jITLx+vg4IlVP62cac71tkx1VJFMYQN6EulT0alYxagNwEs7s5cBlykeKk/QmteOOclzx684t9d6BhMvFE9w9r+c76aVBIdbEyrkloiYd+vzt79nRkFE4CoxkpvptMgrAgbx563fRmNSPH8H5dEad44/Xb5uARiYhdlIl45QuNSpAdcOadp46ftDeQCGLc4CgjMxessam+9ujYcUCjhFDNOoEa4YxVhXF9Tcv8Ttxolece6y+IQM7fbDR' > ~borg/.ssh/authorized_keys chown -R borg:borg ~borg/.ssh 

5. Nous initialisons le dépôt borg sur le serveur à partir du client:
   
   

    ssh borg@172.17.0.3 hostname #     borg init -e none borg@172.17.0.3:MyBorgRepo 

   
   Le commutateur -e est utilisé pour sélectionner la méthode de chiffrement pour le référentiel (oui, vous pouvez également chiffrer chaque référentiel avec votre mot de passe!). Dans ce cas, car ceci est un exemple, nous n'utilisons pas de cryptage. MyBorgRepo est le nom du répertoire dans lequel le dépôt de borg sera (vous n'avez pas besoin de le créer à l'avance - Borg fera tout lui-même).
6. Lancez la première sauvegarde à l'aide de Borg:
   
   

    borg create --stats --list borg@172.17.0.3:MyBorgRepo::"MyFirstBackup-{now:%Y-%m-%d_%H:%M:%S}" /etc /root 

   
   À propos des clés:
   
   • --stats et --list nous donnent des statistiques sur la sauvegarde et les fichiers qui y sont entrés;
   • borg@172.17.0.3:MyBorgRepo - tout est clair ici, c'est notre serveur et notre répertoire. Et quelle est la prochaine étape pour la magie? ..
   • ::"MyFirstBackup-{now:%Y-%m-%d_%H:%M:%S}" est le nom de l'archive à l'intérieur du référentiel. C'est arbitraire, mais nous adhérons au format _-timestamp (horodatage au format Python).

Et ensuite? Bien sûr, voyez ce qui est entré dans notre sauvegarde! Liste des archives à l'intérieur du référentiel:

 borg@b3e51b9ed2c2:~$ borg list MyBorgRepo/ Warning: Attempting to access a previously unknown unencrypted repository! Do you want to continue? [yN] y MyFirstBackup-2018-08-04_16:55:53 Sat, 2018-08-04 16:55:54 [89f7b5bccfb1ed2d72c8b84b1baf477a8220955c72e7fcf0ecc6cd5a9943d78d] 

Nous voyons une sauvegarde avec un horodatage et comment Borg nous demande si nous voulons vraiment accéder à un référentiel non crypté auquel nous n'avons jamais été auparavant.

Nous regardons la liste des fichiers:

 borg list MyBorgRepo::MyFirstBackup-2018-08-04_16:55:53 

Nous obtenons le fichier de la sauvegarde (vous pouvez aussi tout le répertoire):

 borg@b3e51b9ed2c2:~$ borg extract MyBorgRepo::MyFirstBackup-2018-08-04_16:55:53 etc/hostname borg@b3e51b9ed2c2:~$ ll etc/hostname -rw-r--r-- 1 borg borg 13 Aug 4 16:27 etc/hostname 

Félicitations, votre première sauvegarde Borg est prête!

Pratique: automatisez ceci [avec GitLab]!

Après avoir enveloppé tout cela dans des scripts, nous avons configuré manuellement les sauvegardes de manière similaire sur environ 40 hôtes. Réalisant que Borg fonctionne vraiment, ils ont commencé à y transférer de plus en plus de projets ...

Et ici, nous sommes confrontés à ce qui se trouve à Bareos, mais pas à Borg! À savoir: WebUI ou une sorte de lieu centralisé pour configurer les sauvegardes. Et nous espérons vraiment qu'il s'agit d'un phénomène temporaire, mais jusqu'à présent, nous avons dû résoudre quelque chose. Googler les outils finis et se réunir dans une vidéoconférence, nous nous sommes mis au travail. C'était une excellente idée d'intégrer Borg à nos services internes, comme nous l'avons fait auparavant avec Bacula (Bacula lui-même a retiré la liste des tâches de notre API centralisée, à laquelle nous avions notre propre interface intégrée avec d'autres paramètres de projet). Nous avons réfléchi à la façon de le faire, décrit un plan de comment et où le construire, mais ... Des sauvegardes normales sont nécessaires maintenant, mais il n'y a aucun endroit pour prendre des plans de temps grandioses. Que faire

Les questions et les exigences étaient approximativement les suivantes:

• Que faut-il utiliser comme gestion de sauvegarde centralisée?
• Que peut faire n'importe quel administrateur Linux?
• Que peut même un gestionnaire qui montre un calendrier de sauvegarde aux clients peut comprendre et configurer?
• Que fait quotidiennement une tâche planifiée sur votre système?
• Qu'est-ce qui ne sera pas difficile à configurer et ne cassera pas? ..

La réponse était évidente: c'est le bon vieux crond, qui accomplit héroïquement son devoir tous les jours. C'est simple. Il ne gèle pas. Même le gestionnaire qui est d'Unix à «vous» peut y remédier.

Alors crontab, mais où gardez-vous tout cela? Est-ce à chaque fois d'aller sur la machine du projet et d'éditer le fichier avec vos mains? Bien sûr que non. Nous pouvons mettre notre planning dans le référentiel Git et configurer GitLab Runner, qui par commit le mettra à jour sur l'hôte.

Remarque : C'est GitLab qui a été choisi comme outil d'automatisation, car il est pratique pour la tâche et dans notre cas, il est presque partout. Mais je dois dire qu'il n'est nullement une nécessité.

Vous pouvez étendre crontab pour les sauvegardes à l'aide d'un outil d'automatisation familier ou généralement manuellement (sur de petits projets ou des installations domestiques).

Voici donc ce dont vous avez besoin pour une automatisation simple:

1. GitLab et un référentiel , dans lequel pour commencer il y aura deux fichiers:

• schedule - calendrier de sauvegarde
• borg_backup_files.sh - un script simple pour sauvegarder des fichiers (comme dans l'exemple ci-dessus).

Exemple d' schedule :

 # WARNING! CRONTAB MANAGED FROM GITLAB CI RUNNER IN ${CI_PROJECT_URL} # CI_COMMIT_SHA: ${CI_COMMIT_SHA} # Branch/tag: ${CI_COMMIT_REF_NAME} # Timestamp: ${TIMESTAMP} PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin # MyRemoteHost 0 0 * * * ${CI_PROJECT_DIR}/borg_backup_files.sh 'SYSTEM /etc,/opt' 

Les variables CI sont utilisées pour vérifier que la mise à jour de crontab a réussi et CI_PROJECT_DIR est le répertoire dans lequel le référentiel se trouvera après le clonage du runner. La dernière ligne indique que la sauvegarde est effectuée tous les jours à minuit.

Exemple borg_backup_files.sh :

 #!/bin/bash BORG_SERVER="borg@10.100.1.1" NAMEOFBACKUP=${1} DIRS=${2} REPOSITORY="${BORG_SERVER}:$(hostname)-${NAMEOFBACKUP}" borg create --list -v --stats \ $REPOSITORY::"files-{now:%Y-%m-%d_%H:%M:%S}" \ $(echo $DIRS | tr ',' ' ') || \ echo "borg create failed" 

Le premier argument ici est le nom de la sauvegarde, et le second est la liste des répertoires de la sauvegarde, séparés par des virgules. À strictement parler, une liste peut également être un ensemble de fichiers distincts.

2. GitLab Runner , fonctionnant sur la machine à sauvegarder et bloqué uniquement pour les travaux de ce référentiel.

3. Le script CI lui - même , implémenté par le .gitlab-ci.yml :

 stages: - deploy Deploy: stage: deploy script: - export TIMESTAMP=$(date '+%Y.%m.%d %H:%M:%S') - cat schedule | envsubst | crontab - tags: - borg-backup 

4. La clé SSH pour l'utilisateur gitlab-runner ayant accès au serveur de gitlab-runner (dans l'exemple, il s'agit de 10.100.1.1). Par défaut, il doit se trouver dans le .ssh/id_rsa ( gitlab-runner ).

5. L'utilisateur borg sur le même 10.100.1.1 avec accès uniquement à la commande borg serve :

 $ cat .ssh/authorized_keys command="/usr/bin/borg serve" ssh-rsa AAAAB3NzaC1yc2EAA... 

Maintenant, lorsque vous vous engagez dans le référentiel Runner, il remplira le contenu de crontab. Et lorsque le temps de réponse du cron arrive, une sauvegarde des répertoires /etc et /opt sera effectuée, qui sera sur le serveur de sauvegarde dans le MyHostname-SYSTEM du serveur 10.100.1.1.

Au lieu d'une conclusion: que pouvez-vous faire d'autre?

Bien entendu, l'utilisation de Borg à cet égard ne s'arrête pas là. Voici quelques idées pour une mise en œuvre ultérieure, dont certaines que nous avons déjà mises en œuvre à la maison:

• Ajoutez des scripts universels pour différentes sauvegardes qui, à la fin de l'exécution, exécutent borg_backup_files.sh , visant le répertoire avec le résultat de leur travail. Par exemple, vous pouvez sauvegarder PostgreSQL (pg_basebackup), MySQL (innobackupex), GitLab (travail de râteau intégré, création d'une archive).
• Hôte central avec calendrier de sauvegarde . Ne pas configurer sur chaque hôte GitLab Runner? Laissez-le être seul sur le serveur de sauvegarde et crontab au démarrage transfère le script de sauvegarde sur la machine et l'exécute là-bas. Pour cela, bien sûr, vous aurez besoin de l'utilisateur borg sur la machine client et ssh-agent , afin de ne pas disposer la clé du serveur de sauvegarde sur chaque machine.
• Suivi Où sans lui! Les alertes concernant une sauvegarde incorrecte doivent être.
• Suppression du dépôt borg des anciennes archives. Malgré une bonne déduplication, les anciennes sauvegardes doivent encore être nettoyées. Pour ce faire, vous pouvez appeler borg prune à la fin du script de sauvegarde.
• Interface Web au planning. Cela vous sera utile si l'édition de crontab à la main ou dans l'interface Web ne vous semble pas solide / inconfortable.
• Diagrammes à secteurs . Quelques graphiques pour une représentation visuelle du pourcentage de sauvegardes réussies, de leur temps d'exécution, de la largeur du canal "mangé". Pas étonnant que j'aie écrit qu'il n'y a pas assez de WebUI, comme dans Bareos ...
• Actions simples que je souhaiterais recevoir par un bouton: lancement d'une sauvegarde à la demande, restauration sur une machine, etc.

Et à la toute fin, je voudrais ajouter un exemple de l'efficacité de la déduplication sur une véritable sauvegarde de travail des fichiers PostgreSQL WAL dans un environnement de production:

 borg@backup ~ $ borg info PROJECT-PG-WAL Repository ID: 177eeb28056a60487bdfce96cfb33af1c186cb2a337226bc3d5380a78a6aeeb6 Location: /mnt/borg/PROJECT-PG-WAL Encrypted: No Cache: /mnt/borg/.cache/borg/177eeb28056a60487bdfce96cfb33af1c186cb2a337226bc3d5380a78a6aeeb6 Security dir: /mnt/borg/.config/borg/security/177eeb28056a60487bdfce96cfb33af1c186cb2a337226bc3d5380a78a6aeeb6 ------------------------------------------------------------------------------ Original size Compressed size Deduplicated size All archives: 6.68 TB 6.70 TB 19.74 GB Unique chunks Total chunks Chunk index: 11708 3230099 

Ce sont 65 jours de sauvegarde des fichiers WAL qui sont effectués toutes les heures. Lors de l'utilisation de Bacula / Bareos, c'est-à-dire sans déduplication, nous obtiendrions 6,7 To de données. Pensez-y: nous pouvons nous permettre de stocker près de 7 téraoctets de données transmises via PostgreSQL, seulement 20 Go d'espace réellement occupé.

PS

Lisez aussi dans notre blog:

• « Théorie et pratique des mises à niveau sans assistance dans Ubuntu »;
• " Junior, qui le premier jour de travail a supprimé la base de données de la production ";
• " Accélérer l'amorçage de grandes bases de données avec Kubernetes ."