Restaurer GitLab - Procédure de Secours Technique

Restaurer une sauvegarde sur GitLab : La procédure de secours

Pourquoi et quand restaurer une sauvegarde ?

Posséder une sauvegarde est inutile si vous ne savez pas comment l'injecter pour remettre votre serveur en ligne. Le processus de restauration GitLab est une opération délicate qui remplace les données actuelles de votre instance par celles contenues dans votre archive .tar.

C'est l'étape ultime après un crash majeur ou lors d'une migration pour restaurer une sauvegarde GitLab. Contrairement à la sauvegarde qui peut se faire à chaud, la restauration nécessite de stopper certains services pour s'assurer que les données ne sont pas modifiées pendant que GitLab les réinstalle.

Pré-requis indispensables avant la restauration

Avant de taper la première commande, vous devez vous assurer de deux points critiques pour la réussite de votre plan de reprise d'activité :

Votre instance GitLab doit avoir exactement la même version que celle qui a créé la sauvegarde (ex: 17.10.2).
Vous devez avoir replacé vos fichiers gitlab.rb et gitlab-secrets.json dans le dossier /etc/gitlab/.

Le processus de restauration étape par étape

Pour effectuer cette opération, connectez-vous d'abord à votre serveur GitLab via SSH (Secure Shell).

Localiser le fichier de sauvegarde

Assurez-vous que votre archive se trouve bien dans le répertoire par défaut /var/opt/gitlab/backups et vérifiez son nom pour extraire le timestamp de sauvegarde.

cd /var/opt/gitlab/backups
ls -l

Résultat :

-rw------- 1 git git 123456789 Apr 20 10:00 1713532481_2026_04_20_17.10.2_gitlab_backup.tar

Arrêt des services de données

Stoppez les processus Puma (le serveur web) et Sidekiq (le gestionnaire de tâches) avant de lancer la récupération des données :

sudo gitlab-ctl stop puma
sudo gitlab-ctl stop sidekiq

Résultat :

ok: down: puma: 0s, normally up
ok: down: sidekiq: 0s, normally up

Lancement de la restauration

Exécutez la commande de restauration en utilisant uniquement le début du nom de fichier (le timestamp) :

sudo gitlab-backup restore BACKUP=1713532481

Vérification d'intégrité

Il est crucial de réaliser une vérification d'intégrité du système après une restauration :

sudo gitlab-rake gitlab:check

Résultat :

Unpacking backup ... [DONE]
Restoring database ... 
Be careful: This will replace your current database! (yes/no)? yes
[...]
Restoring repositories ...
 * group/project-alpha ... [DONE]
Restoring uploads ... [DONE]
Restore completed!

Vérification essentielle

Cette commande s'assure que la base de données et les dépôts Git communiquent correctement après la réinstallation.

Finalisation et redémarrage du serveur

Une fois l'archive extraite, relancez tous les composants pour remettre le serveur en production :

sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

Vérification d'intégrité et nettoyage

Il est crucial de réaliser une vérification d'intégrité du système après une restauration, notamment en utilisant le flag de nettoyage :

sudo gitlab-rake gitlab:check SANITIZE=true

Résultat :

Checking GitLab subcomponents ...
Database: ... OK
Gitaly: ... OK
Sanitizing database ... [DONE]
GitLab check is completed.

Pourquoi utiliser SANITIZE ?

L'option SANITIZE=true supprime les adresses e-mail réelles et les jetons de sécurité de la base restaurée pour éviter tout envoi intempestif de mails si vous restaurez sur un serveur de test.

Conclusion

Vous maîtrisez désormais le cycle complet de survie : de la sauvegarde à la restauration. C'est la base de la fiabilité d'un administrateur système GitLab.

Maintenant que vos données sont en sécurité, nous allons voir comment alimenter votre serveur en important des dépôts existants depuis d'autres plateformes.

Chapitre précédent