Skip to main content

Cette version de GitHub Enterprise Server ne sera plus disponible le 2026-08-25. Les versions abandonnées ne sont pas prises en charge. Aucune publication de correctifs n’est effectuée, même pour les problèmes de sécurité critiques. Pour de meilleures performances, une sécurité améliorée et de nouvelles fonctionnalités dans GitHub Enterprise Server, consultez Overview du processus de mise à niveau. Pour obtenir de l’aide sur la mise à niveau, GitHub Support Entreprise.

Restauration à partir d’une sauvegarde

Restaurez une GitHub Enterprise Server instance à l’aide d’un instantané de sauvegarde créé précédemment.

Vous pouvez restaurer une instance à partir d’une GitHub Enterprise Server sauvegarde à l’aide de la ligne de commande. Le service de sauvegarde prend en charge la restauration complète des instances, y compris la configuration et les données utilisateur.

Avertissement

La restauration à partir d’une sauvegarde remplacera toutes les données existantes sur votre instance. Cette opération ne peut pas être annulée.

Exigences relatives à la version de l’instantané

Vous pouvez uniquement restaurer un instantané s’il provient d’une version ne comportant pas plus de deux versions de fonctionnalités antérieures à la version de l’instance cible.

Par exemple :

  • Un instantané de la version 3.17 peut être restauré sur une cible exécutant les versions 3.17.x, 3.18.x ou 3.19.x.
  • Vous ne pouvez pas restaurer un instantané 3.17 en 3.20, car cela représente plus de deux versions d'écart.

Vous ne pouvez pas non plus restaurer une version plus récente vers une version plus ancienne. Par exemple, la tentative de restauration d’une capture instantanée 3.18 sur une instance 3.17 échoue avec : Error: Snapshot can not be restored to an older release of GitHub Enterprise Server.

Prérequis

Avant de restaurer une sauvegarde :

  1. Activez le mode maintenance sur l’instance cible. Consultez « Activation et planification du mode de maintenance ».
  2. Vérifiez l’accès au stockage de sauvegarde contenant l’instantané.
  3. Suspendez les services interférents : si vous utilisez la haute disponibilité (HA), assurez-vous que la réplication est arrêtée.
  4. Se préparer à GitHub Actions — si cette option est activée, assurez-vous que l’instance cible est configurée avec le stockage externe approprié. Pour plus d’informations, consultez Restauration avec GitHub Actions activé.

Démarrage de l’opération de restauration

Pour effectuer une restauration à partir d’un instantané :

  1. Connectez-vous à l’instance cible via SSH en tant qu’utilisateur admin.

  2. Exécutez l’une des commandes suivantes :

    • Restaurez le dernier instantané :

      ghe-restore
      
    • Restaurez un instantané spécifique. Remplacez <SNAPSHOT_TIMESTAMP> par l’horodateur de l’instantané que vous souhaitez restaurer (par exemple, YYYYMMDDTHHMMSS).

      ghe-restore -s <SNAPSHOT_TIMESTAMP>
      
    • (Facultatif) Forcer le remplacement de la configuration, des certificats et des données de licence :

      ghe-restore -c          # Latest snapshot
      ghe-restore -s <SNAPSHOT_TIMESTAMP> -c  # Specific snapshot
      
  3. Finaliser dans Console de gestion:

    • Passez en revue tous les paramètres de configuration (réseau, authentification, TLS, etc.).
    • Cliquez sur Enregistrer les paramètres pour les appliquer et démarrer les services.
    • L’instance n’est pas entièrement opérationnelle tant que cette étape n’est pas terminée.
  4. Validez l’instance restaurée pour vous assurer que tout fonctionne comme prévu.

  5. Si vous utilisez la haute disponibilité, effectuez d’abord la restauration sur une instance autonome. Reconfigurez ensuite HA.

    • Si vous rencontrez des problèmes de synchronisation (par exemple, des UUID obsolètes dans ghe-repl-status), exécutez ghe-repl-teardown.
    • Pour obtenir de l’aide, contactez Support GitHub.
  6. Réenregistrer les runners auto-hébergés GitHub Actions, car la restauration invalide les jetons précédents.

Rotation et rétention des instantanés

Les instantanés sont automatiquement supprimés en fonction de vos paramètres de rétention :

  • Seuls les n instantanés les plus récents sont conservés (selon la configuration).
  • Les instantanés plus anciens sont supprimés après chaque sauvegarde réussie.
  • Les instantanés sont nommés à l’aide d’horodatages (YYYYMMDDTHHMMSS) pour faciliter leur identification.
  • Les liens physiques sont utilisés pour stocker efficacement les fichiers inchangés tout en conservant une capacité de restauration complète.

Résolution des problèmes relatifs aux échecs de restauration

Si une opération de restauration échoue, vérifiez :

  • Intégrité de la sauvegarde : assurez-vous que l’instantané n’a pas été interrompu ou corrompu.
  • Accès au stockage : vérifiez que l’instance peut monter et lire le volume de sauvegarde.
  • Incompatibilité de version : confirmez que la version de l’instantané est compatible avec l’instance cible.
  • Journaux des événements : examinez /var/log/github-backup/restore-verbose-[timestamp].log pour rechercher des erreurs.

Si le Console de gestion affiche une erreur générique, connectez-vous à l’instance en SSH pour accéder aux journaux détaillés.