doc-locale/fr-fr/administration/operations/moving_repositories.md
{{< details >}}
{{< /details >}}
Déplacer tous les dépôts gérés par GitLab vers un autre système de fichiers ou un autre serveur.
Utiliser l'API GitLab pour déplacer des dépôts Git :
Les dépôts GitLab peuvent être associés à des projets, des groupes et des extraits de code. Chacun de ces types dispose d'une API distincte pour déplacer les dépôts. Pour déplacer tous les dépôts d'une instance GitLab, chaque type de dépôt doit être déplacé pour chaque stockage.
Chaque dépôt est mis en lecture seule pendant la durée du déplacement et n'est pas accessible en écriture tant que le déplacement n'est pas terminé.
Pour déplacer des dépôts :
<original_storage_name> et <cluster_storage_name>.Vous pouvez déplacer tous les projets ou des projets individuels.
Pour déplacer tous les projets à l'aide de l'API :
Planifiez des déplacements de stockage de dépôt pour tous les projets sur un fragment de stockage à l'aide de l'API. Par exemple :
curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" \
--header "Content-Type: application/json" \
--data '{"source_storage_name":"<original_storage_name>","destination_storage_name":"<cluster_storage_name>"}' \
"https://gitlab.example.com/api/v4/project_repository_storage_moves"
Interrogez les déplacements de dépôt les plus récents à l'aide de l'API. La réponse indique soit :
state est finished.Une fois les déplacements terminés, utilisez l'API pour interroger les projets et confirmer que tous les projets ont été déplacés. Aucun des projets ne doit être retourné avec le champ repository_storage défini sur l'ancien stockage. Par exemple :
curl --header "PRIVATE-TOKEN: <your_access_token>" --header "Content-Type: application/json" \
"https://gitlab.example.com/api/v4/projects?repository_storage=<original_storage_name>"
Vous pouvez également utiliser la console Rails pour confirmer que tous les projets ont été déplacés :
ProjectRepository.for_repository_storage('<original_storage_name>')
Répétez l'opération pour chaque stockage si nécessaire.
Si vous ne souhaitez pas déplacer tous les projets, suivez les instructions pour déplacer des projets individuels.
Vous pouvez déplacer tous les extraits de code ou des extraits de code individuels.
Pour déplacer tous les extraits de code à l'aide de l'API :
Planifiez des déplacements de stockage de dépôt pour tous les extraits de code sur un fragment de stockage. Par exemple :
curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" \
--header "Content-Type: application/json" \
--data '{"source_storage_name":"<original_storage_name>","destination_storage_name":"<cluster_storage_name>"}' \
"https://gitlab.example.com/api/v4/snippet_repository_storage_moves"
Interrogez les déplacements de dépôt les plus récents. La réponse indique soit :
state est finished.Une fois les déplacements terminés, utilisez la console Rails pour confirmer que tous les extraits de code ont été déplacés :
SnippetRepository.for_repository_storage('<original_storage_name>')
La commande ne doit pas retourner d'extraits de code pour le stockage d'origine.
Répétez l'opération pour chaque stockage si nécessaire.
Si vous ne souhaitez pas déplacer tous les extraits de code, suivez les instructions pour les extraits de code individuels.
{{< details >}}
{{< /details >}}
Vous pouvez déplacer tous les groupes ou des groupes individuels.
Pour déplacer tous les groupes à l'aide de l'API :
Planifiez des déplacements de stockage de dépôt pour tous les groupes sur un fragment de stockage. Par exemple :
curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" \
--header "Content-Type: application/json" \
--data '{"source_storage_name":"<original_storage_name>","destination_storage_name":"<cluster_storage_name>"}' \
"https://gitlab.example.com/api/v4/group_repository_storage_moves"
Interrogez les déplacements de dépôt les plus récents. La réponse indique soit :
state est finished.Une fois les déplacements terminés, utilisez la console Rails pour confirmer que tous les groupes ont été déplacés :
GroupWikiRepository.for_repository_storage('<original_storage_name>')
La commande ne doit pas retourner de groupes pour le stockage d'origine.
Répétez l'opération pour chaque stockage si nécessaire.
Si vous ne souhaitez pas déplacer tous les groupes, suivez les instructions pour les groupes individuels.
Vous ne pouvez pas déplacer des données à l'aide de l'API si vous migrez vers un nouvel environnement GitLab. Par exemple :
Dans ce cas, il existe des moyens de copier tous vos dépôts de /var/opt/gitlab/git-data/repositories vers /mnt/gitlab/repositories selon le scénario :
[!warning] Chacune des approches peut ou va écraser des données dans le répertoire cible
/mnt/gitlab/repositories. Vous devez spécifier correctement la source et la cible.
Pour les cibles Gitaly ou Gitaly Cluster (Praefect), vous devez utiliser la fonctionnalité de sauvegarde et de restauration de GitLab. Les dépôts Git sont accessibles, gérés et stockés sur les serveurs GitLab par Gitaly en tant que base de données. Vous pouvez subir une perte de données si vous accédez directement aux fichiers Gitaly et les copiez à l'aide d'outils tels que rsync. Vous pouvez :
Vous devez utiliser la méthode de sauvegarde et de restauration pour les cibles Gitaly Cluster (Praefect).
tar {#use-tar}Vous pouvez utiliser un tube tar pour déplacer des dépôts si :
/mnt/gitlab/repositories est vide.Cette méthode a une faible surcharge et tar est généralement préinstallé sur votre système. Cependant, vous ne pouvez pas reprendre un tube tar interrompu. Si tar est interrompu, vous devez vider le répertoire cible et copier à nouveau toutes les données.
Pour voir la progression du processus tar, remplacez -xf par -xvf.
sudo -u git sh -c 'tar -C /var/opt/gitlab/git-data/repositories -cf - -- . |\
tar -C /mnt/gitlab/repositories -xf -'
tar vers un autre serveur {#use-a-tar-pipe-to-another-server}Pour les cibles Gitaly, vous pouvez utiliser un tube tar pour copier des données vers un autre serveur. Si votre utilisateur git dispose d'un accès SSH au nouveau serveur en tant que git@<newserver>, vous pouvez transmettre les données via SSH.
Si vous souhaitez compresser les données avant qu'elles ne transitent par le réseau (ce qui augmente l'utilisation du CPU), vous pouvez remplacer ssh par ssh -C.
sudo -u git sh -c 'tar -C /var/opt/gitlab/git-data/repositories -cf - -- . |\
ssh git@newserver tar -C /mnt/gitlab/repositories -xf -'
rsync {#use-rsync}Vous pouvez utiliser rsync pour déplacer des dépôts si :
tar est inefficace.[!warning] Vous devez utiliser l'option
--deletelors de l'utilisation dersync. L'utilisation dersyncsans--deletepeut entraîner une perte de données et une corruption du dépôt. Pour plus d'informations, consultez le ticket 270422.
Le /. dans la commande suivante est très important, sinon vous pouvez obtenir une structure de répertoire incorrecte dans le répertoire cible. Si vous souhaitez voir la progression, remplacez -a par -av.
sudo -u git sh -c 'rsync -a --delete /var/opt/gitlab/git-data/repositories/. \
/mnt/gitlab/repositories'
rsync vers un autre serveur {#use-rsync-to-another-server}Pour les cibles Gitaly, vous pouvez envoyer les dépôts sur le réseau avec rsync si l'utilisateur git sur votre système source dispose d'un accès SSH au serveur cible.
sudo -u git sh -c 'rsync -a --delete /var/opt/gitlab/git-data/repositories/. \
git@newserver:/mnt/gitlab/repositories'