Configuration des sauvegardes sur votre appliance

À 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 cloner le dépôt Git du projet. Cette approche vous permet d’extraire les nouvelles mises en production directement à l’aide de Git, et votre fichier de configuration de sauvegarde existant, backup.config, sera conservé lors de l’installation d’une nouvelle version.

Sinon, si l’ordinateur hôte ne peut pas accéder à Internet, vous pouvez télécharger chaque mise en production de GitHub Enterprise Server Backup Utilities en tant qu’archive compressée, puis extraire et installer le contenu. Pour plus d’informations, consultez Bien démarrer dans la documentation du projet GitHub Enterprise Server Backup Utilities.

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.

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.

Pour cloner le dépôt de projet GitHub Enterprise Server Backup Utilities dans un répertoire local sur votre hôte de sauvegarde, exécutez la commande suivante.
```
$ git clone https://github.com/github/backup-utils.git /path/to/target/directory/backup-utils
```
Pour basculer vers le répertoire du dépôt local, exécutez la commande suivante.
```
cd backup-utils
```
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
```
Pour copier le fichier backup.config-example inclus dans backup.config, exécutez la commande suivante.
```
cp backup.config-example backup.config
```
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 appliance 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.
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 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.

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

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

Remarque : Nous vous recommandons de créer une copie de votre fichier backup.config existant dans un emplacement temporaire, comme $HOME/backup.config, avant de mettre à niveau GitHub Enterprise Server Backup Utilities.
Téléchargez les dernières mises à jour du projet en exécutant la commande git fetch.
```
git fetch
```
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
```
Pour vérifier que la mise à niveau a réussi, exécutez la commande suivante.
```
./bin/ghe-backup --version
```
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.

Sur votre hôte de sauvegarde, accédez à votre répertoire GitHub Enterprise Server Backup Utilities, généralement backup-utils.
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)
```
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 .
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
```
Pour basculer vers le dépôt cloné, exécutez la commande suivante.
```
cd backup-utils
```
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
```
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.
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.
Pour vérifier que la mise à niveau a réussi, exécutez la commande suivante.
```
./bin/ghe-backup --version
```
Pour vérifier la connectivité SSH avec votre GitHub Enterprise Server configuré, exécutez la commande suivante.
```
./bin/ghe-host-check
```
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 appliance GitHub Enterprise 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’appliance GitHub Enterprise cible en tant que clé SSH autorisée avant de restaurer une appliance.

Remarque : Quand vous effectuez des restaurations de sauvegarde sur votre instance GitHub Enterprise Server, les mêmes règles de prise en charge des versions s’appliquent. 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 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.

Pour restaurer votre instance GitHub Enterprise Server à partir de la dernière capture instantanée réussie, utilisez la commande ghe-restore.

Remarque : Avant de restaurer une sauvegarde, vérifiez ce qui suit :

Le mode maintenance est activé sur l’instance principale et tous les processus actifs sont terminés. Pour plus d’informations, consultez « Activation et planification du mode de maintenance ».
La réplication est arrêtée sur tous les réplicas dans les configurations de haute disponibilité. Pour plus d’informations, consultez la commande ghe-repl-stop dans « À propos de la configuration de la haute disponibilité ».
Si GitHub Actions est activée pour votre instance GitHub Enterprise Server, vous devez d’abord configurer le fournisseur de stockage externe GitHub Actions sur l’appliance de remplacement. Pour plus d’informations, consultez « Sauvegarde et restauration de GitHub Enterprise Server avec GitHub Actions activé ».

Lors de l’exécution de la commande ghe-restore, une sortie similaire à celle-ci doit s’afficher :

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

Remarque :

Les paramètres réseau sont exclus de l’instantané de sauvegarde. Vous devez configurer manuellement le réseau sur l’appliance GitHub Enterprise Server cible comme l’exige votre environnement.
Lors de la restauration sur de nouveaux disques sur une instance GitHub Enterprise Server existante ou vide, des UUID obsolètes peuvent être présents, ce qui provoque la non-synchronisation de la création de rapports de réplication Git et/ou Alambic. Les ID d’entrée de serveur obsolètes peuvent être la conséquence du 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 cela, les UUID obsolètes peuvent être supprimés à l’aide de ghe-repl-teardown une fois la restauration terminée et avant le démarrage de la réplication. Dans ce scénario, contactez Support GitHub Enterprise pour obtenir de l’aide.

Voici les options supplémentaires que vous pouvez utiliser avec la commande 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 « Utilisation de commandes de sauvegarde et de restauration » du fichier README de GitHub Enterprise Server Backup Utilities dans la documentation du projet GitHub Enterprise Server Backup Utilities.
L’indicateur -s vous permet de sélectionner un autre instantané de sauvegarde.

Configuration des sauvegardes sur votre appliance

Dans cet article