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.

— Sandra
source

Pourquoi est-ce mal? Vous sauvegardez complètement votre Gitlab pour le restaurer complètement. Je ne pense pas que ce soit faux. Bien sûr, il utilise beaucoup plus d'espace que, disons, les sauvegardes incrémentielles, mais ... Je me fiche de la taille de la sauvegarde.

— Lenniey

Avoir une sauvegarde toutes les heures n'est pas inconnu, mais il est impossible de faire un 3 To en moins d'une heure avec leur approche. Et les sauvegardes pour une seule journée seraient d'environ 100 To, où il ne pourrait y avoir que 10 Mo de modifications des données.

— Sandra

OK, c'est une question différente, pas sur la sauvegarde en général mais sur les sauvegardes fréquentes.

— Lenniey

Dans leurs documents officiels, ils mentionnent même leur méthode comme étant lente et suggèrent des alternatives:

If your GitLab server contains a lot of Git repository data you may find the GitLab backup script to be too slow. In this case you can consider using filesystem snapshots as part of your backup strategy.

je ne peux pas parler d'expérience, cependant. Mais je

— devrais

Gitlab a des options dans le fichier de configuration et des drapeaux de sauvegarde qui vous permettront d'exclure des sections, ou d'aller jusqu'à stocker des images et des artefacts sur un magasin d'objets

— ssube

Réponses:

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.

— shodanshok
source

Et les postgres? Souhaitez-vous arrêter gitlab et postgres pendant une minute, afin de pouvoir faire une image cohérente? Idéalement, ce serait génial si les postgres pouvaient être mis en mode lecture seule pendant que l'instantané est fait.

— Sandra

La restauration de @Sandra à partir d'un instantané de système de fichiers devrait apparaître dans postgresql (et dans toute autre base de données correctement écrite) comme un scénario générique de "plantage de l'hôte", déclenchant sa propre procédure de récupération (c'est-à-dire: validation dans la base de données principale de toute page partiellement écrite). En d'autres termes, vous n'avez pas besoin de mettre les postgres en mode lecture seule lorsque vous prenez des instantanés.

— shodanshok

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.

— ETL
source

git pulls n'est pas une sauvegarde incrémentielle parfaite. git push --forceinterrompra les sauvegardes ou supprimera leur historique, en fonction de la façon dont il est mis en œuvre.

— user371366

@ dn3s c'est pourquoi vous désactivez toujours git push --force sur le référentiel principal. Si quelqu'un veut changer l'histoire, il peut créer sa propre fourchette et accepter tous les risques que cela comporte.

— charlie_pl

cela peut convenir à la réplication , mais vous ne voulez pas que l'intégrité de vos sauvegardes repose sur le comportement correct de l'application. que se passe-t-il s'il y a un bogue dans l'application ou s'il est mal configuré en cours de route? que faire si votre serveur est compromis par un utilisateur malveillant? si votre application a la possibilité de supprimer du contenu de l'hôte de sauvegarde, une grande partie de la valeur des sauvegardes distantes incrémentielles est perdue.

— user371366