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 mal à tous les niveaux. Cette archive contient le vidage postgres, les images docker, les données de dépôt, la configuration GIT LFS, etc., etc. La sauvegarde de 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é et une send/recv prise en charge au niveau du système de fichiers .

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. Associé à 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 autre solution consiste à utiliser lvmthinpour effectuer des sauvegardes régulières (par exemple: avec snapper), en se fondant sur des outils tiers (par exemple: bdsync, blocksync, etc.) pour copier / deltas navire seulement.

Une approche différente serait d'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 pouvez 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 peut 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.