Informationen zu GitHub Enterprise Server Backup Utilities
GitHub Enterprise Server Backup Utilities ist ein Sicherungssystem, das du auf einem separaten Host installierst, der in regelmäßigen Intervallen über eine sichere SSH-Netzwerkverbindung Sicherungsmomentaufnahmen von Ihre GitHub Enterprise Server-Instance erstellt. Mit einem Snapshot kannst du eine vorhandene GitHub Enterprise Server-Instanz in einem vorherigen Zustand auf dem Backup-Host wiederherstellen.
Nur die seit dem letzten Snapshot hinzugefügten Daten werden über das Netzwerk übertragen und belegen zusätzlichen physischen Speicherplatz. Zum Minimieren der Auswirkung auf die Leistung werden Backups online unter der niedrigsten CPU-/E/A-Priorität durchgeführt. Zum Durchführen eines Backups muss kein Wartungsfenster geplant werden.
Hauptversionen und Versionsnummern für GitHub Enterprise Server Backup Utilities sind auf Featurereleases von GitHub Enterprise Server abgestimmt. Wir unterstützen die vier neuesten Versionen beider Produkte. Weitere Informationen findest du unter GitHub Enterprise Server-Releases.
Ausführlichere Informationen zu Features, Anforderungen und erweiterter Verwendung findest du in der README-Datei zu GitHub Enterprise Server Backup Utilities in der GitHub Enterprise Server Backup Utilities-Projektdokumentation.
Voraussetzungen
Du musst über ein von Ihre GitHub Enterprise Server-Instance getrenntes Hostsystem verfügen, um GitHub Enterprise Server Backup Utilities verwenden zu können. Ausführliche Informationen zur Konfiguration des Systems findest du unter Anforderungen im Repository „github/backup-utils“.
Du kannst GitHub Enterprise Server Backup Utilities auch zur langfristigen dauerhaften Speicherung von kritischen Daten in eine vorhandene Umgebung integrieren.
Der Sicherungshost und Ihre GitHub Enterprise Server-Instance sollten geografisch voneinander getrennt sein. Dadurch wird gewährleistet, dass Backups wiederhergestellt werden können, falls am Hauptstandort eine schwere Katastrophe oder ein Netzwerkausfall auftritt.
Die Anforderungen an den physischen Speicher variieren basierend auf der Git-Repository-Festplattennutzung und den erwarteten Wachstumsmustern:
Hardware | Empfehlung |
---|---|
vCPUs | 4 |
Memory | 8 GB |
Storage | Das Fünffache des zugeordneten Speichers der primären Instanz |
Entsprechend deiner Nutzung, beispielsweise in Bezug auf die Benutzeraktivität und die ausgewählten Integrationen, sind möglicherweise mehr Ressourcen erforderlich.
Ausführlichere Informationen findest du unter GitHub Enterprise Server Backup Utilities-Anforderungen in der GitHub Enterprise Server Backup Utilities-Projektdokumentation.
GitHub Enterprise Server Backup Utilities installieren
Um GitHub Enterprise Server Backup Utilities auf Ihrem Sicherungshost zu installieren, laden Sie die neueste Version von GitHub Enterprise Server Backup Utilities aus dem Github/backup-utils-Repository herunter, das mit Ihrer Version von GitHub Enterprise Server kompatibel ist. Wenn Sie beispielsweise Version 3.8.4 von GitHub Enterprise Server ausführen, laden Sie die neueste Version von GitHub Enterprise Server Backup Utilities in der Serie 3.10 herunter. Dies ist möglich, da alle Versionen von GitHub Enterprise Server Backup Utilities für zwei Versionen abwärtskompatibel sind, was bedeutet, dass die Serie GitHub Enterprise Server Backup Utilities 3.10 zum Sichern und Wiederherstellen von GitHub Enterprise Server-Instanzen mit den Versionen 3.8, 3.9 oder 3.10 verwendet werden kann.
Nachdem Sie ein komprimiertes Archiv heruntergeladen haben, können Sie den Inhalt extrahieren und installieren. Weitere Informationen finden Sie unter Erste Schritte im Github/backup-utils-Repository.
Wenn Sie über eine vorhandene Sicherungskonfigurationsdatei, backup.config
, verfügen, stellen Sie sicher, dass Sie die Datei an den Speicherort der neu extrahierten und installierten Version von GitHub Enterprise Server Backup Utilities kopieren.
Sicherungsmomentaufnahmen, die von GitHub Enterprise Server Backup Utilities erstellt wurden, werden in den Datenträgerpfad geschrieben, der von der GHE_DATA_DIR
-Datenverzeichnisvariable in Ihrer backup.config
-Datei festgelegt wurde. Diese Momentaufnahmen müssen auf einem Dateisystem gespeichert werden, das symbolische und feste Links unterstützt.
Hinweis: Es wird empfohlen, sicherzustellen, die Momentaufnahmen nicht in einem Unterverzeichnis des GitHub Enterprise Server Backup Utilities-Installationsverzeichnis zu speichern, um zu vermeiden, dass das Datenverzeichnis beim Aktualisieren von GitHub Enterprise Server Backup Utilities-Versionen versehentlich überschrieben wird.
-
Laden Sie die relevante GitHub Enterprise Server Backup Utilities-Version von der Seite Versionen des Github/backup-utils-Repositorys herunter.
-
Um das Repository mithilfe von Tar zu extrahieren, führen Sie den folgenden Befehl aus.
tar -xzvf /path/to/github-backup-utils-vMAJOR.MINOR.PATCH.tar.gz
-
Führe den folgenden Befehl aus, um in das lokale Repositoryverzeichnis zu wechseln.
cd backup-utils
-
Führe den folgenden Befehl aus, um die enthaltene
backup.config-example
-Datei inbackup.config
zu kopieren.cp backup.config-example backup.config
-
Zum Anpassen deiner Konfiguration bearbeite
backup.config
in einem Text-Editor.-
Wenn du zuvor GitHub Enterprise Server Backup Utilities mithilfe von Git aktualisiert hast, stelle sicher, dass du deine vorhandene Konfiguration aus
backup.config
in die neue Datei kopierst. Weitere Informationen findest du unter Aktualisieren von GitHub Enterprise Server Backup Utilities. -
Lege den
GHE_HOSTNAME
-Wert auf den Hostnamen oder die IP-Adresse deiner primären GitHub Enterprise Server-Instanz fest.Hinweis: Wenn Ihre GitHub Enterprise Server-Instance als Cluster oder in einer Hochverfügbarkeitskonfiguration mithilfe eines Lastenausgleichs bereitgestellt wird, kann
GHE_HOSTNAME
der Hostname des Lastenausgleichs sein, solange der Lastenausgleich SSH-Zugriff über Port 122 auf Ihre GitHub Enterprise Server-Instance zulässt.Um sicherzustellen, dass eine wiederhergestellte Instanz sofort verfügbar ist, solltest du Sicherungen durchführen, die selbst in einer Georeplikationskonfiguration die primäre Instanz als Ziel haben.
-
Lege den
GHE_DATA_DIR
-Wert auf den Dateisystempfad fest, unter dem du Backup-Momentaufnahmen speichern möchtest. Es wird empfohlen, einen Speicherort im selben Dateisystem wie dein Sicherungshost auszuwählen.
-
-
Um deinem Sicherungshost Zugriff auf deine Instanz zu gewähren, öffne die Einstellungsseite deiner primären Instanz unter
http(s)://HOSTNAME/setup/settings
, und füge den SSH-Schlüssel des Sicherungshosts der Liste autorisierter SSH-Schlüssel hinzu. Weitere Informationen findest du unter Auf die Verwaltungsshell (SSH) zugreifen. -
Überprüfe mit dem
ghe-host-check
-Befehl die SSH-Verbindung mit Ihre GitHub Enterprise Server-Instance auf dem Sicherungshost../bin/ghe-host-check
-
Führe den folgenden Befehl aus, um eine erste vollständige Sicherung zu erstellen.
./bin/ghe-backup
Weitere Informationen zur erweiterten Verwendung findest du in der README-Datei zu GitHub Enterprise Server Backup Utilities in der GitHub Enterprise Server Backup Utilities-Projektdokumentation.
Aktualisieren von GitHub Enterprise Server Backup Utilities
Wenn du GitHub Enterprise Server Backup Utilities aktualisierst, musst du eine Version auswählen, die mit deiner aktuellen Version von GitHub Enterprise Server funktioniert. Deine Installation von GitHub Enterprise Server Backup Utilities muss mindestens der Version von Ihre GitHub Enterprise Server-Instance entsprechen und darf nicht älter als zwei Versionen davor sein. Weitere Informationen findest du unter Versionsanforderungen für GitHub Enterprise Server in der GitHub Enterprise Server Backup Utilities-Projektdokumentation.
-
Überprüfe die Installationsmethode für GitHub Enterprise Server Backup Utilities. Frühere Versionen von GitHub Enterprise Server Backup Utilities unterstützten die Installation und Updates in einem lokalen Git-Repository, diese Methode wird jedoch nicht mehr unterstützt.
-
Navigiere auf deinem Sicherungshost zu deinem GitHub Enterprise Server Backup Utilities-Verzeichnis, gewöhnlich
backup-utils
. -
Führe den folgenden Befehl aus, um zu überprüfen, ob ein gültiges Arbeitsverzeichnis in einem Git-Repository vorhanden ist.
git rev-parse --is-inside-work-tree
-
-
Um zu bestimmen, wie GitHub Enterprise Server Backup Utilities aktualisiert wird, überprüfe die Ausgabe von
git rev-parse --is-inside-work-tree
.- Wenn die Ausgabe
true
lautet, wurde GitHub Enterprise Server Backup Utilities durch Klonen des Git-Repositorys des Projekts installiert. Um ein Upgrade durchzuführen, kopiere deine vorhandene Konfiguration inbackup.config
, und folge dann den Anweisungen unter Installieren von GitHub Enterprise Server Backup Utilities. - Wenn die Ausgabe
fatal: not a git repository (or any of the parent directories)
lautet, wurde GitHub Enterprise Server Backup Utilities durch Extrahieren einer komprimierten Archivdatei installiert. Folge zum Aktualisieren den Anweisungen unter Installieren vonGitHub Enterprise Server Backup Utilities.
- Wenn die Ausgabe
Backup planen
Warnung: Nach Wiederherstellung einer Sicherung mithilfe von GitHub Enterprise Server Backup Utilities 3.7.0 or 3.8.0 können sich Benutzer*innen möglicherweise nicht bei der Instanz anmelden. Um dieses Problem zu beheben und einen Fehler zu korrigieren, der verhinderte, dass Verschlüsselungsschlüssel für die Geheimnisüberprüfung gesichert werden, aktualisiere deinen Sicherungshost so, dass GitHub Enterprise Server Backup Utilities 3.8.1 verwendet wird, und generiere mit ghe-backup
eine neue vollständige Sicherung. Weitere Informationen zur Verwendung einer vorhandenen Sicherung findest du unter „Bekannte Probleme mit Sicherungen für Instanzen“.
Mithilfe des Befehls cron(8)
oder eines ähnlichen Diensts zum Planen von Befehlen kannst du regelmäßige Backups auf dem Backup-Host planen. Die konfigurierte Sicherungshäufigkeit schreibt die ungünstigste Recovery Point Objective (RPO) in deinem Wiederherstellungsplan vor. Angenommen, du hast das Backup so geplant, dass es täglich um Mitternacht ausgeführt wird. In diesem Fall könntest du in einem Notfallszenario bis zu 24 Stunden an Daten verlieren. Es wird empfohlen, mit einem stündlichen Backup-Plan zu beginnen. Dadurch wird garantiert, dass schlimmstenfalls maximal eine Stunde an Daten am Hauptstandort vernichtet wird.
Wenn sich Backup-Versuche überschneiden, wird der Befehl ghe-backup
mit einer Fehlermeldung abgebrochen. Diese gibt an, dass ein gleichzeitiges Backup vorhanden ist. In diesem Fall wird empfohlen, die Häufigkeit deiner geplanten Sicherungen zu verringern. Weitere Informationen findest du im Abschnitt „Planen von Sicherungen“ der README-Datei zu GitHub Enterprise Server Backup Utilities in der GitHub Enterprise Server Backup Utilities-Projektdokumentation.
Wiederherstellen einer Sicherung
Warnung: Nach Wiederherstellung einer Sicherung mithilfe von GitHub Enterprise Server Backup Utilities 3.7.0 or 3.8.0 können sich Benutzer*innen möglicherweise nicht bei der Instanz anmelden. Um dieses Problem zu beheben und einen Fehler zu korrigieren, der verhinderte, dass Verschlüsselungsschlüssel für die Geheimnisüberprüfung gesichert werden, aktualisiere deinen Sicherungshost so, dass GitHub Enterprise Server Backup Utilities 3.8.1 verwendet wird, und generiere mit ghe-backup
eine neue vollständige Sicherung. Weitere Informationen zur Verwendung einer vorhandenen Sicherung findest du unter „Bekannte Probleme mit Sicherungen für Instanzen“.
Im Falle eines längeren Ausfalls oder eines Notfalls am primären Standort kannst du Ihre GitHub Enterprise Server-Instance wiederherstellen, indem du eine weitere Instanz bereitstellst und einen Wiederherstellungsvorgang über den Sicherungshost ausführst. Du musst der GitHub Enterprise-Zielinstanz den SSH-Schlüssel des Sicherungshosts als autorisierten SSH-Schlüssel hinzufügen, bevor du eine Instanz wiederherstellst.
Wenn du Sicherungswiederherstellungen für Ihre GitHub Enterprise Server-Instance durchführst, kannst du nur Daten aus maximal zwei Featurereleases wiederherstellen. Wenn du beispielsweise eine Sicherung von GitHub Enterprise Server 3.0.x durchführst, kannst du die Sicherung auf einer Instanz wiederherstellen, die GitHub Enterprise Server 3.2.x ausführt. Du kannst keine Daten aus einer Sicherung von GitHub Enterprise Server 2.22.x in einer Instanz wiederherstellen, die 3.2.x ausführt, da dadurch drei Versionen übersprungen würden (2.22 auf 3.0 auf 3.1 auf 3.2). Die Wiederherstellung muss zuerst in einer Instanz erfolgen, die 3.1.x ausführt, und dann auf 3.2.x aktualisiert werden.
Die Netzwerkeinstellungen sind von der Sicherungsmomentaufnahme ausgeschlossen. Nach der Wiederherstellung musst du das Netzwerk auf der GitHub Enterprise Server-Zielinstanz manuell konfigurieren.
Voraussetzungen
- Stelle sicher, dass der Wartungsmodus für die primäre Instanz aktiviert ist und alle aktiven Prozesse abgeschlossen wurden. Weitere Informationen findest du unter Wartungsmodus aktivieren und planen.
- Beende die Replikation auf allen Replikatknoten in einer Hochverfügbarkeitskonfiguration. Weitere Informationen findest du unter Informationen zur Hochverfügbarkeitskonfiguration.
- Stelle eine neue GitHub Enterprise Server-Zielinstanz bereit, um diese als Ziel für die Wiederherstellung deiner Sicherung zu benutzen. Weitere Informationen findest du unter GitHub Enterprise Server-Instanz einrichten.
- Wenn GitHub Actions für Ihre GitHub Enterprise Server-Instance aktiviert ist, musst du den externen Speicheranbieter für GitHub Actions auf der Ersatzinstanz konfigurieren. Weitere Informationen findest du unter Sichern und Wiederherstellen von GitHub Enterprise Server mit aktivierten GitHub Actions.
Starten des Wiederherstellungsvorgangs
Verwende den ghe-restore
-Befehl, um Ihre GitHub Enterprise Server-Instance über deinen Sicherungshost mithilfe der letzten erfolgreichen Momentaufnahme wiederherzustellen. Du kannst die folgenden zusätzlichen Optionen mit ghe-restore
verwenden.
- Das
-c
-Flag überschreibt die Einstellungen, Zertifikate und Lizenzdaten auf dem Zielhost, selbst wenn es bereits konfiguriert ist. Lass dieses Flag weg, wenn du eine Testinstanz für Testzwecke einrichtest und die vorhandene Konfiguration auf dem Ziel beibehalten möchtest. Weitere Informationen findest du im Abschnitt „Verwenden von Sicherungs- und Wiederherstellungsbefehlen“ der GitHub Enterprise Server Backup Utilities-INFODATEI im Repository „github/backup-utils“. - Mit dem
-s
-Flag kannst du eine andere Backup-Momentaufnahme auswählen.
Nachdem du ghe-restore
ausgeführt hast, bestätigt der Befehl die Wiederherstellung und gibt dann Details und den Status während des Vorgangs aus.
$ 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.
Optional kannst du zur Validierung der Wiederherstellung eine IP-Ausnahmeliste konfigurieren, um den Zugriff auf eine bestimmte Liste von IP-Adressen zuzulassen. Weitere Informationen findest du unter Wartungsmodus aktivieren und planen.
Auf einer Instanz in einer Hochverfügbarkeitskonfiguration meldet ghe-repl-status
nach der Wiederherstellung auf neuen Datenträgern auf einer vorhandenen oder leeren Instanz möglicherweise, dass die Git- oder Alambic-Replikation aufgrund veralteter Server-UUIDs nicht synchron ist. Diese veralteten UUIDs können das Ergebnis eines außer Betrieb genommenen Knotens in einer Hochverfügbarkeitskonfiguration sein, der weiterhin in der Anwendungsdatenbank, aber nicht in der wiederhergestellten Replikationskonfiguration vorhanden ist.
Für die Bereinigung nach Abschluss der Wiederherstellung und vor dem Start der Replikation kannst du veraltete UUIDs mithilfe von ghe-repl-teardown
entfernen. Wenn Sie weitere Unterstützung benötigen, gehen Sie zu GitHub Enterprise Support.