Créer une sauvegarde (Backup) de GitLab : Sécuriser vos données
Pourquoi la sauvegarde est-elle vitale ?
En informatique, il existe une règle d'or : une donnée qui n'est pas sauvegardée est une donnée qui n'existe pas. Que ce soit à cause d'une erreur humaine, d'une mise à jour qui tourne mal ou d'une panne matérielle, perdre l'intégralité de vos dépôts, de vos tickets et de votre configuration peut être une catastrophe pour votre équipe.
Heureusement, GitLab intègre un outil puissant qui permet de réaliser une sauvegarde complète de GitLab en une seule commande. Cette procédure regroupe la base de données, les dépôts Git et tous les fichiers attachés dans une seule archive compressée (.tar).
Lancer une sauvegarde manuelle du serveur
Pour effectuer cette opération, vous devez avoir un accès administrateur à votre serveur et utiliser la ligne de commande.
Créer l'archive complète
Utilisez l'outil intégré pour lancer le processus de sauvegarde globale du système :
sudo gitlab-backup createExclure des répertoires spécifiques
Sur de très gros serveurs, la sauvegarde peut prendre beaucoup de temps et d'espace disque. Vous pourriez vouloir ignorer certains éléments lourds comme les fichiers envoyés par les utilisateurs (uploads) ou la base de données.
Utilisez la variable d'environnement SKIP pour filtrer les données à sauvegarder :
sudo gitlab-backup create SKIP=db,uploadsRésultat attendu :
Dumping database ... [DONE]
Dumping repositories ...
* group/project-alpha ... [DONE]
* group/project-beta ... [DONE]
Dumping uploads ... [DONE]
Dumping builds ... [DONE]
Dumping artifacts ... [DONE]
Dumping pages ... [DONE]
Creating backup archive: 1713532481_2026_04_19_17.5.2_gitlab_backup.tar ... [DONE]Où trouver votre fichier de sauvegarde ?
Une fois l'opération terminée, GitLab ne garde pas le fichier dans votre dossier actuel. Il le déplace automatiquement dans un répertoire de sauvegarde sécurisé.
Localiser l'archive .tar
Rendez-vous dans le dossier /var/opt/gitlab/backups pour voir vos fichiers :
cd /var/opt/gitlab/backups
ls -lAttention : Compatibilité des versions
Une sauvegarde GitLab ne peut être restaurée que sur une instance exécutant exactement la même version de GitLab (ex: de 17.5.2 vers 17.5.2). Notez toujours votre version actuelle lors de l'archivage.
Sécurité des fichiers de configuration
Le fichier de sauvegarde ne contient pas les fichiers de configuration critiques (gitlab.rb et gitlab-secrets.json). Vous devez impérativement sauvegarder manuellement ces fichiers sensibles vers un endroit sûr, sinon votre restauration sera impossible.
Conclusion
Vous savez désormais comment sécuriser vos données GitLab contre les imprévus. Posséder une archive récente est la base d'un bon plan de reprise d'activité (PRA).
Savoir créer une archive est une chose, mais savoir l'utiliser en cas de crise en est une autre. Dans le prochain chapitre, nous allons voir comment restaurer une sauvegarde GitLab pour remettre votre serveur sur pied en quelques minutes.
Espace commentaire
Écrire un commentaire
Rejoignez la discussion
Vous devez être connecté pour poster un message.
25 commentaires
Dernier conseil : testez toujours votre restauration sur une machine de dev. Un backup que tu n'as jamais restauré, c'est un backup qui ne fonctionne pas.
Essaie de dumper la base séparément avec
pg_dumpsi le backup global est trop lourd, mais c'est du bricolage.Mon backup échoue avec une erreur de timeout sur la base de données. Le serveur est trop lent.
Utilise cette directive dans
gitlab.rbpour garder seulement les 7 derniers jours :Le dossier
/var/opt/gitlab/backupsdevient plein à craquer. Comment purger les vieux fichiers ?Configure le
backup_upload_connectiondans legitlab.rb. C'est fait pour ça.Quelqu'un sait comment envoyer le backup sur S3 automatiquement après la création ?
J'ai supprimé mes fichiers par erreur, merci pour le tuto, ça m'a sauvé la mise.
Oui, l'outil gère ça nativement, t'inquiète pas pour la cohérence des données.
Est-ce que
gitlab-backupgère le verrouillage des tables pendant le dump ? Pas envie d'avoir une base corrompue.Regarde les logs :
/var/log/gitlab/gitlab-rails/backup_json.log. Tu verras quel repo fait planter le dump.Le processus de sauvegarde bloque sur
Dumping repositories. Ça tourne dans le vide depuis 1 heure.Pas d'outil natif, mais tu peux faire un
tar -tfsur le fichier pour voir s'il est corrompu.Est-ce qu'il y a un moyen de vérifier l'intégrité de l'archive
.tarjuste après le backup ?Bah oui, c'est écrit dans l'article : la version doit être identique. La structure de la DB change à chaque release.
J'ai essayé de restaurer un backup sur une version plus récente, ça a tout pété. Plus jamais.
Édite ton
/etc/gitlab/gitlab.rb. Modifie la ligne suivante pour pointer vers un autre volume :Pense à faire un
gitlab-ctl reconfigureaprès.Le fichier généré est énorme, plus de 50 Go. Le disque sature pendant la compression. On peut changer le répertoire de destination ?
Ajoute simplement cette ligne dans ta crontab root :
Le flag
CRON=1désactive les prompts interactifs.Comment automatiser ça avec un cron job ? J'ai peur d'oublier de le faire manuellement chaque semaine.
Merci pour l'astuce sur le
gitlab-secrets.json, j'avais complètement oublié ce fichier critique à ne jamais perdre.T'es probablement en train de mal passer la variable. Essaie comme ça :
J'ai testé la commande
sudo gitlab-backup create SKIP=db,uploadsmais ça me sort une erreur de syntaxe sur mon shell. Je suis sur Debian.Vérifie les droits sur le répertoire
/var/opt/gitlab/backups. Le user git doit avoir les droits en écriture dessus.Super guide, simple et efficace. Par contre, j'ai une erreur
Permission deniedquand je lancesudo gitlab-backup create. Une idée ?