La sauvegarde de vos dépôts GitLab hébergés sur un VPS (Virtual Private Server) est une étape cruciale pour éviter toute perte de données, qu’il s’agisse de code source, de configurations ou de métadonnées. Dans un environnement où la continuité de service et la sécurité des données sont primordiales, une stratégie de sauvegarde robuste permet de se prémunir contre les pannes matérielles, les erreurs humaines ou les cyberattaques. Contrairement aux solutions cloud comme GitLab.com, l’auto-hébergement sur un VPS offre une flexibilité accrue, mais exige une gestion proactive des sauvegardes.
Dans cet article, nous explorons les différentes méthodes pour sauvegarder efficacement un GitLab auto-hébergé sur un VPS. Nous aborderons les outils natifs, les solutions automatisées, les bonnes pratiques à adopter, ainsi que les pièges à éviter. Que vous soyez un développeur indépendant, une startup ou une entreprise, ces recommandations vous aideront à mettre en place une stratégie de sauvegarde fiable et adaptée à vos besoins.
Pourquoi sauvegarder GitLab sur un VPS est indispensable
Les risques liés à l’absence de sauvegarde
Un VPS, bien que puissant et personnalisable, n’est pas à l’abri des défaillances. Les pannes matérielles, les erreurs de configuration ou les attaques par ransomware peuvent entraîner la perte définitive de vos dépôts. Contrairement à une solution cloud où les sauvegardes sont souvent gérées par le fournisseur, un VPS nécessite une intervention manuelle ou automatisée pour garantir la pérennité des données.
De plus, GitLab stocke non seulement le code source, mais aussi des informations sensibles comme les clés SSH, les variables d’environnement ou les configurations CI/CD. Une sauvegarde incomplète peut compromettre la sécurité de votre infrastructure ou entraîner des temps d’arrêt prolongés en cas de restauration.
Les avantages d’une sauvegarde régulière
Une stratégie de sauvegarde bien conçue offre plusieurs bénéfices :
- Protection contre les pertes de données : En cas de corruption ou de suppression accidentelle, vous pouvez restaurer vos dépôts en quelques minutes.
- Conformité et audit : Certaines réglementations (comme le RGPD) exigent la conservation des données. Une sauvegarde régulière facilite la traçabilité.
- Migration simplifiée : Si vous souhaitez migrer vers un autre VPS ou une solution cloud, une sauvegarde complète accélère le processus.
- Réduction des temps d’arrêt : Une restauration rapide limite l’impact sur vos équipes et vos utilisateurs.
Les méthodes de sauvegarde pour GitLab sur VPS
1. Utiliser l’outil natif de sauvegarde de GitLab
GitLab propose une commande dédiée pour créer des sauvegardes complètes de votre instance. Cette méthode est la plus simple et la plus fiable pour les utilisateurs auto-hébergés.
Étapes pour créer une sauvegarde avec GitLab
Pour générer une sauvegarde, exécutez la commande suivante en tant qu’utilisateur git (ou l’utilisateur sous lequel GitLab est installé) :
sudo gitlab-backup createCette commande génère un fichier de sauvegarde dans le répertoire /var/opt/gitlab/backups/ (par défaut). Le fichier est nommé selon le format 1712345678_2024_04_05_15.12.34_gitlab_backup.tar, où le timestamp correspond à la date de création.
Personnalisation de la sauvegarde
Vous pouvez inclure ou exclure certains éléments dans la sauvegarde :
- Sauvegarder uniquement les dépôts :
sudo gitlab-backup create SKIP=registry,uploads,builds,artifacts,pages,lfs,ci_secure_files - Sauvegarder uniquement les configurations :
sudo gitlab-backup create SKIP=repositories,uploads,builds,artifacts,pages,lfs,ci_secure_files
Restauration d’une sauvegarde
Pour restaurer une sauvegarde, utilisez la commande suivante :
sudo gitlab-backup restore BACKUP=1712345678_2024_04_05_15.12.34Attention : La restauration doit être effectuée sur une instance GitLab de la même version. De plus, arrêtez les services GitLab avant de restaurer (sudo gitlab-ctl stop unicorn et sudo gitlab-ctl stop sidekiq).
2. Sauvegarder manuellement les fichiers critiques
En complément de l’outil natif, il est recommandé de sauvegarder manuellement les fichiers de configuration et les données sensibles.
Fichiers à sauvegarder
- Fichiers de configuration :
/etc/gitlab/gitlab.rb(configuration principale)/etc/gitlab/gitlab-secrets.json(clés secrètes)
- Dépôts Git :
/var/opt/gitlab/git-data/repositories/
- Bases de données :
- PostgreSQL :
sudo -u gitlab-psql /opt/gitlab/embedded/bin/pg_dumpall -U gitlab-psql > gitlab_db_backup.sql - Redis :
sudo cp /var/opt/gitlab/redis/dump.rdb /chemin/de/sauvegarde/
- PostgreSQL :
- Fichiers uploadés :
/var/opt/gitlab/gitlab-rails/uploads/
Automatisation avec des scripts
Pour éviter les erreurs humaines, créez un script Bash pour regrouper ces sauvegardes. Exemple :
#!/bin/bash DATE=$(date +%Y-%m-%d_%H-%M-%S) BACKUP_DIR="/backups/gitlab/$DATE" mkdir -p $BACKUP_DIR Sauvegarde des fichiers de configuration
cp /etc/gitlab/gitlab.rb $BACKUP_DIR/ cp /etc/gitlab/gitlab-secrets.json $BACKUP_DIR/ Sauvegarde des dépôts
tar -czf $BACKUP_DIR/repositories.tar.gz /var/opt/gitlab/git-data/repositories/ Sauvegarde de la base de données
sudo -u gitlab-psql /opt/gitlab/embedded/bin/pg_dumpall -U gitlab-psql > $BACKUP_DIR/gitlab_db.sql Compression et nettoyage
tar -czf /backups/gitlab_backup_$DATE.tar.gz $BACKUP_DIR rm -rf $BACKUP_DIR 3. Utiliser des outils de sauvegarde externes
Pour une sécurité maximale, combinez les méthodes natives avec des outils de sauvegarde externes comme rsync, BorgBackup ou Duplicati.
Sauvegarde avec rsync
rsync permet de synchroniser vos sauvegardes vers un autre serveur ou un stockage cloud. Exemple :
rsync -avz --delete /backups/gitlab/ user@remote-server:/backups/gitlab/Sauvegarde avec BorgBackup
BorgBackup est un outil de sauvegarde dédupliqué et chiffré. Installation :
sudo apt install borgbackupCréation d’une sauvegarde :
borg init --encryption=repokey /chemin/vers/le/repository borg create --stats /chemin/vers/le/repository::gitlab-{now} /var/opt/gitlabSauvegarde avec Duplicati
Duplicati est une solution open-source avec interface graphique, idéale pour les sauvegardes automatisées vers des services cloud (Backblaze, AWS S3, etc.).
Automatiser les sauvegardes pour une sécurité optimale
Planifier des sauvegardes avec Cron
Pour éviter les oublis, utilisez Cron pour planifier des sauvegardes automatiques. Exemple de tâche quotidienne à 2h du matin :
0 2 /usr/bin/gitlab-backup create SKIP=registry,uploads,builds,artifacts,pages,lfs,ci_secure_filesGérer les rétentions de sauvegardes
Une stratégie de rétention permet de limiter l’espace utilisé par les sauvegardes anciennes. Par exemple, conservez uniquement les 7 dernières sauvegardes :
find /backups/gitlab/ -name "gitlab_backup_.tar.gz" -mtime +7 -deleteSurveillance et alertes
Mettez en place un système de surveillance pour vérifier que les sauvegardes s’exécutent correctement. Vous pouvez utiliser :
- Nagios ou Zabbix pour surveiller les logs.
- Un script de vérification qui envoie une alerte en cas d’échec :
#!/bin/bash if ! sudo gitlab-backup create; then echo "Échec de la sauvegarde GitLab !" | mail -s "Alerte Sauvegarde" admin@example.com fi
Bonnes pratiques pour une sauvegarde GitLab efficace
1. Tester régulièrement les restaurations
Une sauvegarde n’est utile que si elle peut être restaurée. Planifiez des tests de restauration mensuels pour vérifier l’intégrité des données. Exemple :
sudo gitlab-ctl stop unicorn sudo gitlab-ctl stop sidekiq sudo gitlab-backup restore BACKUP=1712345678_2024_04_05_15.12.34 sudo gitlab-ctl reconfigure sudo gitlab-ctl restart 2. Chiffrer les sauvegardes sensibles
Si vos sauvegardes contiennent des données sensibles (clés secrètes, variables d’environnement), chiffrez-les avec GPG ou OpenSSL :
gpg --encrypt --recipient "votre@email.com" gitlab_backup.tar.gz3. Stocker les sauvegardes hors site
Ne conservez pas vos sauvegardes uniquement sur le VPS. Utilisez :
- Un second VPS dans une autre région.
- Un stockage cloud (AWS S3, Backblaze, OVH Object Storage).
- Un disque dur externe stocké dans un lieu sécurisé.
4. Documenter votre stratégie de sauvegarde
Documentez les étapes de sauvegarde et de restauration dans un fichier README.md ou un wiki interne. Incluez :
- La fréquence des sauvegardes.
- Les commandes à exécuter en cas de restauration.
- Les contacts en cas de problème.
Erreurs courantes à éviter
1. Négliger la sauvegarde des fichiers de configuration
Sans gitlab.rb et gitlab-secrets.json, la restauration d’une instance GitLab est impossible. Ces fichiers contiennent des paramètres critiques comme les clés de chiffrement ou les URLs.
2. Sauvegarder uniquement les dépôts
Une sauvegarde incomplète (sans base de données ou fichiers uploadés) peut rendre la restauration partielle ou impossible. Utilisez toujours l’outil natif gitlab-backup pour une couverture complète.
3. Ignorer les dépendances logicielles
Si vous restaurez une sauvegarde sur une nouvelle instance, assurez-vous que la version de GitLab est identique. Une restauration entre des versions différentes peut échouer.
4. Ne pas surveiller les échecs de sauvegarde
Un espace disque insuffisant ou une erreur de permissions peut bloquer une sauvegarde sans que vous le sachiez. Configurez des alertes pour être informé immédiatement en cas d’échec.
Conclusion : Une stratégie de sauvegarde GitLab sur VPS infaillible
Sauvegarder un GitLab auto-hébergé sur un VPS est une étape incontournable pour garantir la sécurité et la disponibilité de vos données. En combinant l’outil natif de GitLab, des sauvegardes manuelles des fichiers critiques et des outils externes comme rsync ou BorgBackup, vous mettez en place une stratégie robuste et adaptée à vos besoins.
N’oubliez pas d’automatiser les sauvegardes avec Cron, de tester régulièrement les restaurations et de stocker vos sauvegardes hors site. En suivant les bonnes pratiques évoquées dans cet article, vous réduirez considérablement les risques de perte de données et serez prêt à faire face à toute situation critique.
Enfin, rappelez-vous que la sauvegarde n’est qu’une partie de la solution. Une documentation claire et des tests réguliers sont tout aussi importants pour assurer la pérennité de votre infrastructure GitLab.