doc-locale/fr-fr/administration/backup_restore/backup_gitlab.md
{{< details >}}
{{< /details >}}
Les sauvegardes GitLab protègent vos données et facilitent la reprise après sinistre.
La stratégie de sauvegarde optimale dépend de la configuration de votre déploiement GitLab, du volume de données et des emplacements de stockage. Ces facteurs déterminent les méthodes de sauvegarde à utiliser, où stocker les sauvegardes et comment structurer votre planning de sauvegarde.
Pour les instances GitLab plus importantes, les stratégies de sauvegarde alternatives incluent :
{{< history >}}
{{< /history >}}
GitLab fournit une interface de ligne de commande pour sauvegarder l'intégralité de votre instance. Par défaut, la sauvegarde crée une archive dans un seul fichier tar compressé. Ce fichier comprend :
[!warning] Il est fortement conseillé de lire la section sur le stockage des fichiers de configuration pour les sauvegarder séparément.
/etc/gitlab)À titre indicatif, si vous utilisez une architecture de référence 1k avec moins de 100 Go de données, suivez ces étapes :
Voir aussi :
À mesure que le volume de données GitLab augmente, la commande de sauvegarde prend plus de temps à s'exécuter. Les options de sauvegarde telles que la sauvegarde simultanée des dépôts Git et les sauvegardes incrémentielles de dépôts peuvent aider à réduire le temps d'exécution. À un certain stade, la commande de sauvegarde devient impraticable par elle-même. Par exemple, cela peut prendre 24 heures ou plus.
À partir de GitLab 18.0, les performances de sauvegarde des dépôts ont été considérablement améliorées pour les dépôts comportant un grand nombre de références (branches, tags). Cette amélioration peut réduire les temps de sauvegarde de plusieurs heures à quelques minutes pour les dépôts concernés. Aucune modification de configuration n'est requise pour bénéficier de cette amélioration.
Dans certains cas, des modifications architecturales peuvent être nécessaires pour permettre la mise à l'échelle des sauvegardes.
Pour aller plus loin :
Les données suivantes doivent être sauvegardées.
Dans le cas le plus simple, GitLab dispose d'une seule base de données PostgreSQL sur un serveur PostgreSQL sur la même VM que tous les autres services GitLab. Mais selon la configuration, GitLab peut utiliser plusieurs bases de données PostgreSQL sur plusieurs serveurs PostgreSQL.
En général, ces données constituent la source unique de vérité pour la plupart des contenus générés par les utilisateurs dans l'interface Web, tels que le contenu des tickets et des merge requests, les commentaires, les autorisations et les identifiants.
PostgreSQL contient également des données mises en cache comme le Markdown rendu en HTML, et par défaut, les diffs de merge request. Cependant, les diffs de merge request peuvent également être configurés pour être déchargés vers le système de fichiers ou le stockage d'objets.
Gitaly Cluster (Praefect) utilise une base de données PostgreSQL comme source unique de vérité pour gérer ses nœuds Gitaly.
Un utilitaire PostgreSQL courant, pg_dump, produit un fichier de sauvegarde qui peut être utilisé pour restaurer une base de données PostgreSQL. La commande de sauvegarde utilise cet utilitaire en arrière-plan.
Malheureusement, plus la base de données est volumineuse, plus pg_dump prend de temps à s'exécuter. Selon votre situation, la durée devient impraticable à un certain stade (plusieurs jours, par exemple). Si votre base de données dépasse 100 Go, pg_dump, et par extension la commande de sauvegarde, ne sera probablement pas utilisable. Pour plus d'informations, consultez les stratégies de sauvegarde alternatives.
Une instance GitLab peut avoir un ou plusieurs fragments de dépôt. Chaque fragment est une instance Gitaly ou un Gitaly Cluster (Praefect) responsable de l'accès et des opérations sur les dépôts Git stockés localement. Gitaly peut s'exécuter sur une machine :
Chaque projet peut avoir jusqu'à 3 dépôts différents :
Ils résident tous dans le même fragment et partagent le même nom de base avec un suffixe -wiki et -design pour les cas de Wiki et de dépôt de conception.
Les extraits de code personnels et de projet, ainsi que le contenu du wiki de groupe, sont stockés dans des dépôts Git.
Les duplications de projet sont dédupliquées dans un site GitLab à l'aide de dépôts de pool.
La commande de sauvegarde produit un bundle Git pour chaque dépôt et les archive tous ensemble. Cela duplique les données du dépôt de pool dans chaque duplication. Lors de nos tests, 100 Go de dépôts Git ont nécessité un peu plus de 2 heures pour être sauvegardés et téléchargés sur S3. Avec environ 400 Go de données Git, la commande de sauvegarde n'est probablement pas viable pour des sauvegardes régulières. Pour plus d'informations, consultez les stratégies de sauvegarde alternatives.
GitLab stocke les blobs (ou fichiers) tels que les pièces jointes aux tickets ou les objets LFS dans :
La commande de sauvegarde ne sauvegarde pas les blobs qui ne sont pas stockés sur le système de fichiers. Si vous utilisez le stockage d'objets, assurez-vous d'activer les sauvegardes auprès de votre fournisseur de stockage d'objets.
Guides de sauvegarde spécifiques aux fournisseurs :
Voir aussi :
Le stockage du registre de conteneurs GitLab peut être configuré dans :
La commande de sauvegarde ne sauvegarde pas les données du registre lorsqu'elles sont stockées dans le stockage d'objets.
Si vous avez activé la base de données de métadonnées du registre de conteneurs, vous devez configurer l'accès à la base de données du registre pendant la sauvegarde. Suivez les instructions de votre installation GitLab pour configurer les identifiants requis :
Voir aussi :
[!warning] La tâche Rake de sauvegarde fournie par GitLab ne stocke pas vos fichiers de configuration. La raison principale est que votre base de données contient des éléments incluant des informations chiffrées pour l'authentification à deux facteurs et les variables sécurisées CI/CD. Stocker des informations chiffrées au même endroit que leur clé annule l'intérêt d'utiliser le chiffrement. Par exemple, le fichier secrets contient votre clé de chiffrement de base de données. Si vous le perdez, l'application GitLab ne pourra plus déchiffrer les valeurs chiffrées dans la base de données.
De plus, le fichier secrets peut changer après les mises à niveau.
Vous devez sauvegarder le répertoire de configuration. Au minimum absolu, vous devez sauvegarder :
{{< tabs >}}
{{< tab title="Package Linux" >}}
/etc/gitlab/gitlab-secrets.json/etc/gitlab/gitlab.rbPour plus d'informations, consultez Sauvegarde et restauration de la configuration du package Linux (Omnibus).
{{< /tab >}}
{{< tab title="Auto-compilé" >}}
/home/git/gitlab/config/secrets.yml/home/git/gitlab/config/gitlab.yml{{< /tab >}}
{{< tab title="Docker" >}}
/srv/gitlab/config.{{< /tab >}}
{{< tab title="Chart GitLab Helm" >}}
{{< /tab >}}
{{< /tabs >}}
Vous pouvez également sauvegarder les clés et certificats TLS (/etc/gitlab/ssl, /etc/gitlab/trusted-certs), ainsi que vos clés hôtes SSH pour éviter les avertissements d'attaque de l'homme du milieu si vous devez effectuer une restauration complète de la machine.
Dans le cas improbable où le fichier secrets est perdu, consultez Lorsque le fichier secrets est perdu.
GitLab utilise Redis à la fois comme cache et pour stocker les données persistantes de notre système de jobs en arrière-plan, Sidekiq. La commande de sauvegarde fournie ne sauvegarde pas les données Redis. Cela signifie que pour effectuer une sauvegarde cohérente avec la commande de sauvegarde, il ne doit y avoir aucun job en attente ou en cours d'exécution en arrière-plan.
Elasticsearch est une base de données optionnelle pour la recherche avancée. Elle peut améliorer la recherche au niveau du code source et dans le contenu généré par les utilisateurs dans les tickets, les merge requests et les discussions. La commande de sauvegarde ne sauvegarde pas les données Elasticsearch. Les données Elasticsearch peuvent être régénérées à partir des données PostgreSQL après une restauration.
Options de sauvegarde manuelle :
Voir aussi : Détails de la commande de sauvegarde.
Pour pouvoir sauvegarder et restaurer, assurez-vous que Rsync est installé sur votre système. Si vous avez installé GitLab :
rsync est installé et installez-le si ce n'est pas le cas.Important considerations:
Pour créer une sauvegarde :
{{< tabs >}}
{{< tab title="Package Linux (Omnibus)" >}}
sudo gitlab-backup create
{{< /tab >}}
{{< tab title="Chart Helm (Kubernetes)" >}}
Exécutez la tâche de sauvegarde en utilisant kubectl pour exécuter le script backup-utility sur le pod toolbox GitLab. Pour plus de détails, consultez la documentation de sauvegarde des charts.
{{< /tab >}}
{{< tab title="Docker" >}}
Exécutez la sauvegarde depuis l'hôte.
docker exec -t <container name> gitlab-backup create
{{< /tab >}}
{{< tab title="Auto-compilé" >}}
sudo -u git -H bundle exec rake gitlab:backup:create RAILS_ENV=production
{{< /tab >}}
{{< /tabs >}}
Si votre déploiement GitLab comporte plusieurs nœuds, vous devez choisir un nœud pour exécuter la commande de sauvegarde. Vous devez vous assurer que le nœud désigné :
Exemple de sortie :
Dumping database tables:
- Dumping table events... [DONE]
- Dumping table issues... [DONE]
- Dumping table keys... [DONE]
- Dumping table merge_requests... [DONE]
- Dumping table milestones... [DONE]
- Dumping table namespaces... [DONE]
- Dumping table notes... [DONE]
- Dumping table projects... [DONE]
- Dumping table protected_branches... [DONE]
- Dumping table schema_migrations... [DONE]
- Dumping table services... [DONE]
- Dumping table snippets... [DONE]
- Dumping table taggings... [DONE]
- Dumping table tags... [DONE]
- Dumping table users... [DONE]
- Dumping table users_projects... [DONE]
- Dumping table web_hooks... [DONE]
- Dumping table wikis... [DONE]
Dumping repositories:
- Dumping repository abcd... [DONE]
Creating backup archive: <backup-id>_gitlab_backup.tar [DONE]
Deleting tmp directories...[DONE]
Deleting old backups... [SKIPPING]
Pour des informations détaillées sur le processus de sauvegarde, consultez Processus d'archivage des sauvegardes.
L'outil de ligne de commande fourni par GitLab pour sauvegarder votre instance peut accepter davantage d'options.
La stratégie de sauvegarde par défaut consiste essentiellement à diffuser les données depuis les emplacements de données respectifs vers la sauvegarde à l'aide des commandes Linux tar et gzip. Cela fonctionne bien dans la plupart des cas, mais peut poser des problèmes lorsque les données changent rapidement.
Lorsque les données changent pendant que tar les lit, l'erreur file changed as we read it peut se produire et entraîner l'échec du processus de sauvegarde. Dans ce cas, vous pouvez utiliser la stratégie de sauvegarde appelée copy. La stratégie copie les fichiers de données vers un emplacement temporaire avant d'appeler tar et gzip, évitant ainsi l'erreur.
Un effet secondaire est que le processus de sauvegarde utilise jusqu'à 1X d'espace disque supplémentaire. Le processus fait de son mieux pour nettoyer les fichiers temporaires à chaque étape, afin que le problème ne s'aggrave pas, mais cela peut représenter un changement considérable pour les grandes installations.
Pour utiliser la stratégie copy plutôt que la stratégie de diffusion par défaut, spécifiez STRATEGY=copy dans la commande de tâche Rake. Par exemple :
sudo gitlab-backup create STRATEGY=copy
[!warning] Si vous utilisez un nom de fichier de sauvegarde personnalisé, vous ne pouvez pas limiter la durée de vie des sauvegardes.
Les fichiers de sauvegarde sont créés avec des noms de fichiers conformes aux valeurs par défaut spécifiques. Cependant, vous pouvez remplacer la partie <backup-id> du nom de fichier en définissant la variable d'environnement BACKUP. Par exemple :
sudo gitlab-backup create BACKUP=dump
Le fichier résultant est nommé dump_gitlab_backup.tar. Ceci est utile pour les systèmes qui utilisent rsync et les sauvegardes incrémentielles, et permet d'obtenir des vitesses de transfert considérablement plus rapides.
Par défaut, la compression rapide Gzip est appliquée lors de la sauvegarde de :
Voir aussi :
La commande par défaut est gzip -c -1. Vous pouvez remplacer cette commande par COMPRESS_CMD. De même, vous pouvez remplacer la commande de décompression par DECOMPRESS_CMD.
Mises en garde :
stdout..gz.gzip -cd. Par conséquent, si vous remplacez la commande de compression pour utiliser un format qui ne peut pas être décompressé par gzip -cd, vous devez remplacer la commande de décompression lors de la restauration.gitlab-backup create COMPRESS_CMD="pigz -c --best" ne fonctionne pas comme prévu.gitlab-backup create
COMPRESS_CMD="gzip -c --best" gitlab-backup create
Si gzip a été utilisé pour la sauvegarde, la restauration ne nécessite aucune option :
gitlab-backup restore
Si votre destination de sauvegarde dispose d'une compression automatique intégrée, vous pouvez souhaiter ignorer la compression.
La commande tee redirige stdin vers stdout.
COMPRESS_CMD=tee gitlab-backup create
Et lors de la restauration :
DECOMPRESS_CMD=tee gitlab-backup restore
pigz {#parallel-compression-with-pigz}[!warning] Bien que nous prenions en charge l'utilisation de
COMPRESS_CMDetDECOMPRESS_CMDpour remplacer la bibliothèque de compression Gzip par défaut, nous ne testons la bibliothèque Gzip par défaut qu'avec les options par défaut de façon régulière. Vous êtes responsable des tests et de la validation de la viabilité de vos sauvegardes. Nous recommandons fortement cela comme bonne pratique générale pour les sauvegardes, que vous remplaciez ou non la commande de compression. Si vous rencontrez des problèmes avec une autre bibliothèque de compression, vous devriez revenir à la bibliothèque par défaut. Le dépannage et la correction des erreurs avec des bibliothèques alternatives sont une priorité moindre pour GitLab.
Un exemple de compression des sauvegardes avec pigz en utilisant 4 processus :
sudo COMPRESS_CMD="pigz --stdout --fast --processes 4" gitlab-backup create
Étant donné que pigz compresse au format gzip, il n'est pas nécessaire d'utiliser pigz pour décompresser les sauvegardes qui ont été compressées par pigz. Cependant, cela peut tout de même offrir un avantage de performance par rapport à gzip. Un exemple de décompression des sauvegardes avec pigz :
sudo DECOMPRESS_CMD="pigz --decompress --stdout" gitlab-backup restore
[!note]
pigzn'est pas inclus dans le package Linux GitLab. Vous devez l'installer vous-même.
zstd {#parallel-compression-with-zstd}[!warning] Bien que nous prenions en charge l'utilisation de
COMPRESS_CMDetDECOMPRESS_CMDpour remplacer la bibliothèque de compression Gzip par défaut, nous ne testons la bibliothèque Gzip par défaut qu'avec les options par défaut de façon régulière. Vous êtes responsable des tests et de la validation de la viabilité de vos sauvegardes. Nous recommandons fortement cela comme bonne pratique générale pour les sauvegardes, que vous remplaciez ou non la commande de compression. Si vous rencontrez des problèmes avec une autre bibliothèque de compression, vous devriez revenir à la bibliothèque par défaut. Le dépannage et la correction des erreurs avec des bibliothèques alternatives sont une priorité moindre pour GitLab.
Un exemple de compression des sauvegardes avec zstd en utilisant 4 threads :
sudo COMPRESS_CMD="zstd --compress --stdout --fast --threads=4" gitlab-backup create
Un exemple de décompression des sauvegardes avec zstd :
sudo DECOMPRESS_CMD="zstd --decompress --stdout" gitlab-backup restore
[!note]
zstdn'est pas inclus dans le package Linux GitLab. Vous devez l'installer vous-même.
Pour vous assurer que l'archive générée est transférable par rsync, vous pouvez définir l'option GZIP_RSYNCABLE=yes. Cela définit l'option --rsyncable pour gzip, ce qui n'est utile qu'en combinaison avec la définition de l'option de nom de fichier de sauvegarde.
L'option --rsyncable dans gzip n'est pas garantie d'être disponible sur toutes les distributions. Pour vérifier qu'elle est disponible dans votre distribution, exécutez gzip --help ou consultez les pages de manuel.
sudo gitlab-backup create BACKUP=dump GZIP_RSYNCABLE=yes
Selon le type d'installation, des composants légèrement différents peuvent être ignorés lors de la création de la sauvegarde.
{{< tabs >}}
{{< tab title="Package Linux (Omnibus) / Docker / Auto-compilé" >}}
<!-- source: <https://gitlab.com/gitlab-org/gitlab/-/blob/d693aa7f894c7306a0d20ab6d138a7b95785f2ff/lib/backup/manager.rb#L117-133> -->db (base de données)repositories (données des dépôts Git, wikis inclus)uploads (pièces jointes)builds (logs de sortie des jobs CI)artifacts (artefacts de job CI)pages (contenu Pages)lfs (objets LFS)terraform_state (états Terraform)registry (images du registre de conteneurs)packages (paquets)ci_secure_files (fichiers sécurisés au niveau du projet)external_diffs (diffs de merge request externes){{< /tab >}}
{{< tab title="Chart Helm (Kubernetes)" >}}
<!-- source: <https://gitlab.com/gitlab-org/build/CNG/-/blob/068e146db915efcd875414e04403410b71a2e70c/gitlab-toolbox/scripts/bin/backup-utility#L19> -->db (base de données)repositories (données des dépôts Git, wikis inclus)uploads (pièces jointes)artifacts (artefacts de job CI et logs de sortie)pages (contenu Pages)lfs (objets LFS)terraform_state (états Terraform)registry (images du registre de conteneurs)packages (registre de paquets)ci_secure_files (fichiers sécurisés au niveau du projet)external_diffs (diffs de merge request){{< /tab >}}
{{< /tabs >}}
{{< tabs >}}
{{< tab title="Package Linux (Omnibus)" >}}
sudo gitlab-backup create SKIP=db,uploads
{{< /tab >}}
{{< tab title="Chart Helm (Kubernetes)" >}}
Consultez Ignorer des composants dans la documentation de sauvegarde des charts.
{{< /tab >}}
{{< tab title="Auto-compilé" >}}
sudo -u git -H bundle exec rake gitlab:backup:create SKIP=db,uploads RAILS_ENV=production
{{< /tab >}}
{{< /tabs >}}
SKIP= est également utilisé pour :
SKIP=tar).SKIP=remote).[!note] Il n'est pas possible d'ignorer la création tar lors de l'utilisation du stockage d'objets pour les sauvegardes.
La dernière partie de la création d'une sauvegarde est la génération d'un fichier .tar contenant toutes les parties. Dans certains cas, la création d'un fichier .tar peut être un effort inutile ou même directement nuisible. Vous pouvez donc ignorer cette étape en ajoutant tar à la variable d'environnement SKIP. Exemples d'utilisation :
PREVIOUS_BACKUP et BACKUP ne doivent pas être spécifiés, sinon la sauvegarde spécifiée est extraite, mais aucun fichier .tar n'est généré à la fin.)L'ajout de tar à la variable SKIP laisse les fichiers et répertoires contenant la sauvegarde dans le répertoire utilisé pour les fichiers intermédiaires. Ces fichiers sont écrasés lors de la création d'une nouvelle sauvegarde. Vous devez donc vous assurer qu'ils sont copiés ailleurs, car vous ne pouvez avoir qu'une seule sauvegarde sur le système.
{{< tabs >}}
{{< tab title="Package Linux (Omnibus)" >}}
sudo gitlab-backup create SKIP=tar
{{< /tab >}}
{{< tab title="Auto-compilé" >}}
sudo -u git -H bundle exec rake gitlab:backup:create SKIP=tar RAILS_ENV=production
{{< /tab >}}
{{< /tabs >}}
{{< history >}}
gitlab-backup dans GitLab 16.3.gitlab-backup pour la restauration d'une sauvegarde spécifiée plutôt que la dernière sauvegarde introduite dans GitLab 16.6.gitlab-backup pour la création de sauvegardes incrémentielles introduite dans GitLab 16.6.backup-utility introduite dans GitLab 17.0.{{< /history >}}
Au lieu de stocker de volumineuses sauvegardes de dépôts dans l'archive de sauvegarde, les sauvegardes de dépôts peuvent être configurées de sorte que le nœud Gitaly hébergeant chaque dépôt soit responsable de la création de la sauvegarde et de sa diffusion vers le stockage d'objets. Cela permet de réduire les ressources réseau nécessaires à la création et à la restauration d'une sauvegarde.
{{< tabs >}}
{{< tab title="Package Linux (Omnibus)" >}}
sudo gitlab-backup create REPOSITORIES_SERVER_SIDE=true
{{< /tab >}}
{{< tab title="Auto-compilé" >}}
sudo -u git -H bundle exec rake gitlab:backup:create REPOSITORIES_SERVER_SIDE=true
{{< /tab >}}
{{< tab title="Chart Helm (Kubernetes)" >}}
kubectl exec <Toolbox pod name> -it -- backup-utility --repositories-server-side
Lorsque vous utilisez des sauvegardes basées sur cron, ajoutez le drapeau --repositories-server-side aux arguments supplémentaires.
{{< /tab >}}
{{< /tabs >}}
Lors de l'utilisation de plusieurs stockages de dépôts, les dépôts peuvent être sauvegardés ou restaurés simultanément pour optimiser l'utilisation du temps CPU. Les variables suivantes sont disponibles pour modifier le comportement par défaut de la tâche Rake :
GITLAB_BACKUP_MAX_CONCURRENCY : Le nombre maximum de projets à sauvegarder en même temps. Par défaut, correspond au nombre de processeurs logiques.GITLAB_BACKUP_MAX_STORAGE_CONCURRENCY : Le nombre maximum de projets à sauvegarder en même temps sur chaque stockage. Cela permet de répartir les sauvegardes de dépôts entre les stockages. La valeur par défaut est 2.Par exemple, avec 4 stockages de dépôts :
{{< tabs >}}
{{< tab title="Package Linux (Omnibus)" >}}
sudo gitlab-backup create GITLAB_BACKUP_MAX_CONCURRENCY=4 GITLAB_BACKUP_MAX_STORAGE_CONCURRENCY=1
{{< /tab >}}
{{< tab title="Auto-compilé" >}}
sudo -u git -H bundle exec rake gitlab:backup:create GITLAB_BACKUP_MAX_CONCURRENCY=4 GITLAB_BACKUP_MAX_STORAGE_CONCURRENCY=1
{{< /tab >}}
{{< tab title="Chart Helm (Kubernetes)" >}}
toolbox:
#...
extra: {}
extraEnv:
GITLAB_BACKUP_MAX_CONCURRENCY: 4
GITLAB_BACKUP_MAX_STORAGE_CONCURRENCY: 1
{{< /tab >}}
{{< /tabs >}}
{{< history >}}
{{< /history >}}
[!note] Seuls les dépôts prennent en charge les sauvegardes incrémentielles. Par conséquent, si vous utilisez
INCREMENTAL=yes, la tâche crée une archive tar de sauvegarde autonome. En effet, toutes les sous-tâches, sauf les dépôts, créent toujours des sauvegardes complètes (elles écrasent la sauvegarde complète existante). Consultez le ticket 19256 pour une demande de fonctionnalité visant à prendre en charge les sauvegardes incrémentielles pour toutes les sous-tâches.
Les sauvegardes incrémentielles de dépôts peuvent être plus rapides que les sauvegardes complètes de dépôts car elles ne regroupent que les modifications depuis la dernière sauvegarde dans le bundle de sauvegarde de chaque dépôt. Les archives de sauvegarde produites par gitlab-backup sont portables et autonomes car elles contiennent toutes les étapes nécessaires pour restaurer chaque dépôt à partir de la sauvegarde complète d'origine.
Pour restaurer une sauvegarde incrémentielle vers une nouvelle instance GitLab (sans données préexistantes), vous devez créer la sauvegarde incrémentielle à partir d'une sauvegarde complète. N'ignorez aucun composant de sauvegarde lors de la création de la sauvegarde de base.
Avec les sauvegardes de dépôts côté serveur, les fichiers de sauvegarde incrémentielle de dépôts sont stockés séparément dans le stockage d'objets. Chaque incrément dépend de toutes les étapes précédentes jusqu'à la sauvegarde complète d'origine.
[!warning] Ne supprimez pas les fichiers de sauvegarde incrémentielle du stockage d'objets. Si un fichier intermédiaire est supprimé (par exemple, via une politique de cycle de vie du stockage d'objets), la chaîne de sauvegarde est rompue et la sauvegarde ne peut pas être restaurée.
Pour plus de détails, consultez Restaurer une sauvegarde incrémentielle de dépôt.
Utilisez l'option PREVIOUS_BACKUP=<backup-id> pour choisir la sauvegarde à utiliser. Par défaut, un fichier de sauvegarde est créé comme documenté dans la section ID de sauvegarde. Vous pouvez remplacer la partie <backup-id> du nom de fichier en définissant la variable d'environnement BACKUP.
Pour créer une sauvegarde incrémentielle, exécutez :
sudo gitlab-backup create INCREMENTAL=yes PREVIOUS_BACKUP=<backup-id>
Pour créer une sauvegarde incrémentielle non archivée à partir d'une sauvegarde archivée, utilisez SKIP=tar :
sudo gitlab-backup create INCREMENTAL=yes SKIP=tar
{{< history >}}
{{< /history >}}
Lors de l'utilisation de plusieurs stockages de dépôts, les dépôts de stockages de dépôts spécifiques peuvent être sauvegardés séparément à l'aide de l'option REPOSITORIES_STORAGES. L'option accepte une liste de noms de stockage séparés par des virgules.
Par exemple :
{{< tabs >}}
{{< tab title="Package Linux (Omnibus)" >}}
sudo gitlab-backup create REPOSITORIES_STORAGES=storage1,storage2
{{< /tab >}}
{{< tab title="Auto-compilé" >}}
sudo -u git -H bundle exec rake gitlab:backup:create REPOSITORIES_STORAGES=storage1,storage2
{{< /tab >}}
{{< /tabs >}}
{{< history >}}
{{< /history >}}
Vous pouvez sauvegarder des dépôts spécifiques à l'aide de l'option REPOSITORIES_PATHS. De même, vous pouvez utiliser SKIP_REPOSITORIES_PATHS pour ignorer certains dépôts. Les deux options acceptent une liste de chemins de projet ou de groupe séparés par des virgules. Si vous spécifiez un chemin de groupe, tous les dépôts de tous les projets du groupe et des groupes descendants sont inclus ou ignorés, selon l'option utilisée.
Par exemple, pour sauvegarder tous les dépôts de tous les projets du Groupe A (group-a), le dépôt du Projet C dans le Groupe B (group-b/project-c), et ignorer le Projet D dans le Groupe A (group-a/project-d) :
{{< tabs >}}
{{< tab title="Package Linux (Omnibus)" >}}
sudo gitlab-backup create REPOSITORIES_PATHS=group-a,group-b/project-c SKIP_REPOSITORIES_PATHS=group-a/project-d
{{< /tab >}}
{{< tab title="Auto-compilé" >}}
sudo -u git -H bundle exec rake gitlab:backup:create REPOSITORIES_PATHS=group-a,group-b/project-c SKIP_REPOSITORIES_PATHS=group-a/project-d
{{< /tab >}}
{{< tab title="Chart Helm (Kubernetes)" >}}
REPOSITORIES_PATHS=group-a SKIP_REPOSITORIES_PATHS=group-a/project_a2 backup-utility --skip db,registry,uploads,artifacts,lfs,packages,external_diffs,terraform_state,ci_secure_files,pages
{{< /tab >}}
{{< /tabs >}}
[!note] Il n'est pas possible de d'ignorer la création tar lors de l'utilisation du stockage d'objets pour les sauvegardes.
Vous pouvez laisser le script de sauvegarde téléverser le fichier .tar qu'il crée vers un stockage distant. Dans l'exemple suivant, nous utilisons Amazon S3 pour le stockage, mais vous pouvez également utiliser d'autres fournisseurs cloud comme Google Cloud Storage et Azure, ou des partages montés localement.
Voir aussi :
Pour le package Linux (Omnibus) :
Ajoutez ce qui suit à /etc/gitlab/gitlab.rb :
gitlab_rails['backup_upload_connection'] = {
'provider' => 'AWS',
'region' => 'eu-west-1',
# Choose one authentication method
# IAM Profile
'use_iam_profile' => true
# OR AWS Access and Secret key
'aws_access_key_id' => 'AKIAKIAKI',
'aws_secret_access_key' => 'secret123'
}
gitlab_rails['backup_upload_remote_directory'] = 'my.s3.bucket'
# Consider using multipart uploads when file size reaches 100 MB. Enter a number in bytes.
# gitlab_rails['backup_multipart_chunk_size'] = 104857600
Si vous utilisez la méthode d'authentification par profil IAM, assurez-vous que l'instance sur laquelle backup-utility doit être exécuté dispose de la politique suivante (remplacez <backups-bucket> par le nom correct du bucket) :
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::<backups-bucket>/*"
}
]
}
Reconfigurer GitLab pour que les modifications prennent effet
AWS prend en charge ces modes de chiffrement côté serveur :
Utilisez le mode de votre choix avec GitLab. Chaque mode a des méthodes de configuration similaires mais légèrement différentes.
Pour activer SSE-S3, dans les options de stockage de sauvegarde, définissez le champ server_side_encryption sur AES256. Par exemple, dans le package Linux (Omnibus) :
gitlab_rails['backup_upload_storage_options'] = {
'server_side_encryption' => 'AES256'
}
Pour activer SSE-KMS, vous avez besoin de la clé KMS via son Amazon Resource Name (ARN) au format arn:aws:kms:region:acct-id:key/key-id. Sous le paramètre de configuration backup_upload_storage_options, définissez :
server_side_encryption sur aws:kms.server_side_encryption_kms_key_id sur l'ARN de la clé.Par exemple, dans le package Linux (Omnibus) :
gitlab_rails['backup_upload_storage_options'] = {
'server_side_encryption' => 'aws:kms',
'server_side_encryption_kms_key_id' => 'arn:aws:<YOUR KMS KEY ID>:'
}
SSE-C requiert de définir ces options de chiffrement :
backup_encryption : AES256.backup_encryption_key : Clé non encodée de 32 octets (256 bits). Le téléversement échoue si la clé ne fait pas exactement 32 octets.Par exemple, dans le package Linux (Omnibus) :
gitlab_rails['backup_encryption'] = 'AES256'
gitlab_rails['backup_encryption_key'] = '<YOUR 32-BYTE KEY HERE>'
Si la clé contient des caractères binaires et ne peut pas être encodée en UTF-8, spécifiez plutôt la clé avec la variable d'environnement GITLAB_BACKUP_ENCRYPTION_KEY. Par exemple :
gitlab_rails['env'] = { 'GITLAB_BACKUP_ENCRYPTION_KEY' => "\xDE\xAD\xBE\xEF" * 8 }
Cet exemple peut être utilisé pour un bucket à Amsterdam (AMS3) :
Ajoutez ce qui suit à /etc/gitlab/gitlab.rb :
gitlab_rails['backup_upload_connection'] = {
'provider' => 'AWS',
'region' => 'ams3',
'aws_access_key_id' => 'AKIAKIAKI',
'aws_secret_access_key' => 'secret123',
'endpoint' => 'https://ams3.digitaloceanspaces.com'
}
gitlab_rails['backup_upload_remote_directory'] = 'my.s3.bucket'
Reconfigurer GitLab pour que les modifications prennent effet
Si vous voyez un message d'erreur 400 Bad Request lors de l'utilisation de Digital Ocean Spaces, la cause peut être l'utilisation du chiffrement de sauvegarde. Étant donné que Digital Ocean Spaces ne prend pas en charge le chiffrement, supprimez ou commentez la ligne contenant gitlab_rails['backup_encryption'].
Tous les fournisseurs S3 ne sont pas entièrement compatibles avec la bibliothèque Fog. Par exemple, si vous voyez un message d'erreur 411 Length Required après une tentative de téléversement, vous devrez peut-être réduire la valeur de aws_signature_version de la valeur par défaut à 2, en raison de ce problème.
Pour les installations auto-compilées :
Modifiez home/git/gitlab/config/gitlab.yml :
backup:
# snip
upload:
# Fog storage connection settings, see https://fog.github.io/storage/ .
connection:
provider: AWS
region: eu-west-1
aws_access_key_id: AKIAKIAKI
aws_secret_access_key: 'secret123'
# If using an IAM Profile, leave aws_access_key_id & aws_secret_access_key empty
# ie. aws_access_key_id: ''
# use_iam_profile: 'true'
# The remote 'directory' to store your backups. For S3, this would be the bucket name.
remote_directory: 'my.s3.bucket'
# Specifies Amazon S3 storage class to use for backups, this is optional
# storage_class: 'STANDARD'
#
# Turns on AWS Server-Side Encryption with Amazon Customer-Provided Encryption Keys for backups, this is optional
# 'encryption' must be set in order for this to have any effect.
# 'encryption_key' should be set to the 256-bit encryption key for Amazon S3 to use to encrypt or decrypt.
# To avoid storing the key on disk, the key can also be specified via the `GITLAB_BACKUP_ENCRYPTION_KEY` your data.
# encryption: 'AES256'
# encryption_key: '<key>'
#
#
# Turns on AWS Server-Side Encryption with Amazon S3-Managed keys (optional)
# https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html
# For SSE-S3, set 'server_side_encryption' to 'AES256'.
# For SS3-KMS, set 'server_side_encryption' to 'aws:kms'. Set
# 'server_side_encryption_kms_key_id' to the ARN of customer master key.
# storage_options:
# server_side_encryption: 'aws:kms'
# server_side_encryption_kms_key_id: 'arn:aws:kms:YOUR-KEY-ID-HERE'
Redémarrer GitLab pour que les modifications prennent effet
Pour utiliser Google Cloud Storage pour enregistrer des sauvegardes, vous devez d'abord créer une clé d'accès depuis la console Google :
Pour le package Linux (Omnibus) :
Modifiez /etc/gitlab/gitlab.rb :
gitlab_rails['backup_upload_connection'] = {
'provider' => 'Google',
'google_storage_access_key_id' => 'Access Key',
'google_storage_secret_access_key' => 'Secret',
## If you have CNAME buckets (foo.example.com), you might run into SSL issues
## when uploading backups ("hostname foo.example.com.storage.googleapis.com
## does not match the server certificate"). In that case, uncomment the following
## setting. See: https://github.com/fog/fog/issues/2834
#'path_style' => true
}
gitlab_rails['backup_upload_remote_directory'] = 'my.google.bucket'
Reconfigurer GitLab pour que les modifications prennent effet
Pour les installations auto-compilées :
Modifiez home/git/gitlab/config/gitlab.yml :
backup:
upload:
connection:
provider: 'Google'
google_storage_access_key_id: 'Access Key'
google_storage_secret_access_key: 'Secret'
remote_directory: 'my.google.bucket'
Redémarrer GitLab pour que les modifications prennent effet
{{< tabs >}}
{{< tab title="Package Linux (Omnibus)" >}}
Modifiez /etc/gitlab/gitlab.rb :
gitlab_rails['backup_upload_connection'] = {
'provider' => 'AzureRM',
'azure_storage_account_name' => '<AZURE STORAGE ACCOUNT NAME>',
'azure_storage_access_key' => '<AZURE STORAGE ACCESS KEY>',
'azure_storage_domain' => 'blob.core.windows.net', # Optional
}
gitlab_rails['backup_upload_remote_directory'] = '<AZURE BLOB CONTAINER>'
Si vous utilisez une identité gérée, omettez azure_storage_access_key :
gitlab_rails['backup_upload_connection'] = {
'provider' => 'AzureRM',
'azure_storage_account_name' => '<AZURE STORAGE ACCOUNT NAME>',
'azure_storage_domain' => '<AZURE STORAGE DOMAIN>' # Optional
}
gitlab_rails['backup_upload_remote_directory'] = '<AZURE BLOB CONTAINER>'
Reconfigurer GitLab pour que les modifications prennent effet
{{< /tab >}}
{{< tab title="Auto-compilé" >}}
Modifiez home/git/gitlab/config/gitlab.yml :
backup:
upload:
connection:
provider: 'AzureRM'
azure_storage_account_name: '<AZURE STORAGE ACCOUNT NAME>'
azure_storage_access_key: '<AZURE STORAGE ACCESS KEY>'
remote_directory: '<AZURE BLOB CONTAINER>'
Redémarrer GitLab pour que les modifications prennent effet
{{< /tab >}}
{{< /tabs >}}
Pour plus de détails, consultez le tableau des paramètres Azure.
Cette option fonctionne uniquement pour le stockage distant. Si vous souhaitez regrouper vos sauvegardes, vous pouvez passer une variable d'environnement DIRECTORY :
sudo gitlab-backup create DIRECTORY=daily
sudo gitlab-backup create DIRECTORY=weekly
Si vous avez configuré GitLab pour téléverser des sauvegardes vers un stockage distant, vous pouvez utiliser l'option SKIP=remote pour ignorer le téléversement de vos sauvegardes vers le stockage distant.
{{< tabs >}}
{{< tab title="Package Linux (Omnibus)" >}}
sudo gitlab-backup create SKIP=remote
{{< /tab >}}
{{< tab title="Auto-compilé" >}}
sudo -u git -H bundle exec rake gitlab:backup:create SKIP=remote RAILS_ENV=production
{{< /tab >}}
{{< /tabs >}}
Vous pouvez envoyer des sauvegardes vers un partage monté localement (par exemple, NFS, CIFS ou SMB) en utilisant le fournisseur de stockage Fog Local.
Pour ce faire, vous devez définir les clés de configuration suivantes :
backup_upload_connection.local_root : répertoire monté vers lequel les sauvegardes sont copiées.backup_upload_remote_directory : sous-répertoire du répertoire backup_upload_connection.local_root. Il est créé s'il n'existe pas. Si vous souhaitez copier les archives tar à la racine de votre répertoire monté, utilisez ..Lors du montage, le répertoire défini dans la clé local_root doit appartenir à :
git. Donc, monter avec le uid= de l'utilisateur git pour CIFS et SMB.git.Étant donné que les performances du système de fichiers peuvent affecter les performances globales de GitLab, nous ne recommandons pas l'utilisation de systèmes de fichiers basés sur le cloud pour le stockage.
Ne définissez pas les clés de configuration suivantes sur le même chemin :
gitlab_rails['backup_path'] (backup.path pour les installations auto-compilées).gitlab_rails['backup_upload_connection'].local_root (backup.upload.connection.local_root pour les installations auto-compilées).La clé de configuration backup_path définit l'emplacement local du fichier de sauvegarde. La clé de configuration upload est destinée à être utilisée lorsque le fichier de sauvegarde est téléversé vers un serveur distinct, peut-être à des fins d'archivage.
Si ces clés de configuration sont définies sur le même emplacement, la fonctionnalité de téléversement échoue car une sauvegarde existe déjà à l'emplacement de téléversement. Cet échec entraîne la suppression de la sauvegarde par la fonctionnalité de téléversement, car elle suppose qu'il s'agit d'un fichier résiduel restant après l'échec de la tentative de téléversement.
{{< tabs >}}
{{< tab title="Package Linux (Omnibus)" >}}
Modifiez /etc/gitlab/gitlab.rb :
gitlab_rails['backup_upload_connection'] = {
:provider => 'Local',
:local_root => '/mnt/backups'
}
# The directory inside the mounted folder to copy backups to
# Use '.' to store them in the root directory
gitlab_rails['backup_upload_remote_directory'] = 'gitlab_backups'
Reconfigurer GitLab pour que les modifications prennent effet.
{{< /tab >}}
{{< tab title="Auto-compilé" >}}
Modifiez home/git/gitlab/config/gitlab.yml :
backup:
upload:
# Fog storage connection settings, see https://fog.github.io/storage/ .
connection:
provider: Local
local_root: '/mnt/backups'
# The directory inside the mounted folder to copy backups to
# Use '.' to store them in the root directory
remote_directory: 'gitlab_backups'
Redémarrer GitLab pour que les modifications prennent effet.
{{< /tab >}}
{{< /tabs >}}
Les archives de sauvegarde créées par GitLab (1393513186_2014_02_27_gitlab_backup.tar) ont le propriétaire/groupe git/git et des autorisations 0600 par défaut. Cela vise à empêcher les autres utilisateurs système de lire les données GitLab. Si vous avez besoin que les archives de sauvegarde aient des autorisations différentes, vous pouvez utiliser le paramètre archive_permissions.
{{< tabs >}}
{{< tab title="Package Linux (Omnibus)" >}}
Modifiez /etc/gitlab/gitlab.rb :
gitlab_rails['backup_archive_permissions'] = 0644 # Makes the backup archives world-readable
Reconfigurer GitLab pour que les modifications prennent effet.
{{< /tab >}}
{{< tab title="Auto-compilé" >}}
Modifiez /home/git/gitlab/config/gitlab.yml :
backup:
archive_permissions: 0644 # Makes the backup archives world-readable
Redémarrer GitLab pour que les modifications prennent effet.
{{< /tab >}}
{{< /tabs >}}
[!warning] Les tâches cron suivantes ne sauvegardent pas vos fichiers de configuration GitLab ni vos clés hôtes SSH.
Important: N'oubliez pas de sauvegarder également :
Vous pouvez planifier une tâche cron qui sauvegarde vos dépôts et les métadonnées GitLab.
{{< tabs >}}
{{< tab title="Package Linux (Omnibus)" >}}
Modifiez le crontab pour l'utilisateur root :
sudo su -
crontab -e
Ajoutez-y la ligne suivante pour planifier la sauvegarde tous les jours à 2 h :
0 2 * * * /opt/gitlab/bin/gitlab-backup create CRON=1
{{< /tab >}}
{{< tab title="Auto-compilé" >}}
Modifiez le crontab pour l'utilisateur git :
sudo -u git crontab -e
Ajoutez les lignes suivantes en bas :
# Create a full backup of the GitLab repositories and SQL database every day at 2am
0 2 * * * cd /home/git/gitlab && PATH=/usr/local/bin:/usr/bin:/bin bundle exec rake gitlab:backup:create RAILS_ENV=production CRON=1
{{< /tab >}}
{{< /tabs >}}
Le paramètre d'environnement CRON=1 indique au script de sauvegarde de masquer toute la sortie de progression en l'absence d'erreurs. Cela est recommandé pour réduire le spam cron. Lors du dépannage des problèmes de sauvegarde, remplacez cependant CRON=1 par --trace pour une journalisation détaillée.
[!warning] Le processus décrit dans cette section ne fonctionne pas si vous avez utilisé un nom de fichier personnalisé pour vos sauvegardes.
Pour éviter que les sauvegardes régulières n'utilisent tout l'espace disque disponible, vous pouvez définir une durée de vie limitée pour les sauvegardes. La prochaine fois que la tâche de sauvegarde s'exécutera, les sauvegardes plus anciennes que backup_keep_time seront supprimées.
Cette option de configuration ne gère que les fichiers locaux. GitLab ne supprime pas les anciens fichiers stockés dans un stockage objet tiers, car l'utilisateur peut ne pas avoir la permission de lister et de supprimer des fichiers. Il est recommandé de configurer la politique de rétention appropriée pour votre stockage objet.
Voir aussi :
{{< tabs >}}
{{< tab title="Package Linux (Omnibus)" >}}
Modifiez /etc/gitlab/gitlab.rb :
## Limit backup lifetime to 7 days - 604800 seconds
gitlab_rails['backup_keep_time'] = 604800
Reconfigurer GitLab pour que les modifications prennent effet.
{{< /tab >}}
{{< tab title="Auto-compilé" >}}
Modifiez /home/git/gitlab/config/gitlab.yml :
backup:
## Limit backup lifetime to 7 days - 604800 seconds
keep_time: 604800
Redémarrer GitLab pour que les modifications prennent effet.
{{< /tab >}}
{{< /tabs >}}
Ne sauvegardez pas ni ne restaurez GitLab via une connexion PgBouncer. Ces tâches doivent contourner PgBouncer et se connecter directement au nœud de base de données PostgreSQL principal, sans quoi elles provoqueront une interruption de service GitLab.
Lorsque la tâche de sauvegarde ou de restauration GitLab est utilisée avec PgBouncer, le message d'erreur suivant s'affiche :
ActiveRecord::StatementInvalid: PG::UndefinedTable
Chaque fois que la sauvegarde GitLab s'exécute, GitLab commence à générer des erreurs 500 et des erreurs concernant des tables manquantes seront journalisées par PostgreSQL :
ERROR: relation "tablename" does not exist at character 123
Cela se produit parce que la tâche utilise pg_dump, qui définit un chemin de recherche nul et inclut explicitement le schéma dans chaque requête SQL pour corriger la CVE-2018-1058.
Étant donné que les connexions sont réutilisées avec PgBouncer en mode de mise en pool de transactions, PostgreSQL ne parvient pas à rechercher le schéma public par défaut. Par conséquent, cette suppression du chemin de recherche entraîne l'apparition de tables et de colonnes manquantes.
Références techniques :
Il existe deux façons de résoudre ce problème :
{{< history >}}
{{< /history >}}
Par défaut, GitLab utilise la configuration de base de données stockée dans un fichier de configuration (database.yml). Cependant, vous pouvez remplacer les paramètres de base de données pour la tâche de sauvegarde et de restauration en définissant des variables d'environnement préfixées par GITLAB_BACKUP_ :
GITLAB_BACKUP_PGHOSTGITLAB_BACKUP_PGUSERGITLAB_BACKUP_PGPORTGITLAB_BACKUP_PGPASSWORDGITLAB_BACKUP_PGSSLMODEGITLAB_BACKUP_PGSSLKEYGITLAB_BACKUP_PGSSLCERTGITLAB_BACKUP_PGSSLROOTCERTGITLAB_BACKUP_PGSSLCRLGITLAB_BACKUP_PGSSLCOMPRESSIONPar exemple, pour remplacer l'hôte et le port de la base de données pour utiliser 192.168.1.10 et le port 5432 avec le paquet Linux (Omnibus) :
sudo GITLAB_BACKUP_PGHOST=192.168.1.10 GITLAB_BACKUP_PGPORT=5432 /opt/gitlab/bin/gitlab-backup create
Si vous exécutez GitLab sur plusieurs bases de données, vous pouvez remplacer les paramètres de base de données en incluant le nom de la base de données dans la variable d'environnement. Par exemple, si vos bases de données main et ci sont hébergées sur des serveurs de base de données différents, vous devez ajouter leur nom après le préfixe GITLAB_BACKUP_, en laissant les noms PG* tels quels :
sudo GITLAB_BACKUP_MAIN_PGHOST=192.168.1.10 GITLAB_BACKUP_CI_PGHOST=192.168.1.12 /opt/gitlab/bin/gitlab-backup create
Consultez la documentation PostgreSQL pour plus de détails sur ce que font ces paramètres.
gitaly-backup pour la sauvegarde et la restauration des dépôts {#gitaly-backup-for-repository-backup-and-restore}Le binaire gitaly-backup est utilisé par la tâche Rake de sauvegarde pour créer et restaurer des sauvegardes de dépôts depuis Gitaly. gitaly-backup remplace la méthode de sauvegarde précédente qui appelait directement les RPC sur Gitaly depuis GitLab.
La tâche Rake de sauvegarde doit pouvoir trouver cet exécutable. Dans la plupart des cas, vous n'avez pas besoin de modifier le chemin d'accès au binaire, car il devrait fonctionner correctement avec le chemin par défaut /opt/gitlab/embedded/bin/gitaly-backup. Si vous avez une raison spécifique de modifier le chemin, il peut être configuré dans le paquet Linux (Omnibus) :
Ajoutez ce qui suit à /etc/gitlab/gitlab.rb :
gitlab_rails['backup_gitaly_backup_path'] = '/path/to/gitaly-backup'
Reconfigurer GitLab pour que les modifications prennent effet.
Étant donné que chaque déploiement peut avoir des capacités différentes, vous devez d'abord examiner quelles données doivent être sauvegardées pour mieux comprendre si, et comment, vous pouvez les exploiter.
Par exemple, si vous utilisez Amazon RDS, vous pouvez choisir d'utiliser ses fonctionnalités intégrées de sauvegarde et de restauration pour gérer vos données PostgreSQL GitLab, et exclure les données PostgreSQL lors de l'utilisation de la commande de sauvegarde.
Voir aussi :
Dans les cas suivants, envisagez d'utiliser le transfert de données du système de fichiers ou des instantanés dans le cadre de votre stratégie de sauvegarde :
[!warning] Gitaly Cluster (Praefect) ne prend pas en charge les sauvegardes par instantané.
Lors de l'utilisation du transfert de données du système de fichiers ou des instantanés :
sudo gitlab-ctl stop) avant d'effectuer un transfert de système de fichiers (avec rsync, par exemple) ou de prendre un instantané pour vous assurer que toutes les données en mémoire sont écrites sur le disque. GitLab est composé de plusieurs sous-systèmes (Gitaly, base de données, stockage de fichiers) qui disposent de leurs propres tampons, files d'attente et couches de stockage. Les transactions GitLab peuvent s'étendre sur ces sous-systèmes, ce qui entraîne des parties d'une transaction prenant des chemins différents vers le disque. Sur les systèmes en cours d'exécution, les transferts de système de fichiers et les instantanés ne parviennent pas à capturer les parties de la transaction encore en mémoire.Exemple : Amazon Elastic Block Store (EBS)
/var/opt/gitlab.Exemple : Logical Volume Manager (LVM) snapshots + rsync
/var/opt/gitlab./var/opt/gitlab avec rsync ne serait pas fiable, car trop de fichiers changeraient pendant l'exécution de rsync./var/opt/gitlab avec rsync, nous créons un instantané LVM temporaire, que nous montons en tant que système de fichiers en lecture seule à /mnt/gitlab_backup.Si vous exécutez GitLab sur un serveur virtualisé, vous pouvez également créer des instantanés VM de l'ensemble du serveur GitLab. Il n'est cependant pas rare qu'un instantané VM vous oblige à éteindre le serveur, ce qui limite l'utilisation pratique de cette solution.
Tout d'abord, assurez-vous de sauvegarder les données GitLab existantes en ignorant les dépôts :
{{< tabs >}}
{{< tab title="Package Linux (Omnibus)" >}}
sudo gitlab-backup create SKIP=repositories
{{< /tab >}}
{{< tab title="Auto-compilé" >}}
sudo -u git -H bundle exec rake gitlab:backup:create SKIP=repositories RAILS_ENV=production
{{< /tab >}}
{{< /tabs >}}
Pour sauvegarder manuellement les données du dépôt Git sur le disque, il existe plusieurs stratégies possibles :
Les dépôts Git doivent être copiés de manière cohérente. Si les dépôts sont copiés lors d'opérations d'écriture simultanées, des incohérences ou des problèmes de corruption peuvent survenir. Cela peut entraîner une corruption du dépôt, des commits manquants ou des données de sauvegarde incomplètes.
Pour empêcher les écritures dans les données du dépôt Git, il existe deux approches possibles :
Utilisez le mode maintenance pour placer GitLab en état de lecture seule.
Créez un temps d'arrêt explicite en arrêtant tous les services Gitaly avant de sauvegarder les dépôts :
sudo gitlab-ctl stop gitaly
# execute git data copy step
sudo gitlab-ctl start gitaly
Vous pouvez copier les données du dépôt Git en utilisant n'importe quelle méthode, à condition que les écritures soient empêchées sur les données en cours de copie (pour éviter les incohérences et les problèmes de corruption). Par ordre de préférence et de sécurité, les méthodes recommandées sont :
Utilisez rsync avec les options archive-mode, delete et checksum, par exemple :
rsync -aR --delete --checksum source destination # be extra safe with the order as it will delete existing data if inverted
Utilisez un tube tar pour copier l'intégralité du répertoire du dépôt vers un autre serveur ou emplacement.
Utilisez sftp, scp, cp, ou toute autre méthode de copie.
Une façon de sauvegarder les dépôts sans nécessiter de temps d'arrêt à l'échelle de l'instance consiste à marquer les projets par programmation comme étant en lecture seule lors de la copie des données sous-jacentes.
Voici quelques inconvénients possibles :
Il existe un script expérimental qui tente d'automatiser ce processus dans le projet Runbooks de l'équipe Geo.