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 deine GitHub Enterprise Server-Instanz 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 deine GitHub Enterprise Server-Instanz 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 deine GitHub Enterprise Server-Instanz 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 | 2 |
Memory | 2 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, empfehlen wir, die relevante % data variables.product.prodname_enterprise_backup_utilities %} Version als komprimiertes Archiv herunterzuladen und dann den Inhalt zu extrahieren und zu installieren. Weitere Informationen finden Sie unter Erste Schritte im Github/backup-utils-Repository.
Durch das Herunterladen der Version als komprimiertes Archiv wird sichergestellt, dass Sie die richtige Version von GitHub Enterprise Server Backup Utilities für deine GitHub Enterprise Server-Instanz verwenden und dass Ihre vorhandene Sicherungskonfigurationsdatei backup.config
bei der Installation einer neuen Version beibehalten wird.
Sicherungsmomentaufnahmen werden in den Datenträgerpfad geschrieben, der von der GHE_DATA_DIR
-Datenverzeichnisvariable in deiner backup.config
-Datei festgelegt wurde. 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.-
Lege den
GHE_HOSTNAME
-Wert auf den Hostnamen oder die IP-Adresse deiner primären GitHub Enterprise Server-Instanz fest.Hinweis: Wenn deine GitHub Enterprise Server-Instanz als Cluster oder in einer Hochverfügbarkeitskonfiguration mithilfe eines Lastenausgleichs bereitgestellt wird, kann
GHE_HOSTNAME
der Hostname des Lastenausgleichs sein, solange er (auf Port 122) SSH-Zugriff auf deine GitHub Enterprise Server-Instanz 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 auszuwählen, der sich in demselben Dateisystem wie dein Sicherheitshost befindet, aber außerhalb des Pfads, in den du das Git-Repository in Schritt 1 geklont hast.
-
-
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 deine GitHub Enterprise Server-Instanz 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 deine GitHub Enterprise Server-Instanz 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. Du kannst GitHub Enterprise Server Backup Utilities in einem Git-Repository aktualisieren, indem du die neuesten Änderungen abrufst und auscheckst.
Falls du kein Git-Repository für deine Installation verwendest, kannst du ansonsten auch ein neues Archiv extrahieren oder deinen Ansatz ändern, um stattdessen ein Git-Repository zu verwenden.
Überprüfen des Installationstyps
Du kannst die Installationsmethode für GitHub Enterprise Server Backup Utilities überprüfen und die beste Möglichkeit für die Aktualisierung deiner Installation ermitteln.
-
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
Wenn die Ausgabe
true
lautet, wurde GitHub Enterprise Server Backup Utilities durch Klonen des Git-Repositorys des Projekts installiert. Wenn die Ausgabefatal: not a git repository (or any of the parent directories)
lautet, wurde GitHub Enterprise Server Backup Utilities wahrscheinlich durch Extrahieren einer komprimierten Archivdatei installiert. Wenn sich deine Installation in einem Git-Repository befindet, kannst du die neueste Version mithilfe von Git installieren. Wenn die Installation aus einer komprimierten Archivdatei stammt, kannst du entweder die neueste Version herunterladen und extrahieren oder GitHub Enterprise Server Backup Utilities mithilfe von Git neu installieren, um zukünftige Upgrades zu vereinfachen.
- Aktualisieren einer Installation in einem Git-Repository
- Aktualisieren mit Git statt mit komprimierten Archiven
Aktualisieren einer Installation in einem Git-Repository
- Navigiere auf deinem Sicherungshost zu deinem GitHub Enterprise Server Backup Utilities-Verzeichnis, gewöhnlich
backup-utils
.
Hinweis: Es wird empfohlen, vor der Aktualisierung von GitHub Enterprise Server Backup Utilities eine Kopie der vorhandenen backup.config
-Datei an einem temporären Speicherort zu erstellen (z. B. $HOME/backup.config
).
-
Führe den
git fetch
-Befehl aus, um die neuesten Projektupdates herunterzuladen.git fetch
-
Zum Aktualisieren auf die neueste Projektreleaseversion verwende den
stable
-Branch, indem du dengit checkout stable
-Befehl ausführst.git checkout stable
Falls du eine bestimmte Projektversion verwenden möchtest, kannst du alternativ den folgenden Befehl ausführen, wobei du
X.Y.Z
durch die gewünschte Releaseversion ersetzt.git checkout vX.Y.Z
-
Führe den folgenden Befehl aus, um zu überprüfen, ob das Upgrade erfolgreich war.
./bin/ghe-backup --version
-
Führe den folgenden Befehl aus, um die SSH-Konnektivität zwischen deinen konfigurierten GitHub Enterprise Server-Instanzen zu überprüfen.
./bin/ghe-host-check
Aktualisieren mit Git statt mit komprimierten Archiven
Wenn dein Sicherungshost über eine Internetverbindung verfügt und du zuvor ein komprimiertes Archiv (.tar.gz
) zum Installieren oder Aktualisieren von GitHub Enterprise Server Backup Utilities verwendet hast, empfehlen wir, für deine Installation stattdessen ein Git-Repository zu verwenden. Das Aktualisieren mit Git ist weniger arbeitsaufwendig, und deine Sicherungskonfiguration wird beibehalten.
Wenn du Git anstelle eines komprimierten Archivs für Upgrades verwenden möchtest, musst du deine vorhandene Konfiguration sichern, das Repository klonen, deine Konfiguration an die richtige Stelle kopieren, die Installation überprüfen, die SSH-Konnektivität überprüfen und dann die alte Installation löschen.
-
Navigiere auf deinem Sicherungshost zu deinem GitHub Enterprise Server Backup Utilities-Verzeichnis, gewöhnlich
backup-utils
. -
Wenn du die vorhandene GitHub Enterprise Server Backup Utilities-Installation sichern möchtest, kopiere die aktuelle
backup.config
-Datei an einen sicheren Speicherort, z. B. dein Stammverzeichnis.cp backup.config $HOME/backup.config.saved-$(date +%Y%m%d-%H%M%S)
-
Ändere das lokale Verzeichnis auf deinem Sicherungshost, in dem du das Git-Repository für GitHub Enterprise Server Backup Utilities installieren möchtest.
-
Führe den folgenden Befehl aus, um das Projektrepository in das Verzeichnis auf deinem Sicherungshost zu klonen.
git clone https://github.com/github/backup-utils.git
-
Führe den folgenden Befehl aus, um in das geklonte Repository zu wechseln.
cd backup-utils
-
Zum Aktualisieren auf die neueste Projektreleaseversion verwende den
stable
-Branch, indem du dengit checkout stable
-Befehl ausführst.git checkout stable
Falls du eine bestimmte Projektversion verwenden möchtest, kannst du alternativ den folgenden Befehl ausführen, wobei du
X.Y.Z
durch die gewünschte Releaseversion ersetzt.git checkout vX.Y.Z
-
Kopiere die vorhandene Sicherungskonfigurationsdatei in das lokale Repositoryverzeichnis, um deine vorherige Sicherungskonfiguration wiederherzustellen. Ersetze den Pfad im Befehl durch den Speicherort der Datei, die in Schritt 2 gespeichert wurde.
cp PATH/TO/BACKUP/FROM/STEP/2 backup.config
Hinweis: Du kannst auswählen, wo deine Sicherungskonfigurationsdatei nach dem Klonen wiederhergestellt werden soll. Weitere Informationen zum Speicherort von Konfigurationsdateien findest du unter Erste Schritte in der GitHub Enterprise Server Backup Utilities-Projektdokumentation.
-
Um zu bestätigen, dass die Pfade zu Verzeichnissen oder Skripts in deiner Sicherungskonfigurationsdatei richtig sind, überprüfe die Datei in einem Text-Editor.
-
Führe den folgenden Befehl aus, um zu überprüfen, ob das Upgrade erfolgreich war.
./bin/ghe-backup --version
-
Führe den folgenden Befehl aus, um die SSH-Konnektivität zwischen deinen konfigurierten GitHub Enterprise Server-Instanzen zu überprüfen.
./bin/ghe-host-check
-
Vergewissere dich, dass deine Sicherungsdaten nicht im Verzeichnis für die alte Installation gespeichert sind.
-
Lösche dein altes GitHub Enterprise Server Backup Utilities-Verzeichnis aus Schritt 1 (wo sich die komprimierte Archivinstallation befindet).
Backup planen
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
Im Falle eines längeren Ausfalls oder eines Notfalls am primären Standort kannst du deine GitHub Enterprise Server-Instanz 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 deine GitHub Enterprise Server-Instanz 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.
- Wenn GitHub Actions für deine GitHub Enterprise Server-Instanz 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 deine GitHub Enterprise Server-Instanz ü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 du weitere Unterstützung benötigst, wenden dich an den GitHub Enterprise Support.