Les organisations utilisant une instance GitLab autogérée s'appuient généralement sur elle pour conserver leur code source, leur gestion de projet et outillage opérationnel. Il est essentiel d'avoir des sauvegardes fonctionnelles afin que vos données soient protégées en cas de panne matérielle, d'échec de la mise à jour du serveur ou de compromission malveillante.
GitLab dispose d'un composant de sauvegarde intégré qui peut créer une archive complète des données de votre installation. L'archive peut être restaurée sur un nouveau serveur exécutant la même version de GitLab.
Voici comment configurer des sauvegardes sur votre système de fichiers local ou un compartiment Amazon S3. Ces étapes sont destinées à être utilisées avec les éditions omnibus de GitLab. Vous devrez modifier les commandes GitLab CLI en les préfixant avec bundle exec rake si votre instance a été construite à partir des sources.
Faire un On -Demande de sauvegarde
Le moyen le plus simple de créer une sauvegarde consiste à utiliser la commande de création à la demande. Exécutez la commande suivante dans votre shell :
sudo gitlab-backup create
Cela fonctionne sur GitLab 12.2 et versions ultérieures. Les versions plus anciennes devraient plutôt utiliser une version alternative :
sudo gitlab-rake gitlab:backup:create Advertisement
La sauvegarde sera enregistrée en tant qu'archive tar dans le répertoire défini par votre fichier de configuration GitLab. Les installations Omnibus utilisent par défaut /var/opt/gitlab/backups. Chaque archive de sauvegarde est nommée avec son horodatage de création et sa version de GitLab.
Qu'est-ce qui est inclus dans une sauvegarde ?
L'utilitaire de sauvegarde intégré de GitLab exporte les données créées par les utilisateurs sur votre instance GitLab. Cela inclut tout ce qui se trouve dans la base de données GitLab et vos dépôts Git sur disque.
La restauration de la sauvegarde rétablira vos projets, groupes, utilisateurs, problèmes, pièces jointes téléchargées et journaux de travaux CI/CD. La sauvegarde couvre également les sites Web GitLab Pages et les images Docker téléchargées dans le registre de conteneurs intégré.
Les packages ajoutés aux registres de packages GitLab ne sont pas pris en charge. Vous devez configurer votre installation pour enregistrer les packages sur un fournisseur de stockage d'objets externe si vous avez besoin qu'ils soient récupérables sans reconstruction manuelle.
Création d'un programme de sauvegarde
Il n'y a pas de mécanisme intégré pour définir une planification de sauvegarde automatisée. Vous devez configurer votre propre tâche cron pour exécuter la commande de sauvegarde indiquée ci-dessus.
Exécutez sudo crontab -e pour ouvrir le crontab root, puis ajoutez le contenu suivant au fichier :
0 21 * * * /opt/gitlab/bin/gitlab-backup create CRON=1 Publicité
Enregistrez et fermez le fichier pour appliquer votre changement de crontab. Cet exemple créera une nouvelle sauvegarde à 21 heures chaque jour. La définition de la variable d'environnement CRON indique à GitLab de masquer l'affichage de la progression de la sauvegarde afin que vous ne receviez pas d'e-mails cron redondants avec la sortie de la tâche.
L'utilisation de cette tâche telle quelle conservera chaque sauvegarde indéfiniment jusqu'à ce que vous les nettoyiez manuellement. Cela peut rapidement consommer beaucoup d'espace de stockage si vous exécutez une instance GitLab active contenant des projets volumineux.
Une clé de configuration facultative vous permet de supprimer les anciennes archives dans le cadre du script de création de sauvegarde. Ouvrez votre fichier de configuration GitLab dans /etc/gitlab/gitlab.rb. Recherchez backup_keep_time, décommentez la ligne et définissez le nombre de secondes pendant lesquelles vous souhaitez conserver chaque sauvegarde.
gitlab_rails['backup_keep_time'] = 432000
Ici, les sauvegardes sont conservées pendant cinq jours. GitLab supprimera toutes les archives éligibles dans le répertoire de sauvegarde chaque fois que la commande de création de sauvegarde est exécutée.
Vous devez reconfigurer GitLab chaque fois que le fichier de configuration change. Exécutez sudo gitlab-ctl reconfigure pour appliquer votre nouveau paramètre.
Exclusion des types de données
Parfois, vous souhaiterez peut-être exécuter une sauvegarde avec un sous-ensemble des types de données pris en charge. La définition de la variable d'environnement SKIP vous permet d'exclure des opérations spécifiques de l'exécution, réduisant ainsi votre archive finale.
Publicité
La variable d'environnement prend une liste de types de données séparés par des virgules. Vous pouvez trouver les options actuellement prises en charge dans le wiki GitLab.
Voici comment tout sauvegarder à l'exception des images de registre de conteneurs :
sudo gitlab-backup create SKIP=registry
Exclure le contenu du registre est souvent un moyen simple de réduire considérablement la taille de votre sauvegarde et d'accélérer sa vitesse de création. Une équipe avec plusieurs projets actifs créant plusieurs images Docker par jour peut rapidement accumuler des gigaoctets de données de registre. Les exclure de la sauvegarde n'est pas nécessairement un trop gros risque, car vous pouvez toujours reconstruire les images en utilisant le Dockerfile dans votre référentiel.
Sauvegarde vers S3
GitLab peut enregistrer automatiquement vos sauvegardes sur des fournisseurs de stockage d'objets compatibles S3. Décommentez les lignes backup_upload_connection et ajoutez vos informations de connexion :
gitlab_rails['backup_upload_connection'] = { “fournisseur” => "AWS", "région" => "eu-west-1", "aws_access_key_id" => "access_key", "aws_secret_access_key" => "secret_key", # "endpoint" => "https://…" }
Ajoutez votre propre clé d'accès, clé secrète et ID de région AWS pour terminer la connexion. Vous devez également définir le champ de point de terminaison si vous vous connectez à un fournisseur autre qu'AWS. Fournissez l'URL de votre serveur de stockage d'objets afin que GitLab puisse y télécharger.
Vous devez également définir une clé backup_upload_remote_directory. Recherchez cette ligne dans le fichier de configuration, décommentez-la et définissez un nom de compartiment S3 pour télécharger vos sauvegardes dans :
gitlab_rails['backup_upload_remote_directory'] = 'gitlab-sauvegardes';
Exécutez sudo gitlab-ctl reconfigure pour appliquer vos modifications.
La commande de création de sauvegarde va maintenant télécharger ses archives dans votre compartiment S3 configuré. Cela vous donne une bien plus grande redondance en stockant vos sauvegardes hors site, vous protégeant contre les pannes matérielles physiques.
Publicité
Attention, le paramètre backup_keep_time n'est pas pris en charge lorsque vous utilisez Stockage S3. Il s'applique uniquement aux archives de sauvegarde stockées localement. Vous pouvez obtenir quelque chose de similaire en utilisant les politiques d'expiration intégrées de S3 pour supprimer automatiquement les téléchargements après l'expiration d'une période de temps définie.
La copie de sauvegarde Stratégie
La stratégie de sauvegarde par défaut de GitLab consiste à diffuser les données en continu vers l'archive tar. Cela fonctionne généralement bien mais peut présenter des problèmes sur les instances GitLab très actives. Les données peuvent changer dans le répertoire source avant qu'elles n'aient fini d'atteindre l'archive, ce qui fait que tar les ignore avec une erreur de fichier modifié au fur et à mesure que nous le lisons.
Pour lutter contre cela, GitLab a introduit une stratégie de copie facultative. Cela copie toutes les données de sauvegarde éligibles dans un répertoire temporaire, puis diffuse le contenu copié dans l'archive tar finale. Cela garantit que tar ne lit pas à partir d'une instance GitLab en direct, mais a pour effet secondaire d'augmenter temporairement la consommation de stockage de GitLab. Les performances de sauvegarde peuvent également subir un impact notable, en particulier sur les périphériques de stockage plus lents.
La stratégie de copie est activée en définissant la variable d'environnement STRATEGY lors de l'exécution de la commande de sauvegarde. Vous devez vous assurer que vous disposez de suffisamment d'espace disque. GitLab exécutera la sauvegarde par étapes de type de données, vous n'aurez donc besoin que du double de la taille de votre plus grand type de données. Par exemple, si vous disposez de 5 Go de référentiels Git et de 10 Go de registres de conteneurs, vous devez disposer de 10 Go d'espace disponible supplémentaire, et non de 15 Go.
sudo gitlab-backup create STRATEGY=copy
N'oubliez pas : sauvegardez votre fichier de configuration !
Le script de sauvegarde de GitLab ne gère que les données créées par l'utilisateur. Il existe deux autres fichiers critiques essentiels au fonctionnement de votre serveur GitLab. Ceux-ci doivent également être sauvegardés pour assurer une récupération réussie de votre instance.
- /etc/gitlab/gitlab.rb – Il s'agit de votre fichier de configuration GitLab. Toutes les installations, à l'exception des plus élémentaires, acquièrent généralement de nombreuses modifications au fil du temps. La sauvegarde de ce fichier vous permet de le déposer dans une nouvelle installation de GitLab sans avoir à recommencer à zéro.
- /etc/gitlab/gitlab-secrets.json– Ce fichier doit être sauvegardé. Il comprend la clé de chiffrement de votre base de données, les secrets utilisés pour l'authentification à deux facteurs et d'autres données sensibles non récupérables. L'égarement de ce fichier pourrait rendre tout effort de récupération impossible, même si vous disposez d'une archive de sauvegarde fonctionnelle.
Vous pouvez utiliser une autre tâche cron pour sauvegarder ces deux fichiers. Ils doivent être copiés sur votre serveur afin que vous puissiez toujours y accéder en cas de panne matérielle.
Conclusion
Les sauvegardes sont vitales pour tout administrateur GitLab. Le logiciel est généralement essentiel pour chaque équipe d'une organisation, donc tout temps d'arrêt inattendu peut entraîner de graves problèmes opérationnels.
Publicité
GitLab est livré avec tout ce dont vous avez besoin pour effectuer des sauvegardes régulières. La meilleure approche consiste à créer une tâche cron qui exécute le script intégré selon un calendrier régulier. Enregistrez vos archives de sauvegarde sur un stockage d'objets externe pour vous protéger contre la perte, les pannes ou les dommages matériels. N'oubliez pas de sauvegarder manuellement vos fichiers de configuration et de secrets GitLab, sinon le processus de récupération sera beaucoup plus compliqué.