Comment sauvegarder à grande échelle Gitlab?
Lorsqu'ils demandent au support Gitlab comment faire une sauvegarde de 3 To sur ceux Gitlab sur site, ils répondent en utilisant notre outil qui produit un tarball.
Cela me semble faux à tous les niveaux. Cette archive tar contient le vidage postgres, les images docker, les données de dépôt, la configuration GIT LFS, etc. et ainsi de suite. Sauvegarder TB de données statiques avec des données très dynamiques de la base de connaissances ne fonctionne pas correctement. Et puis vient le problème de, nous voulons faire une sauvegarde toutes les heures.
Question
J'aimerais vraiment savoir comment les autres procèdent, pour obtenir une sauvegarde cohérente.
ZFS sur Linux me conviendrait, si cela fait partie de la solution.
Pour un temps aussi court entre les sauvegardes (1h), votre meilleur pari est de compter sur un instantané au niveau du système de fichiers et send/recv soutien.
Si l'utilisation de ZoL n'est pas un problème dans votre environnement, je vous conseille fortement de l'utiliser. ZFS est un système de fichiers très robuste et vous aimerez vraiment tous les extras (par exemple: compression) qu'il offre. Couplé avec sanoid/syncoid , il peut fournir une stratégie de sauvegarde très solide. Le principal inconvénient est qu'il n'est pas inclus dans le noyau principal, vous devez donc l'installer/le mettre à jour séparément.
Alternativement, si vous avez vraiment besoin de vous limiter aux éléments inclus dans la ligne principale, vous pouvez utiliser BTRFS. Mais assurez-vous de comprendre ses (nombreux) inconvénients et pita .
Enfin, une solution alternative consiste à utiliser lvmthin pour effectuer des sauvegardes régulières (par exemple: avec snapper), en s'appuyant sur des outils tiers (par exemple: bdsync =, blocksync , etc.) pour copier/expédier les deltas uniquement.
Une approche différente consisterait à avoir deux machines répliquées (via DRBD ) où vous prenez des instantanés indépendants via lvmthin.
Je voudrais revoir ce que vous sauvegardez et éventuellement utiliser une approche "multi-chemins". Par exemple, vous pouvez sauvegarder les référentiels Git en exécutant constamment des tirages Git sur des serveurs de sauvegarde. Cela ne copierait que le diff et vous laisserait une deuxième copie de tous les référentiels Git. Vraisemblablement, vous pourriez détecter de nouveaux dépôts avec l'API.
Et utilisez les procédures de sauvegarde "intégrées" pour sauvegarder les problèmes, etc. Je doute que le 3 To provienne de cette partie afin que vous puissiez faire des sauvegardes très souvent à très peu de frais. Vous pouvez également configurer la base de données PostgreSQL avec une redondance d'alerte avec réplication.
Il est possible que votre 3 To provienne d'images de conteneurs dans le registre Docker. Avez-vous besoin de les sauvegarder? Si c'est le cas, alors il pourrait y avoir une meilleure approche juste pour cela.
Fondamentalement, je recommanderais vraiment de regarder ce qui constitue votre sauvegarde et de sauvegarder les données dans différentes parties.
Même l'outil de sauvegarde de GitLab a des options pour inclure/exclure certaines parties du système telles que le Docker Registry.