À propos de GitHub Enterprise Server Backup Utilities
GitHub Enterprise Server Backup Utilities est un système de sauvegarde que vous installez sur un hôte distinct, qui effectue des captures instantanées de sauvegarde de votre instance GitHub Enterprise Server à intervalles réguliers via une connexion réseau SSH sécurisée. Vous pouvez utiliser un instantané pour restaurer une instance existante de GitHub Enterprise Server dans un état précédent à partir de l’hôte de sauvegarde.
Seules les données ajoutées depuis le dernier instantané sont transférées sur le réseau et occupent un espace de stockage physique supplémentaire. Pour réduire l’impact sur les performances, les sauvegardes sont effectuées en ligne selon la priorité processeur/entrées-sorties la plus faible. Vous n’avez pas besoin de planifier une fenêtre de maintenance pour effectuer une sauvegarde.
Les versions principales et les numéros de version pour GitHub Enterprise Server Backup Utilities s’alignent sur les mises en production de fonctionnalités de GitHub Enterprise Server. Nous prenons en charge les quatre versions les plus récentes des deux produits. Pour plus d’informations, consultez « Versions de GitHub Enterprise Server ».
Pour plus d’informations sur les fonctionnalités, les exigences et l’utilisation avancée, consultez le fichier README de GitHub Enterprise Server Backup Utilities dans la documentation du projet GitHub Enterprise Server Backup Utilities.
Prérequis
Pour utiliser GitHub Enterprise Server Backup Utilities, vous devez disposer d’un système hôte distinct de votre instance GitHub Enterprise Server. Pour plus d’informations sur la configuration du système, consultez Configuration requise dans le dépôt github/backup-utils.
Vous pouvez aussi intégrer GitHub Enterprise Server Backup Utilities dans un environnement existant pour le stockage permanent à long terme des données critiques.
L’hôte de sauvegarde et votre instance GitHub Enterprise Server doivent de préférence être géographiquement distants l’un de l’autre. Ainsi, les sauvegardes seront disponibles pour une récupération si un sinistre ou une panne réseau de grande ampleur se produit sur le site principal.
Les besoins en stockage physique varieront en fonction de l’utilisation disque des dépôts Git et des modèles de croissance attendus :
Matériel | Recommandation |
---|---|
Processeurs virtuels | 4 |
Mémoire | 8 Go |
Stockage | Cinq fois le stockage alloué à l’instance principale |
Selon votre utilisation en termes par exemple d’activité des utilisateurs et d’intégrations sélectionnées, des ressources supplémentaires peuvent s’avérer nécessaires.
Pour plus d’informations, consultez Exigences de GitHub Enterprise Server Backup Utilities dans la documentation du projet GitHub Enterprise Server Backup Utilities.
Installation de GitHub Enterprise Server Backup Utilities
Pour installer GitHub Enterprise Server Backup Utilities sur votre hôte de sauvegarde, téléchargez la dernière version de GitHub Enterprise Server Backup Utilities à partir du référentiel github/backup-utils compatible avec votre version de GitHub Enterprise Server. Par exemple, si vous exécutez la version 3.8.4 de GitHub Enterprise Server, téléchargez la dernière version de GitHub Enterprise Server Backup Utilities dans la série 3.10. Cela est possible, car toutes les versions de GitHub Enterprise Server Backup Utilities sont à compatibilité descendante pour 2 versions, ce qui signifie que la série GitHub Enterprise Server Backup Utilities 3.10 peut être utilisée pour assurer la sauvegarde et restauration des instances GitHub Enterprise Server exécutant les versions 3.8, 3.9 ou 3.10.
Après avoir téléchargé une archive compressée, vous pouvez extraire et installer le contenu. Pour plus d’informations, consultez Démarrage dans le référentiel github/backup-utils.
Si vous disposez d'un fichier de configuration de sauvegarde existant backup.config
, veillez à copier le fichier à l'emplacement de la version nouvellement extraite et installée de GitHub Enterprise Server Backup Utilities.
Les instantanés de sauvegarde créés par GitHub Enterprise Server Backup Utilities sont écrites dans le chemin d'accès du disque défini par la variable de l'annuaire de données GHE_DATA_DIR
dans votre fichier backup.config
. Ces instantanés doivent être stockés sur un système de fichiers qui prend en charge les liens symboliques et physiques.
Remarque : Nous vous recommandons de veiller à ce que vos instantanés ne soient pas conservés dans un sous-répertoire du répertoire d’installation GitHub Enterprise Server Backup Utilities, pour éviter de remplacer par inadvertance votre répertoire de données lors de la mise à niveau des versions de GitHub Enterprise Server Backup Utilities.
-
Téléchargez la version appropriée de GitHub Enterprise Server Backup Utilities à partir de la page Versions du référentiel github/backup-utils.
-
Pour extraire le référentiel à l’aide de tar, exécutez la commande suivante.
tar -xzvf /path/to/github-backup-utils-vMAJOR.MINOR.PATCH.tar.gz
-
Pour basculer vers le répertoire du dépôt local, exécutez la commande suivante.
cd backup-utils
-
Pour copier le fichier
backup.config-example
inclus dansbackup.config
, exécutez la commande suivante.cp backup.config-example backup.config
-
Pour personnaliser votre configuration, modifiez
backup.config
dans un éditeur de texte.-
Si vous avez précédemment mis à niveau GitHub Enterprise Server Backup Utilities à l'aide de Git, veillez à copier votre configuration existante dans le nouveau fichier
backup.config
. Pour plus d'informations, reportez-vous à « Mise à niveau de GitHub Enterprise Server Backup Utilities ». -
Définissez la valeur de
GHE_HOSTNAME
sur le nom d’hôte ou l’adresse IP de votre instance principale GitHub Enterprise Server.Remarque : si votre instance GitHub Enterprise Server est déployé en tant que cluster ou dans une configuration à haute disponibilité utilisant un équilibreur de charge, le
GHE_HOSTNAME
peut être le nom d'hôte de l'équilibreur de charge, dans la mesure où il autorise l'accès SSH (sur le port 122) à votre instance GitHub Enterprise Server.Pour faire en sorte qu’une instance récupérée soit immédiatement disponible, effectuez des sauvegardes ciblant l’instance principale, même dans une configuration de géoréplication.
-
Définissez la valeur de
GHE_DATA_DIR
sur l’emplacement du système de fichiers où vous souhaitez stocker les instantanées de sauvegarde. Nous vous recommandons de choisir un emplacement sur le même système de fichiers que votre hôte de sauvegarde.
-
-
Pour accorder à votre hôte de sauvegarde l’accès à votre instance, ouvrez la page des paramètres de votre instance principale à
http(s)://HOSTNAME/setup/settings
et ajoutez la clé SSH de l’hôte de sauvegarde à la liste des clés SSH autorisées. Pour plus d’informations, consultez « Accès à l’interpréteur de commandes d’administration (SSH) ». -
Sur votre hôte de sauvegarde, vérifiez la connectivité SSH à votre instance GitHub Enterprise Server avec la commande
ghe-host-check
../bin/ghe-host-check
-
Pour créer une sauvegarde complète initiale, exécutez la commande suivante.
./bin/ghe-backup
Pour plus d’informations sur l’utilisation avancée, consultez le fichier README de GitHub Enterprise Server Backup Utilities dans la documentation du projet GitHub Enterprise Server Backup Utilities.
Mise à niveau de GitHub Enterprise Server Backup Utilities
Lors de la mise à niveau de GitHub Enterprise Server Backup Utilities, vous devez choisir une version qui fonctionnera avec votre version actuelle de GitHub Enterprise Server. Votre installation de GitHub Enterprise Server Backup Utilities doit être au moins la même version que votre instance GitHub Enterprise Server, et ne peut pas avoir deux versions d’avance. Pour plus d’informations, consultez Exigences de version GitHub Enterprise Server dans la documentation du projet GitHub Enterprise Server Backup Utilities.
-
Vérifiez la méthode d'installation pour GitHub Enterprise Server Backup Utilities. Les versions précédentes de GitHub Enterprise Server Backup Utilities prenaient en charge l'installation et les mises à jour dans un référentiel Git local, mais cette méthode a été abandonnée.
-
Sur votre hôte de sauvegarde, accédez à votre répertoire GitHub Enterprise Server Backup Utilities, généralement
backup-utils
. -
Pour vérifier s’il existe un répertoire de travail valide dans un dépôt Git, exécutez la commande suivante.
git rev-parse --is-inside-work-tree
-
-
Pour déterminer comment mettre à niveau GitHub Enterprise Server Backup Utilities, vérifiez la sortie de
git rev-parse --is-inside-work-tree
.- Si la sortie est
true
, GitHub Enterprise Server Backup Utilities a été installé en clonant le dépôt Git du projet. Pour effectuer la mise à niveau, copiez votre configuration existante dansbackup.config
, puis suivez les instructions contenues dans « Installation de GitHub Enterprise Server Backup Utilities ». - Si la sortie inclut
fatal: not a git repository (or any of the parent directories)
, c'est que GitHub Enterprise Server Backup Utilities a été extrait d'un fichier d'archive compressé. Pour changer de niveau, suivez les instructions contenues dans « Installation de GitHub Enterprise Server Backup Utilities ».
- Si la sortie est
Planification d'une sauvegarde
Avertissement : Après la restauration d’une sauvegarde créée avec GitHub Enterprise Server Backup Utilities 3.7.0, 3.8.0, or 3.9.0, les utilisateurs risquent de ne pas être en mesure de se connecter à l’instance. Pour résoudre ce problème, ainsi qu’un bogue qui empêchait la sauvegarde des clés de chiffrement d’analyse des secrets, mettez à niveau votre hôte de sauvegarde pour utiliser GitHub Enterprise Server Backup Utilities 3.9.1 et générez une nouvelle sauvegarde complète à l’aide de ghe-backup
. Pour plus d’informations à propos de l’utilisation d’une sauvegarde existante, consultez « Problèmes connus liés aux sauvegardes pour votre instance ».
Vous pouvez planifier des sauvegardes régulières sur l’hôte de sauvegarde à l’aide de la commande cron(8)
ou d’un service de planification de commandes similaire. La fréquence de sauvegarde configurée détermine l’objectif de point de récupération (RPO) dans le cas le plus défavorable dans votre plan de récupération. Par exemple, si vous avez planifié une exécution de la sauvegarde tous les jours à minuit, vous pouvez perdre jusqu’à 24 heures de données dans un scénario catastrophe. Nous vous recommandons de commencer avec une planification de sauvegarde horaire, garantissant ainsi dans le pire des cas une perte de données maximale d’une heure si les données du site principal sont détruites.
Si les tentatives de sauvegarde se chevauchent, la commande ghe-backup
abandonne avec un message d’erreur indiquant l’existence d’une sauvegarde simultanée. En pareil cas, nous vous recommandons de diminuer la fréquence de vos sauvegardes planifiées. Pour plus d’informations, consultez la section « Planification des sauvegardes » du fichier README de GitHub Enterprise Server Backup Utilities dans la documentation du projet GitHub Enterprise Server Backup Utilities.
Restauration d’une sauvegarde
Avertissement : Après la restauration d’une sauvegarde créée avec GitHub Enterprise Server Backup Utilities 3.7.0, 3.8.0, or 3.9.0, les utilisateurs risquent de ne pas être en mesure de se connecter à l’instance. Pour résoudre ce problème, ainsi qu’un bogue qui empêchait la sauvegarde des clés de chiffrement d’analyse des secrets, mettez à niveau votre hôte de sauvegarde pour utiliser GitHub Enterprise Server Backup Utilities 3.9.1 et générez une nouvelle sauvegarde complète à l’aide de ghe-backup
. Pour plus d’informations à propos de l’utilisation d’une sauvegarde existante, consultez « Problèmes connus liés aux sauvegardes pour votre instance ».
En cas de panne prolongée ou d’événement catastrophique sur le site principal, vous pouvez restaurer votre instance GitHub Enterprise Server en provisionnant une autre instance et en effectuant une restauration à partir de l’hôte de sauvegarde. Vous devez ajouter la clé SSH de l’hôte de sauvegarde à l’instance GitHub Enterprise cible en tant que clé SSH autorisée avant de restaurer une instance.
Quand vous effectuez des restaurations de sauvegarde sur votre instance GitHub Enterprise Server, vous ne pouvez pas restaurer des données issues d’une mise en production de fonctionnalité antérieure de plus de deux versions. Par exemple, si vous effectuez une sauvegarde à partir de GitHub Enterprise Server 3.0.x, vous pouvez restaurer la sauvegarde sur une instance exécutant GitHub Enterprise Server 3.2.x. Vous ne pouvez pas restaurer de données à partir d’une sauvegarde de GitHub Enterprise Server 2.22.x sur une instance exécutant 3.2.x, car il y aurait alors trois sauts entre les versions (2.22 à 3.0 à 3.1 à 3.2). Vous devrez d’abord restaurer sur une instance 3.1.x, puis effectuer une mise à niveau vers la version 3.2.x.
Des paramètres réseau sont exclus de l’instantané de sauvegarde. Après la restauration, vous devez configurer manuellement la mise en réseau sur l’instance GitHub Enterprise Server cible.
Prérequis
- Assurez-vous que le mode maintenance est activé sur l’instance principale et que tous les processus actifs sont terminés. Pour plus d’informations, consultez « Activation et planification du mode de maintenance ».
- Arrêtez la réplication sur tous les nœuds réplica dans une configuration à haute disponibilité. Pour plus d’informations, consultez « À propos de la configuration de la haute disponibilité ».
- Approvisionnez une nouvelle instance GitHub Enterprise Server à utiliser comme cible pour la restauration de votre sauvegarde. Pour plus d’informations, consultez « Configuration d’une instance GitHub Enterprise Server ».
- Si GitHub Actions est activée pour votre instance GitHub Enterprise Server, vous devez configurer le fournisseur de stockage externe pour GitHub Actions sur l’instance de remplacement. Pour plus d’informations, consultez « Sauvegarde et restauration de GitHub Enterprise Server avec GitHub Actions activé ».
Démarrage de l’opération de restauration
Pour restaurer votre instance GitHub Enterprise Server à partir de votre hôte de sauvegarde en utilisant la dernière capture instantanée réussie, utilisez la commande ghe-restore
. Vous pouvez utiliser les options supplémentaires suivantes avec ghe-restore
.
- L’indicateur
-c
remplace les paramètres, le certificat et les données de licence sur l’hôte cible, même s’il est déjà configuré. Omettez cet indicateur si vous configurez une instance intermédiaire à des fins de test et que vous souhaitez conserver la configuration existante sur la cible. Pour plus d’informations, consultez la section relative à l’utilisation des commandes de sauvegarde et de restauration dans le document README GitHub Enterprise Server Backup Utilities dans le dépôt github/backup-utils. - L’indicateur
-s
vous permet de sélectionner un autre instantané de sauvegarde.
Une fois que vous avez exécuté ghe-restore
, la commande vérifie la restauration, puis génère les détails et l’état pendant l’opération.
$ ghe-restore -c 169.154.1.1
> Checking for leaked keys in the backup snapshot that is being restored ...
> * No leaked keys found
> Connect 169.154.1.1:122 OK (v2.9.0)
> WARNING: All data on GitHub Enterprise appliance 169.154.1.1 (v2.9.0)
> will be overwritten with data from snapshot 20170329T150710.
> Please verify that this is the correct restore host before continuing.
> Type 'yes' to continue: yes
> Starting restore of 169.154.1.1:122 from snapshot 20170329T150710
# ...output truncated
> Completed restore of 169.154.1.1:122 from snapshot 20170329T150710
> Visit https://169.154.1.1/setup/settings to review appliance configuration.
Le cas échéant, pour valider la restauration, configurez une liste d’exceptions IP afin d’autoriser l’accès à une liste spécifique d’adresses IP. Pour plus d’informations, consultez « Activation et planification du mode de maintenance ».
Sur une instance dans une configuration à haute disponibilité, une fois que vous avez restauré sur de nouveaux disques sur un instance existante ou vide, ghe-repl-status
peut signaler que la réplication Git ou Alambic n’est pas synchronisée en raison d’UUID de serveur obsolètes. Ces UUID obsolètes peuvent être liés au fait qu’un nœud mis hors service dans une configuration à haute disponibilité est toujours présent dans la base de données d’application, mais pas dans la configuration de réplication restaurée.
Pour corriger une fois la restauration terminée et avant de commencer la réplication, vous pouvez supprimer les UUID obsolètes avec ghe-repl-teardown
. Si vous avez besoin d’une assistance supplémentaire, visitez Support GitHub Enterprise.
Supervision de la progression de la sauvegarde ou de la restauration
Pendant une opération de sauvegarde ou de restauration, vous pouvez utiliser l’utilitaire ghe-backup-progress
sur votre hôte de sauvegarde pour superviser la progression de l’opération. L’utilitaire affiche la progression de chaque travail de manière séquentielle.
Pour superviser la progression sur l’hôte de sauvegarde, à partir du répertoire contenant GitHub Enterprise Server Backup Utilities, exécutez la commande suivante.
bin/ghe-backup-progress
bin/ghe-backup-progress
Par défaut, l’utilitaire affiche la progression en continu jusqu’à ce que l’opération soit terminée. Vous pouvez appuyer sur n’importe quelle touche pour revenir à l’invite.
Si vous le souhaitez, vous pouvez exécuter la commande suivante pour afficher la progression actuelle, le dernier travail terminé, puis quitter immédiatement.
bin/ghe-backup-progress --once
bin/ghe-backup-progress --once