Comment GitLab vous aide à sauvegarder de grands stockages NextCloud

Hé Habr !

Aujourd'hui, je souhaite parler de notre expérience dans l'automatisation de la sauvegarde du Big Data à partir des stockages Nextcloud dans différentes configurations. Je travaille comme station-service chez Molniya AK, où nous gérons la configuration des systèmes informatiques ; Nextcloud est utilisé pour le stockage des données. Y compris, avec une structure distribuée, avec redondance.

Les problèmes liés aux caractéristiques des installations sont qu'il y a beaucoup de données. Le versioning fourni par Nextcloud, la redondance, les raisons subjectives, etc. créent de nombreux doublons.

Préhistoire

Lors de l'administration de Nextcloud, se pose le problème de l'organisation d'une sauvegarde efficace, qui doit être cryptée, car les données sont précieuses.

Nous proposons des options de stockage des sauvegardes chez nous ou chez le client sur des machines distinctes de Nextcloud, ce qui nécessite une approche automatisée et flexible de l'administration.

Il existe de nombreux clients, tous avec des configurations différentes, tous sur leurs propres sites et avec leurs propres caractéristiques. C’est une technique classique lorsque l’intégralité du site vous appartient et que les sauvegardes sont faites à partir de couronnes ; cela ne rentre pas bien.

Tout d'abord, regardons les données d'entrée. Nous avons besoin:

• Évolutivité en termes d’un ou plusieurs nœuds. Pour les grandes installations, nous utilisons minio comme stockage.
• Découvrez les problèmes liés à l'exécution des sauvegardes.
• Vous devez conserver une sauvegarde chez vos clients et/ou chez nous.
• Résolvez les problèmes rapidement et facilement.
• Les clients et les installations sont très différents les uns des autres - l'uniformité ne peut pas être obtenue.
• La vitesse de récupération doit être minimale dans deux scénarios : récupération complète (catastrophe), un dossier effacé par erreur.
• La fonction de déduplication est requise.

Pour résoudre le problème de gestion des sauvegardes, nous avons installé GitLab. Plus de détails par tacle.

Bien sûr, nous ne sommes pas les premiers à résoudre un tel problème, mais il nous semble que notre expérience pratique et durement acquise peut être intéressante et nous sommes prêts à la partager.

Notre entreprise ayant une politique open source, nous recherchions une solution open source. À notre tour, nous partageons nos développements et les publions. Par exemple, sur GitHub il y a notre plugin pour Nextcloud, que nous fournissons à nos clients, améliorant ainsi la sécurité des données en cas de suppression accidentelle ou intentionnelle.

Outils de sauvegarde

Nous avons commencé notre recherche de méthodes de solution en choisissant un outil de création de sauvegarde.

Tar + gzip régulier ne fonctionne pas bien - les données sont dupliquées. Un incrément contient souvent très peu de modifications réelles et la plupart des données d'un seul fichier sont répétées.
Il existe un autre problème : la redondance du stockage de données distribué. Nous utilisons minio et ses données sont fondamentalement redondantes. Ou vous avez dû faire une sauvegarde via minio lui-même - chargez-la et utilisez tous les espaceurs entre le système de fichiers et, non moins important, il y a un risque d'oublier certains compartiments et méta-informations. Ou utilisez la déduplication.

Des outils de sauvegarde avec duplication sont disponibles en open source (sur Habré il y avait articles à ce sujet) et nos finalistes étaient Borg и Restique. Notre comparaison des deux applications est ci-dessous, mais pour l’instant, nous allons vous expliquer comment nous avons organisé l’ensemble du programme.

Gestion des sauvegardes

Borg et Restic sont bons, mais aucun des deux produits ne dispose d'un mécanisme de contrôle centralisé. À des fins de gestion et de contrôle, nous avons choisi un outil que nous avons déjà implémenté, sans lequel nous ne pouvons imaginer notre travail, y compris l'automatisation - il s'agit du célèbre CI/CD - GitLab.

L'idée est la suivante : gitlab-runner est installé sur chaque nœud stockant les données Nextcloud. Le coureur exécute un script selon un calendrier qui surveille le processus de sauvegarde et lance Borg ou Restic.

Qu'avons-nous obtenu ? Retour d'information sur l'exécution, contrôle pratique des modifications, détails en cas d'erreur.

Ici ici sur GitHub nous avons publié des exemples de script pour diverses tâches et nous avons fini par le joindre à la sauvegarde non seulement de Nextcloud, mais également de nombreux autres services. Il y a aussi un planificateur si vous ne voulez pas le configurer manuellement (et nous ne voulons pas le faire) et .gitlab-ci.yml

Il n'existe pas encore de moyen de modifier le délai d'expiration CI/CD dans l'API Gitlab, mais il est petit. Il faut l'augmenter, disons 1d.

GitLab, heureusement, peut être lancé non seulement selon un commit, mais uniquement selon un calendrier, c'est exactement ce dont nous avons besoin.

Parlons maintenant du script wrapper.

Nous définissons les conditions suivantes pour ce script :

• Il doit être lancé à la fois par le coureur et manuellement depuis la console avec la même fonctionnalité.
• Il doit y avoir des gestionnaires d'erreurs :
• Code de retour.
• recherchez une chaîne dans le journal. Par exemple, pour nous, une erreur peut être un message que le programme ne considère pas comme fatal.
• Délai de traitement. Le délai de livraison doit être raisonnable.
• Nous avons besoin d'un journal très détaillé. Mais seulement en cas d'erreur.
• Un certain nombre de tests sont également effectués avant de démarrer.
• Petits bonus de commodité que nous avons trouvés utiles lors du processus d'assistance :
• Le début et la fin sont enregistrés dans le syslog de la machine locale. Cela permet de connecter les erreurs système et l’opération de sauvegarde.
• Une partie du journal des erreurs, le cas échéant, est sortie sur la sortie standard, l'intégralité du journal est écrite dans un fichier séparé. Il est pratique d'examiner immédiatement CI et d'évaluer l'erreur si elle est insignifiante.
• Modes de débogage.

Le journal complet est enregistré en tant qu'artefact dans GitLab ; s'il n'y a pas d'erreur, le journal est supprimé. Nous écrivons le script en bash.

Nous serons heureux d’examiner toutes suggestions et commentaires concernant l’open source – bienvenue.

Comment ça marche

Un exécuteur avec un exécuteur Bash est lancé sur le nœud de sauvegarde. Selon le planificateur, le travail CI/CD est lancé dans un navet spécial. Le coureur lance un script wrapper universel pour de telles tâches, il vérifie la validité du référentiel de sauvegarde, des points de montage et tout ce que nous voulons, puis sauvegarde et nettoie l'ancien. La sauvegarde terminée elle-même est envoyée à S3.

Nous travaillons selon ce schéma - il s'agit d'un fournisseur AWS externe ou d'un équivalent russe (c'est plus rapide et les données ne quittent pas la Fédération de Russie). Ou nous installons un cluster minio distinct pour le client sur son site à ces fins. Nous procédons généralement ainsi pour des raisons de sécurité, lorsque le client ne souhaite pas du tout que les données quittent son circuit.

Nous n'avons pas utilisé la fonctionnalité d'envoi de sauvegarde via ssh. Cela n'ajoute rien à la sécurité et les capacités réseau du fournisseur S3 sont bien supérieures à celles de notre seule machine ssh.

Afin de protéger votre machine locale contre un pirate informatique, puisqu'il peut effacer les données sur S3, vous devez activer le versionnage.
La sauvegarde chiffre toujours la sauvegarde.

Borg a un mode non crypté none, mais nous vous déconseillons fortement de l'activer. Dans ce mode, non seulement il n'y aura pas de cryptage, mais la somme de contrôle de ce qui est écrit n'est pas calculée, ce qui signifie que l'intégrité ne peut être vérifiée qu'indirectement, à l'aide d'index.

Un planificateur distinct vérifie les sauvegardes pour l'intégrité des index et du contenu. Le contrôle est lent et long, nous l'exécutons donc séparément une fois par mois. Cela peut prendre plusieurs jours.

Lisez-moi en russe

La fonction principale

• prepare entraînement
• testcheck contrôle de préparation
• maincommand équipe de base
• forcepostscript une fonction qui est exécutée à la fin ou par erreur. Nous l'utilisons pour démonter la partition.

Fonctions de service

• cleanup Nous enregistrons les erreurs ou effaçons le fichier journal.
• checklog analyser le journal pour détecter l'occurrence d'une ligne contenant une erreur.
• ret gestionnaire de sortie.
• checktimeout vérifiez le délai d'attente.

Environment

• VERBOSE=1 Nous affichons immédiatement les erreurs à l'écran (stdout).
• SAVELOGSONSUCCES=1 enregistrez le journal en cas de succès.
• INIT_REPO_IF_NOT_EXIST=1 Créez un référentiel s'il n'existe pas. Désactivé par défaut.
• TIMEOUT temps maximum pour l’opération principale. Vous pouvez le définir comme « m », « h » ou « d » à la fin.

Mode de stockage pour les anciennes copies. Défaut:

• KEEP_DAILY=7
• KEEP_WEEKLY=4
• KEEP_MONTHLY=6

Variables à l'intérieur du script

• ERROR_STRING — chaîne pour le journal d'enregistrement en cas d'erreur.
• EXTRACT_ERROR_STRING - expression pour afficher la chaîne en cas d'erreur.
• KILL_TIMEOUT_SIGNAL — signal de mise à mort en cas d'expiration du délai.
• TAIL — combien de chaînes avec des erreurs à l'écran.
• COLORMSG — couleur du message (jaune par défaut).

Ce script, appelé wordpress, a un nom conditionnel, son astuce est qu'il sauvegarde également la base de données mysql. Cela signifie qu'il peut être utilisé pour les installations Nexcloud à nœud unique, où vous pouvez également sauvegarder la base de données. La commodité réside non seulement dans le fait que tout est au même endroit, mais également dans le fait que le contenu de la base de données est proche du contenu des fichiers, car le décalage horaire est minime.

Restic contre Borg

Il existe également des comparaisons entre Borg et Restic ici sur Habré, et nous n’avions pas pour tâche d’en créer un autre, mais le nôtre. Il était important pour nous de savoir à quoi cela ressemblerait sur nos données, avec nos spécificités. Nous les apportons.

Nos critères de sélection, en plus de ceux déjà évoqués (déduplication, restauration rapide, etc.) :

• Résistance au travail inachevé. Vérifiez le kill -9.
• Taille sur le disque.
• Besoin en ressources (CPU, mémoire).
• Taille des blobs stockés.
• Travailler avec S3.
• Vérification de l'intégrité.

Pour les tests, nous avons pris un client avec des données réelles et une taille totale de 1,6 To.
Conditions.

Borg ne sait pas travailler directement avec S3, et nous avons monté le disque comme fusible, via les maladroits. Restic l'a envoyé à S3 lui-même.

Dingo fonctionne très vite et bien, et il y a module de cache disque, ce qui accélère encore plus le travail. Il est en phase bêta et, franchement, nous avons planté avec une perte de données lors de tests (autres). Mais la commodité est que la procédure de sauvegarde elle-même ne nécessite pas beaucoup de lecture, mais surtout d'écriture, nous utilisons donc le cache uniquement lors des contrôles d'intégrité.

Pour réduire l'influence du réseau, nous avons utilisé un fournisseur local - Yandex Cloud.

Résultats des tests de comparaison.

• Kill -9 avec un nouveau redémarrage a tous deux réussi.
• Taille sur le disque. Borg peut compresser, donc les résultats sont comme prévu.

Sauvegardeur
Taille

Borg
562Gb

Restique
628Gb

• Par processeur
  Borg lui-même consomme peu, avec une compression par défaut, mais il doit être évalué avec le processus goofys. Au total, ils sont comparables et utilisent environ 1,2 cœurs sur la même machine virtuelle de test.
• Mémoire. Restic fait environ 0,5 Go, Borg fait environ 200 Mo. Mais tout cela est insignifiant comparé au cache des fichiers système. Il est donc conseillé d'allouer plus de mémoire.
• La différence de taille des gouttes était frappante.

Sauvegardeur
Taille

Borg
environ 500 Mo

Restique
environ 5 Mo

• L'expérience avec le S3 de Restic est excellente. Travailler avec Borg via goofys ne soulève aucune question, mais il a été noté qu'il est conseillé d'effectuer umount une fois la sauvegarde terminée pour réinitialiser complètement le cache. La particularité de S3 est que les fragments sous-pompés ne seront jamais envoyés au bucket, ce qui signifie que des données incomplètement remplies entraînent des dommages importants.
• Le contrôle d’intégrité fonctionne bien dans les deux cas, mais la vitesse diffère considérablement.
  Restique Heures 3,5.
  Borg, avec un cache de fichiers SSD de 100 Go – 5 heures.Il en résulte environ la même vitesse si les données se trouvent sur un disque local.
  Borg lit directement depuis S3 sans cache Heures 33. Monstrueusement long.

L'essentiel est que Borg peut compresser et possède des blobs plus gros, ce qui rend le stockage et les opérations GET/PUT dans S3 moins chers. Mais cela se fait au prix d’une vérification plus complexe et plus lente. Quant à la vitesse de récupération, nous n’avons remarqué aucune différence. Restic prend les sauvegardes suivantes (après la première) un peu plus longtemps, mais pas de manière significative.

Le dernier choix, mais non le moindre, était la taille de la communauté.

Et nous avons choisi Borg.

Quelques mots sur la compression

Borg a un excellent nouvel algorithme de compression dans son arsenal - zstd. La qualité de compression n'est pas pire que celle de gzip, mais beaucoup plus rapide. Et comparable en vitesse au lz4 par défaut.

Par exemple, un dump de base de données MySQL est compressé deux fois mieux que lz4 à la même vitesse. Cependant, l'expérience avec des données réelles montre qu'il y a très peu de différence dans le taux de compression du nœud Nextcloud.

Borg a un mode de compression plutôt bonus - si le fichier a une entropie élevée, alors la compression n'est pas appliquée du tout, ce qui augmente la vitesse. Activé par option lors de la création
-C auto,zstd
pour l'algorithme zstd
Donc avec cette option, en comparaison avec la compression par défaut, nous avons
560 Go et 562 Go respectivement. Les données de l'exemple ci-dessus, je vous le rappelle, sans compression, le résultat est de 628 Go. Le résultat d'une différence de 2 Go nous a quelque peu surpris, mais nous avons pensé que nous le choisirions finalement. auto,zstd.

Méthode de vérification des sauvegardes

Selon le planificateur, la machine virtuelle est lancée directement depuis le fournisseur ou depuis le client, ce qui réduit considérablement la charge du réseau. Au moins, c'est moins cher que de l'élever soi-même et de générer du trafic.

goofys --cache "--free:5%:/mnt/cache" -o allow_other --endpoint https://storage.yandexcloud.net --file-mode=0666 --dir-mode=0777 xxxxxxx.com /mnt/goofys
export BORG_PASSCOMMAND="cat /home/borg/.borg-passphrase"
borg list /mnt/goofys/borg1/
borg check --debug -p --verify-data /mnt/goofys/borg1/

En utilisant le même schéma, nous vérifions les fichiers avec un antivirus (après coup). Après tout, les utilisateurs téléchargent différentes choses sur Nextcloud et tout le monde ne dispose pas d'un antivirus. Effectuer des inspections au moment du coulage prend trop de temps et nuit aux affaires.

L'évolutivité est obtenue en exécutant des exécuteurs sur différents nœuds avec différentes balises.
Notre surveillance collecte les statuts des sauvegardes via l'API GitLab dans une seule fenêtre ; si nécessaire, les problèmes sont facilement détectés et tout aussi facilement localisés.

Conclusion

En conséquence, nous savons avec certitude que nous effectuons des sauvegardes, que nos sauvegardes sont valides, que les problèmes qui en découlent prennent peu de temps et sont résolus au niveau de l'administrateur de service. Les sauvegardes prennent très peu de place par rapport à tar.gz ou Bacula.

Source: habr.com