GitHub sollte an erster Stelle stehen, wenn es um Ihre Datensicherung geht

Fragen Sie die meisten IT- oder Plattformteams, was ihre oberste Priorität beim Backup ist, und Sie werden immer dieselbe Liste hören: E-Mail, Dateifreigaben, ERP-Software und natürlich die Infrastruktur (Hardware, Software und Netzwerkkomponenten). GitHub rangiert in der Regel irgendwo im Mittelfeld oder wird mit folgenden Worten abgetan: „GitHub repliziert sich selbst, da brauchen wir keine Sorge.“ 

Diese Rangfolge ist ein Überbleibsel aus einer anderen Ära. GitHub ist mittlerweile das wertvollste und schnellste System zur Datenerfassung in den meisten Entwicklungsabteilungen und gehört an die Spitze der Prioritätenliste für Backups – noch vor E-Mails, Dateifreigaben und den meisten in der Cloud gehosteten Anwendungen. 

Warum GitHub an die Spitze sprang 

Was sich in GitHub befindet, hat sich verändert. Eine moderne GitHub-Organisation enthält den Betriebsplan des Unternehmens: Anwendungscode, Infrastructure-as-Code, CI/CD-Pipelines, Bereitstellungskonfigurationen, Runbooks, Sicherheitsrichtlinien, kundenorientierte SDKs, KI-Prompts und zunehmend auch die Agentendefinitionen, die die tägliche Entwicklungsarbeit automatisieren. Früher bedeutete der Verlust eines Repos den Verlust von etwas Code. Heute kann der Verlust eines Repos den Verlust der Spezifikation für die Arbeitsweise des Unternehmens bedeuten. 

Die Arbeitsgeschwindigkeit stieg dramatisch an. Mit Copilot, Cursor und Claude Code in den täglichen Arbeitsabläufen erzeugt eine Organisation mit 50 Entwicklern, die im Jahr 2023 täglich 200 Commits produzierte, nun routinemäßig 600–1.000. Agenten führen Commits über Nacht durch. Agenten führen Commits am Wochenende durch. Was früher eine Woche in Anspruch nahm, lässt sich nun an einem Tag erstellen – was auch bedeutet, dass ein einziger zerstörerischer Vorfall mehr Arbeit zunichte machen kann als je zuvor. 

Die Ausfallmöglichkeiten haben sich verschlimmert. Die nativen Schutzmechanismen von GitHub (Zweigschutz, Replikation, das 90-tägige Zeitfenster für gelöschte Repos) sind zwar vorhanden, aber begrenzt. Sie bieten keinen Schutz vor einem Force-Push, den GitHub als legitim ansieht, da er von einem authentifizierten Dienstkonto stammt. Sie bieten keinen Schutz vor einem Agenten, der die Datei „.github/workflows“ so umschreibt, dass eine Schleife entsteht, die Release-Artefakte zerstört. Sie bieten keinen Schutz vor einem kompromittierten persönlichen Zugriffstoken, das um 3:00 Uhr morgens zum Löschen von 200 Branches verwendet wird. 

Was ein GitHub-Backup tatsächlich überstehen muss 

Die entscheidenden zerstörerischen Ereignisse sind meist nicht böswillig. Sie sind alltäglicher Natur, und das Zeitalter der Agenten hat sie noch häufiger gemacht: 

• Ein Bereinigungs-Agent löscht Zweige, die veraltet schienen, es aber nicht waren.&
• Ein Refactor-Agent führt nach einem fehlerhaften Rebase einen Force-Push in den „main“-Zweig durch. 
• Ein Migrationsskript schreibt die Historie in einem Dutzend Repos um. 
• Ein kompromittiertes Agent-Token wird verwendet, um Branches, Tags oder Releases zu löschen, bevor es jemand bemerkt. 
• Ein CI-Workflow führt einen zerstörerischen Git-Befehl aus, den ein Agent generiert hat. 

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

Ein theoretisches Beispiel 

Ein mittelständisches Fintech-Unternehmen betreibt 18 Repos auf GitHub, die jede Nacht gesichert werden. Das Unternehmen verfügt über einen Programmier-Agenten, der Tests durchführt und automatisierte Korrekturen organisationsweit anwendet. Dieser ist mit einem Dienstkonto authentifiziert, das über Administratorrechte für das Haupt-Monorepo verfügt, da die Einrichtung feinkörniger Berechtigungen erst im nächsten Quartal geplant war. 

Am Samstag um 2:00 Uhr morgens stößt der Agent bei der Verarbeitung eines umfangreichen Pull-Requests auf einen Fehler in seiner Rebase-Logik. Er führt einen erzwungenen Push einer umgeschriebenen Historie in den „main“-Zweig durch und verwirft dabei 142 Commits aus der vergangenen Woche, darunter drei Produktions-Hotfixes, die bereits in der Produktionsumgebung laufen. Niemand beobachtet den Vorgang. Keine Regel zum Zweigschutz blockiert den Push. 

Das Team bemerkt den Vorfall am Montagmorgen. Die letzte funktionierende Sicherung wurde am Freitag um Mitternacht durchgeführt. Zwischen diesem Snapshot und dem Vorfall hatte der Agent 47 PRs zusammengeführt. Alle 47 sind aus der Quellcodeverwaltung verschwunden. Die Hotfixes sind zwar weiterhin in der Produktion aktiv, doch die „Source of Truth“ dafür existiert in keinem Repository mehr. 

Die Wiederherstellung dauert drei Tage. Zwei der Hotfixes lassen sich nicht sauber neu erstellen und müssen von Grund auf neu geschrieben werden. Ein stündliches Backup hätte den Verlust auf 47 Minuten Arbeitszeit begrenzt. 

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

Wenn GitHub Ihre oberste Priorität bei der Datensicherung ist, muss die Lösung vier Anforderungen erfüllen: 

Eine hohe Sicherungsfrequenz. In der Backup-Branche wird der Begriff RPO (Recovery Point Objective). Im Klartext ausgedrückt: Es gibt an, wie viel Arbeit Sie bereit sind zu verlieren, falls etwas ausfällt – gemessen in Zeit. Wenn Ihre Sicherung jede Nacht läuft, beträgt Ihr RPO 24 Stunden. Für GitHub im Zeitalter der Agenten ist eine nächtliche Sicherung zu langsam. Stündlich ist das Minimum. Bei kritischen Monorepos sind 30 Minuten vertretbar. Fragen Sie jeden Anbieter, wie hoch seine Mindesthäufigkeit ist und ob diese für das gesamte Repo (einschließlich Issues, PRs und Einstellungen) oder nur für den Code gilt. 

Vollständige Abdeckung. Das Sichern von Code allein verwandelt einen vierstündigen Vorfall in einen viertägigen. Sie benötigen Issues, PRs, Diskussionen, Actions-Workflows, Releases, LFS-Objekte, Branch-Schutzregeln sowie Einstellungen auf Organisationsebene wie Teammitgliedschaften und App-Installationen. Der Verlust von .github/workflows allein kann bereits den Verlust der Konfiguration der Agenten bedeuten, auf die Sie angewiesen sind. 

Unveränderlichkeit. Ein kompromittiertes Admin-Token, mit dem ein Repo gelöscht werden kann, kann oft auch das Backup löschen, wenn das Backup-System denselben Anmeldedaten vertraut. Air-Gapped- oder objektgesperrte Kopien sind kein optionales Extra. Sie machen den Unterschied zwischen einem schlechten Tag und einem Albtraum, bei dem alles von den Laptops der Entwickler neu aufgebaut werden muss. 

Getestete Wiederherstellung. Stellen Sie mindestens einmal pro Quartal ein nicht kritisches Repo durchgängig wieder her. Messen Sie, wie lange dies tatsächlich dauert. Ein Backup, aus dem Sie noch nie eine Wiederherstellung durchgeführt haben, ist eine Vermutung, kein Plan. 

Der Wandel 

Die meisten Unternehmen sichern GitHub unter der Annahme, dass es sich um ein Code-Repository mit einigen angehängten sekundären Artefakten handelt. Das entspricht nicht mehr dem, was GitHub heute ist. Es ist das schnelllebigste Betriebssystem, das die meisten Unternehmen einsetzen, und die Geschwindigkeit, mit der es Wert schafft, hat die Backup-Strategie überholt, die die meisten Teams übernommen haben. 

Rücken Sie GitHub an die Spitze der Prioritätenliste. Eine aggressive Backup-Frequenz, vollständige Abdeckung, Unveränderlichkeit und getestete Wiederherstellung sind die Merkmale, die diese Priorität mit Leben füllen. Ohne sie ist „wir sichern GitHub“ lediglich ein Häkchen auf einer Checkliste und kein Plan.