Letzte Woche kam nichts von mir, weil ich mit ein paar Kumpels auf der AIDAbella unterwegs war, Kiel–Aarhus–Göteborg–Kiel. Deshalb schreibe ich heute direkt über das, was mich dieses Wochenende beschäftigt hat: für mein Agenten-System ein Git Remote einrichten und es so auf ein echtes Backup-System umzustellen.
Wie es vorher aussah
Die komplette Versionsgeschichte meines Agenten-Systems lag bisher ausschließlich an einem einzigen Ort: auf meinem Server. Als Absicherung diente ein ZIP-Snapshot auf Google Drive.
Das fühlt sich beruhigend an. Ein Blick auf die Datei in der Cloud, und der Gedanke: Passt schon, es gibt ja ein Backup.
Es ist aber nur die halbe Absicherung.
Warum ein ZIP nicht reicht
Um das zu verstehen, hilft die Frage, was im Ernstfall passiert. Geht auf dem Server etwas schief oder verrennt man sich beim Weiterentwickeln, nützt ein ZIP-Archiv erstaunlich wenig.
1. Ein ZIP ist nur ein Standbild
Ein ZIP-Archiv hält den Zustand von genau einem bestimmten Tag fest. Alles, was danach passiert, fehlt. Wer das Archiv nicht regelmäßig erneuert, steht im Schadensfall mit veralteten Daten da. Das Tückische daran: Es fällt erst im Ernstfall auf.
2. Es beantwortet die entscheidenden Fragen nicht
Ein Snapshot zeigt das Resultat, aber nie den Weg dorthin. Die Frage, wann genau ein Fehler entstanden ist und wie der funktionierende Stand davor aussah, beantwortet ein ZIP-Ordner nicht. Bei Automatisierungen, die selbstständig laufen, wird genau diese Nachvollziehbarkeit irgendwann wichtig.
3. Fällt der Server aus, ist das Protokoll weg
Git führt Buch über jede einzelne Änderung. Liegt dieses Buch nur auf dem Hauptserver, geht es bei einem Ausfall gemeinsam mit den Daten verloren. Ein Git Remote ist die automatische Spiegelung an einem zweiten Ort, ohne dass im Alltag jemand daran denken muss.
Was Git eigentlich macht
Git ist ein Änderungsprotokoll für Dateien. Jedes Mal, wenn ein Stand festgehalten wird, entsteht ein Eintrag, im Fachwort ein Commit. Dazu gehören ein exakter Zeitpunkt, eine kurze Beschreibung und die genaue Veränderung gegenüber dem Stand davor. Ein Projektordner samt diesem Protokoll heißt Repository.
Wer nicht programmiert, kann sich das wie ein Kassenbuch vorstellen. Dort steht nicht nur der aktuelle Kontostand, sondern jede einzelne Buchung. So lässt sich jeder frühere Zustand wiederherstellen, und es bleibt nachvollziehbar, wann etwas geändert wurde.
Drei weitere Begriffe kommen im Artikel vor:
- Branch: ein Nebenzweig, auf dem an etwas gearbeitet wird, ohne den stabilen Hauptstand anzufassen.
- Tag: eine feste Markierung für einen bestimmten Stand, etwa eine fertige Version.
- Remote: ein Repository an einem zweiten Ort, zum Beispiel bei GitHub, das mit dem ersten abgeglichen wird.
Git Remote einrichten in vier Schritten
So läuft es ab, wenn du einen Git Remote einrichten willst, Schritt für Schritt.
Schritt 1: Historie auf Zugangsdaten prüfen
Bevor Code auf einen fremden Server hochgeladen wird, muss sicher sein, dass keine Zugangsdaten darin stecken. Ein API-Key oder ein Passwort, das vor drei Monaten für fünf Minuten im Code stand, bleibt in der Git-Historie erhalten, selbst wenn die Datei im aktuellen Stand längst gelöscht ist.
Geprüft wird die komplette Historie, nicht nur der aktuelle Stand, und zwar auf drei Wegen:
- Nach der Form: Schlüssel folgen oft einem typischen Muster. Danach lässt sich gezielt suchen.
- Nach dem Wert: Die tatsächlich genutzten Zugangsdaten werden gegen die Historie gehalten. Taucht ein echter Wert auf, wird er gefunden, egal wie er aussieht.
- Nach der Zufälligkeit: Zeichenfolgen, die wie Zufall aussehen, fallen in normalem Text und Code auf und weisen oft auf Schlüssel hin.
Findet sich etwas, reicht Löschen nicht. Der betroffene Schlüssel muss ausgetauscht werden, bevor etwas hochgeladen wird.
Schritt 2: Privates Repository anlegen
Auf GitHub wird ein privates, leeres Repository angelegt. Danach wird es als Remote eingetragen und der komplette Ist-Zustand hochgeladen: alle Commits, alle Branches, alle Tags. Am zweiten Ort liegt dann nicht nur der aktuelle Stand, sondern die gesamte Geschichte.
Schritt 3: Automatischer Push nach jedem Commit
Ein Backup, an das man manuell denken muss, wird irgendwann vergessen. Deshalb läuft der Upload nach jedem Commit automatisch im Hintergrund. Danach einmal testen, ob der Upload wirklich von selbst läuft.
Schritt 4: Zugriff eng halten
Der Server muss auf GitHub zugreifen können, aber nicht auf den ganzen Account. Die Lösung heißt Deploy Key: ein SSH-Schlüsselpaar, das exklusiv für dieses eine Repository gilt. Wird der Server einmal geknackt, kommt ein Angreifer nur an dieses eine Repository und nicht an den restlichen Account. Ein früher genutzter Account-Schlüssel wird danach entfernt.
Fazit
Ein Backup verdient seinen Namen erst, wenn es an einem anderen Ort liegt, die lückenlose Historie abbildet und sich vollautomatisch synchronisiert. Ein ZIP-Snapshot auf Google Drive ist besser als nichts, mehr aber auch nicht. Nach dem Git Remote einrichten sichert sich das System bei jeder einzelnen Änderung selbst
FAQ – Häufig gestellte Fragen zu Git Remote einrichten: Warum ein ZIP-Backup nicht reicht
Was ist ein Git Remote?
Eine zweite Kopie eines Git-Repositorys an einem externen Ort, zum Beispiel auf GitHub. Änderungen werden dorthin hochgeladen, sodass sich der Stand bei einem Hardwareausfall wiederherstellen lässt.
Warum reicht ein ZIP-Backup nicht aus?
Ein ZIP hält nur den Tag der Erstellung fest. Spätere Änderungen fehlen, und wann ein Fehler entstanden ist, lässt sich nicht nachvollziehen. Ein Remote enthält die komplette Historie.
Muss die Historie vor dem Upload geprüft werden?
Ja. Passwörter oder API-Keys, die einmal im Code standen, bleiben in früheren Commits sichtbar. Deshalb wird die gesamte Historie vor dem Upload nach Zugangsdaten durchsucht.
Was ist ein Deploy Key?
Ein SSH-Schlüssel, der den Zugriff auf ein einzelnes Repository beschränkt. Der restliche Account bleibt damit geschützt.
Wie oft wird gesichert?
Vollautomatisch nach jedem einzelnen Commit. Manuell muss nichts angestoßen werden.
