GitHub sollte die Nummer 1 sein, die Sie sichern

Fragen Sie die meisten IT- oder Plattform-Teams, was ihre oberste Backup-Priorität ist, und Sie werden die gleiche Liste hören: E-Mail, Dateifreigaben, ERP-Software und natürlich die Infrastruktur (Hardware, Software und Netzwerkkomponenten). GitHub liegt in der Regel irgendwo in der Mitte oder wird abgewunken mit dem Hinweis: "GitHub repliziert sich selbst, uns geht es gut."

Dieses Ranking ist ein Überbleibsel aus einer anderen Ära. GitHub ist heute das wertvollste System mit der höchsten Geschwindigkeit in den meisten technischen Unternehmen und gehört an die Spitze der Prioritätenliste für die Datensicherung, noch vor E-Mail, Dateifreigaben und den meisten in der Cloud gehosteten Anwendungen.

Warum GitHub den Sprung an die Spitze schaffte

Was in GitHub lebt, hat sich geändert. Eine moderne GitHub-Organisation enthält den operativen Bauplan des Unternehmens: Anwendungscode, Infrastructure-as-Code, CI/CD-Pipelines, Deployment-Konfigurationen, Runbooks, Sicherheitsrichtlinien, SDKs für Kunden, KI-Anweisungen und zunehmend auch die Agentendefinitionen, die das tägliche Engineering automatisieren. Früher bedeutete der Verlust eines Repo den Verlust von Code. Heute kann der Verlust eines Repo den Verlust der Spezifikation dafür bedeuten, wie das Unternehmen arbeitet.

Die Geschwindigkeit ist dramatisch gestiegen. Mit Copilot, Cursor und Claude Code in den täglichen Arbeitsabläufen produziert eine Organisation mit 50 Ingenieuren, die im Jahr 2023 noch 200 Commits pro Tag produzierte, heute routinemäßig 600-1.000. Agents machen Commits in der Nacht. Die Agenten arbeiten das ganze Wochenende hindurch. Was früher eine Woche dauerte, kann heute an einem Tag erstellt werden. Das bedeutet auch, dass ein einziger zerstörerischer Vorfall mehr Arbeit vernichten kann als je zuvor.

Die Fehlermodi haben sich verschlimmert. Die nativen Schutzmechanismen von GitHub (Branch Protection, Replikation, das 90-Tage-Fenster für gelöschte Repos) sind real, aber begrenzt. Sie schützen nicht vor einem Force Push, den GitHub für legitim hält, weil er von einem authentifizierten Dienstkonto stammt. Sie erholen sich nicht von einem Agenten, der .github/workflows in eine Schleife umschreibt, die Release-Artefakte vernichtet. Sie werden nicht wiederhergestellt, wenn ein kompromittiertes persönliches Zugriffstoken verwendet wird, um 200 Zweige um 3:00 Uhr morgens zu löschen.

Was ein GitHub-Backup tatsächlich überleben muss

Die zerstörerischen Ereignisse, auf die es ankommt, sind meist nicht bösartig. Sie sind alltäglich und durch die Ära der Agenten sind sie häufiger geworden:

• Ein Aufräum-Agent löscht Zweige, die veraltet aussehen, es aber nicht sind.
• Ein Refactor-Agent erzwingt nach einem schlechten Rebase einen Push auf Main.
• Ein Migrationsskript schreibt die Historie über ein Dutzend Repos hinweg neu.
• Ein kompromittiertes Agent-Token wird verwendet, um Zweige, Tags oder Versionen zu löschen, bevor es jemand merkt.
• Ein CI-Workflow führt einen destruktiven Git-Befehl aus, den ein Agent generiert hat.

In jedem Fall sieht der Schaden für GitHub legitim aus. Er wurde authentifiziert. Er war autorisiert. Die Schutzmechanismen von GitHub haben keine Möglichkeit zu erkennen, dass der Push falsch war.

Ein theoretisches Beispiel

Ein mittelgroßes Finanzunternehmen betreibt 18 Repos auf GitHub, die jede Nacht gesichert werden. Sie haben einen Coding Agent, der Tests durchführt und automatisierte Korrekturen in der gesamten Organisation vornimmt. Er ist mit einem Dienstkonto authentifiziert, das über Administratorrechte für das Hauptmonorepo verfügt, da feinkörnige Berechtigungen ein Projekt für die Zukunft sind.

Samstag um 2:00 Uhr morgens stößt der Agent bei der Verarbeitung eines großen PRs auf einen Fehler in seiner Rebase-Logik. Er schiebt eine umgeschriebene Historie nach main und verwirft dabei 142 Commits aus der Vorwoche, darunter drei Produktions-Hotfixes, die bereits in prod laufen. Kein Mensch sieht zu. Keine Zweigschutzregel blockiert den Push.

Das Team findet es am Montagmorgen heraus. Das letzte gute Backup lief Freitag um Mitternacht. Zwischen diesem Snapshot und dem Vorfall hatte der Agent 47 PRs zusammengeführt. Alle 47 sind aus der Versionskontrolle verschwunden. Die Hotfixes sind immer noch in der Produktion aktiv, aber die Quelle der Wahrheit für sie existiert in keinem Repo mehr.

Die Wiederherstellung dauert drei Tage. Zwei der Hotfixes können nicht sauber wiederhergestellt werden und müssen von Grund auf neu geschrieben werden. Ein stündliches Backup hätte den Verlust auf 47 Minuten Arbeit begrenzt.

Worauf Sie bei einer GitHub-Backup-Lösung achten sollten

Wenn GitHub Ihre Backup-Priorität Nr. 1 ist, braucht die Lösung vier Dinge:

Aggressive Backup-Kadenz. Die Backup-Tools verwenden den Begriff RPO (Recovery Point Objective). Im Klartext bedeutet dies, wie viel Arbeit Sie bereit sind zu verlieren, wenn etwas kaputt geht, gemessen in Zeit. Wenn Ihr Backup nachts läuft, beträgt Ihr RPO 24 Stunden. Für GitHub in der Ära der Agenten ist eine nächtliche Sicherung zu langsam. Stündlich ist die Untergrenze. Dreißig Minuten sind für kritische Monorepos vertretbar. Fragen Sie jeden Anbieter nach seiner Mindestkadenz und danach, ob sie für das gesamte Repo (einschließlich Issues, PRs und Einstellungen) oder nur für den Code gilt.

Ganzflächige Abdeckung. Die Sicherung von Code allein macht aus einem vierstündigen Vorfall einen viertägigen. Sie brauchen Themen, PRs, Diskussionen, Actions-Workflows, Releases, LFS-Objekte, Regeln für den Schutz von Zweigen und Einstellungen auf Orgebene wie Team-Mitgliedschaft und App-Installationen. Allein der Verlust von .github/workflows kann den Verlust der Konfiguration der Agenten bedeuten, auf die Sie angewiesen sind.

Unveränderlichkeit. Ein kompromittierter Admin-Token, der ein Repo löschen kann, kann oft auch das Backup löschen, wenn das Backup-System denselben Anmeldeinformationen vertraut. Air-gapped oder objektgesperrte Kopien sind nicht optional. Sie sind der Unterschied zwischen einem schlechten Tag und einem Alptraum, den Entwickler-Laptops wiederherzustellen.

Getestete Wiederherstellung. Stellen Sie mindestens einmal im Quartal ein nicht kritisches Repository vollständig wieder her. Messen Sie, wie lange es tatsächlich dauert. Ein Backup, von dem Sie noch nie eine Wiederherstellung durchgeführt haben, ist eine Vermutung, kein Plan.

Der Wandel

Die meisten Unternehmen sichern GitHub in der Annahme, dass es sich um ein Code-Repository mit einigen sekundären Artefakten handelt. Das ist GitHub aber nicht mehr. Es ist das schnellste operative System, das die meisten Unternehmen betreiben, und die Geschwindigkeit, mit der es Werte anhäuft, hat die von den meisten Teams geerbte Backup-Struktur überholt.

Setzen Sie GitHub an die Spitze der Prioritätenliste. Aggressive Backup-Kadenz, flächendeckende Sicherung, Unveränderbarkeit und getestete Wiederherstellung sind die Merkmale, die diese Priorität Wirklichkeit werden lassen. Ohne sie ist "wir sichern GitHub" ein Kästchen, kein Plan.

>