Configuration des sauvegardes sur votre instance

À 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	2
Mémoire	2 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, nous vous recommandons de télécharger la version appropriée de GitHub Enterprise Server Backup Utilities en tant qu’archive compressée, puis d’extraire et d’installer le contenu. Pour plus d’informations, consultez Démarrage dans le référentiel github/backup-utils.

Le téléchargement de la version en tant qu’archive compressée garantit que vous utilisez la version correcte de GitHub Enterprise Server Backup Utilities pour votre instance GitHub Enterprise Server et que votre fichier de configuration de sauvegarde existant backup.config sera conservé lors de l’installation d’une nouvelle version.

Les instantanés de sauvegarde sont écrits dans le chemin du disque défini par la variable de répertoire de données GHE_DATA_DIR dans votre fichier backup.config. Les instantanés doivent être stockés sur un système de fichiers qui prend en charge les liens symboliques et physiques.

1. 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.

2. 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
   

3. Pour basculer vers le répertoire du dépôt local, exécutez la commande suivante.

   cd backup-utils
   

4. Pour copier le fichier backup.config-example inclus dans backup.config, exécutez la commande suivante.

   cp backup.config-example backup.config
   

5. Pour personnaliser votre configuration, modifiez backup.config dans un éditeur de texte.

   1. 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ée 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.

   2. 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, mais en dehors de l’emplacement où vous avez cloné le dépôt Git à l’étape 1.

6. 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) ».

7. 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
   

8. 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 mise en production 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. Vous pouvez mettre à niveau GitHub Enterprise Server Backup Utilities dans un dépôt Git en récupérant et en extrayant les dernières modifications.

En guise d’alternative, si vous n’utilisez pas de dépôt Git pour votre installation, vous pouvez extraire une nouvelle archive en place ou changer votre approche de façon à utiliser un dépôt Git à la place.

Vérification du type d’installation

Vous pouvez vérifier la méthode d’installation pour GitHub Enterprise Server Backup Utilities et déterminer le meilleur moyen de mettre à niveau votre installation.

1. Sur votre hôte de sauvegarde, accédez à votre répertoire GitHub Enterprise Server Backup Utilities, généralement backup-utils.

2. 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
   

   Si la sortie est true, GitHub Enterprise Server Backup Utilities a été installé en clonant le dépôt Git du projet. Si la sortie inclut fatal: not a git repository (or any of the parent directories), GitHub Enterprise Server Backup Utilities a probablement été installé en extrayant un fichier d’archive compressé. Si votre installation se trouve dans un dépôt Git, vous pouvez installer la dernière version à l’aide de Git. Si l’installation provient d’un fichier archive compressé, vous pouvez télécharger et extraire la dernière version, ou réinstaller GitHub Enterprise Server Backup Utilities à l’aide de Git pour simplifier les mises à niveau futures.

• Mise à niveau d’une installation dans un dépôt Git
• Utilisation de Git au lieu d’archives compressées pour les mises à niveau

Mise à niveau d’une installation dans un dépôt Git

1. Sur votre hôte de sauvegarde, accédez à votre répertoire GitHub Enterprise Server Backup Utilities, généralement backup-utils.

1. Téléchargez les dernières mises à jour du projet en exécutant la commande git fetch.

   git fetch
   

2. Pour effectuer une mise à jour vers la dernière mise en production du projet, utilisez la branche stable en exécutant la commande git checkout stable.

   git checkout stable
   

   Vous pouvez également utiliser une version de projet spécifique en exécutant la commande suivante et en remplaçant X.Y.Z par la mise en production souhaitée.

   git checkout vX.Y.Z
   

3. Pour vérifier que la mise à niveau a réussi, exécutez la commande suivante.

   ./bin/ghe-backup --version
   

4. Pour vérifier la connectivité SSH avec votre GitHub Enterprise Server configuré, exécutez la commande suivante.

   ./bin/ghe-host-check
   

Utilisation de Git au lieu d’archives compressées pour les mises à niveau

Si votre hôte de sauvegarde dispose d’une connectivité Internet et que vous avez déjà utilisé une archive compressée (.tar.gz) pour installer ou mettre à niveau GitHub Enterprise Server Backup Utilities, nous vous recommandons d’utiliser plutôt un dépôt Git pour votre installation. La mise à niveau à l’aide de Git nécessite moins de travail et conserve votre configuration de sauvegarde.

Pour utiliser Git au lieu d’une archive compressée pour les mises à niveau, vous devez sauvegarder votre configuration existante, cloner le référentiel, copier votre configuration sur place, vérifier l’installation, contrôler la connectivité SSH, puis supprimer l’ancienne installation.

1. Sur votre hôte de sauvegarde, accédez à votre répertoire GitHub Enterprise Server Backup Utilities, généralement backup-utils.

2. Pour sauvegarder votre configuration GitHub Enterprise Server Backup Utilities existante, copiez votre fichier backup.config actuel dans un emplacement sécurisé, tel que votre répertoire d’accueil.

   cp backup.config $HOME/backup.config.saved-$(date +%Y%m%d-%H%M%S)
   

3. Basculez vers le répertoire local sur votre hôte de sauvegarde où vous souhaitez installer le dépôt Git GitHub Enterprise Server Backup Utilities .

4. Pour cloner le dépôt de projet dans le répertoire sur votre hôte de sauvegarde, exécutez la commande suivante.

   git clone https://github.com/github/backup-utils.git
   

5. Pour basculer vers le dépôt cloné, exécutez la commande suivante.

   cd backup-utils
   

6. Pour effectuer une mise à jour vers la dernière mise en production du projet, utilisez la branche stable en exécutant la commande git checkout stable.

   git checkout stable
   

   Vous pouvez également utiliser une version de projet spécifique en exécutant la commande suivante et en remplaçant X.Y.Z par la mise en production souhaitée.

   git checkout vX.Y.Z
   

7. Pour restaurer votre configuration de sauvegarde à partir d’une version antérieure, copiez votre fichier de configuration de sauvegarde existant dans le répertoire du dépôt local. Remplacez le chemin dans la commande par l’emplacement du fichier enregistré à l’étape 2.

   cp PATH/TO/BACKUP/FROM/STEP/2 backup.config
   

   Remarque : Vous pouvez choisir où restaurer votre fichier de configuration de sauvegarde après le clonage. Pour plus d’informations sur l’emplacement des fichiers de configuration, consultez Bien démarrer dans la documentation du projet GitHub Enterprise Server Backup Utilities.

8. Pour vérifier que les chemins des répertoires ou des scripts dans votre fichier de configuration de sauvegarde sont corrects, passez en revue le fichier dans un éditeur de texte.

9. Pour vérifier que la mise à niveau a réussi, exécutez la commande suivante.

   ./bin/ghe-backup --version
   

10. Pour vérifier la connectivité SSH avec votre GitHub Enterprise Server configuré, exécutez la commande suivante.

    ./bin/ghe-host-check
    

11. Vérifiez que vos données de sauvegarde ne se trouvent pas dans le répertoire de l’ancienne installation.

12. Supprimez votre ancien répertoire GitHub Enterprise Server Backup Utilities à l’étape 1 (où se trouvait l’installation d’archive compressée).

Planification d'une sauvegarde

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

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

1. 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 ».
2. 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é ».
3. 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’aide supplémentaire, contactez le Support GitHub Enterprise.