Warum Git allein kein Backup ist – Quellcode, CI/CD und der falsche Sicherheitsglaube

In vielen Softwareprojekten gilt Git als zentrale Absicherung: Quellcode ist versioniert, Änderungen sind nachvollziehbar, Releases lassen sich über Tags rekonstruieren. Dieses Setup vermittelt Sicherheit – führt aber häufig zu einer falschen Annahme:

Der Code liegt in Git, also ist das Projekt gesichert.

In der Praxis greift dieses Verständnis zu kurz. Moderne Anwendungen bestehen nicht nur aus Quellcode, sondern aus einer Vielzahl weiterer Komponenten, die für Betrieb und Wiederherstellung entscheidend sind. Fehlen diese, existiert zwar ein Repository – aber kein lauffähiges System.

Git und Backup – eine klare Abgrenzung

Git ist ein Werkzeug zur Versionskontrolle. Es erfüllt diese Aufgabe sehr zuverlässig:

• Versionierung von Quellcode
• Nachvollziehbarkeit von Änderungen
• Zusammenarbeit über Branches und Merge Requests
• Abbildung von Releases über Tags

Was Git nicht leistet, ist die vollständige Absicherung eines Systems. Insbesondere schützt Git nicht vor:

• Verlust oder Löschung von Repositories
• Ablauf von CI/CD-Artefakten und Logs
• fehlenden Konfigurationswerten oder Secrets
• nicht reproduzierbaren Builds
• Datenverlust in Datenbanken oder Object Storage
• Problemen im Build- und Release-Prozess ausserhalb des Repositories

Git ist damit ein zentraler Baustein – aber kein Ersatz für ein Backup- oder Wiederherstellungskonzept.

Warum Wiederherstellung in der Praxis oft scheitert

Ein typischer moderner Applikations-Stack besteht aus mehreren Ebenen:

• Anwendungslogik (Services, Jobs, Queues)
• Benutzeroberflächen oder APIs
• Datenbanken
• CI/CD-Pipelines
• Deployment-Mechanismen (Container oder klassische Deployments)
• Object Storage für Dateien, Artefakte oder Backups

Geht bei einem Incident nur ein Teil davon verloren, zeigt sich schnell, dass ein Repository allein nicht ausreicht. Entscheidend sind Fragen wie:

• Wo liegt die produktive Konfiguration?
• Wie werden Secrets bereitgestellt und gesichert?
• Ist ein Build reproduzierbar, inklusive Abhängigkeiten und Laufzeitumgebung?
• Existieren Artefakte oder Images, die einem konkreten Release entsprechen?
• Wie lässt sich der Datenstand konsistent wiederherstellen?
• Wie lange dauert eine realistische Wiederherstellung?

Ohne klare Antworten darauf bleibt Versionskontrolle ein organisatorischer Vorteil – aber keine Grundlage für einen erfolgreichen Restore.

CI/CD ist kein Archiv

CI/CD-Systeme werden häufig implizit als Ablage genutzt. Das funktioniert, solange keine Störung auftritt.

In der Praxis werden Logs und Build-Artefakte in CI/CD-Plattformen nur für einen begrenzten Zeitraum aufbewahrt – abhängig von Plattform und Konfiguration. Standardmässig beträgt die Aufbewahrungsdauer bei GitHub Actions 90 Tage (konfigurierbar je nach Repository oder Organisation). Nach Ablauf dieser Retention werden Artefakte und Logs automatisch gelöscht, sofern keine explizite Archivierung erfolgt.

Betroffen sind unter anderem:

• Build-Artefakte
• Test- und Coverage-Reports
• Debug-Logs
• Zwischenstände von Releases

Ein konkretes Beispiel: Bei GitHub Actions unterliegen Artefakte und Logs standardmässig einer konfigurierbaren, zeitlich begrenzten Aufbewahrung und werden danach automatisch entfernt.

Wer sich darauf verlässt, im Ernstfall Artefakte aus der Pipeline zu beziehen, nutzt kein Backup, sondern eine temporäre Ablage mit Ablaufdatum.

Secrets als kritischer Faktor bei der Wiederherstellung

Ein häufiger Engpass bei Restores sind Konfigurationswerte und Secrets. Sie gehören aus guten Gründen nicht ins Repository – fehlen sie jedoch, ist eine Wiederherstellung oft unmöglich.

Ein klassisches Beispiel ist ein zentraler Applikations- oder Verschlüsselungsschlüssel. Geht dieser verloren oder wird ersetzt, sind verschlüsselte Daten, Sessions oder Tokens nicht mehr lesbar. Das betrifft nicht nur Sicherheit, sondern unmittelbar die Funktionsfähigkeit des Systems.

Moderne Setups setzen zunehmend auf kurzlebige Tokens und identitätsbasierte Zugriffe, um statische Secrets zu vermeiden. Das verbessert die Sicherheit – ersetzt aber kein Backup. Auch Identitäten, Trust-Beziehungen und Konfigurationen müssen dokumentiert und im Notfall reproduzierbar sein.

Was ein brauchbares Backup-Konzept für Softwareprojekte enthalten sollte

Aus der Praxis ergibt sich ein technisches Minimal-Set an Komponenten, ohne die eine Wiederherstellung realistisch nicht möglich ist. Ein tragfähiges Backup-Konzept für Softwareprojekte sollte daher mindestens folgende Punkte abdecken:

Ein Backup-Konzept ist dann sinnvoll, wenn es eine Wiederherstellung ermöglicht – nicht nur das Ablegen von Daten.

1. Repository-Backups
   Ein Remote allein ist kein Backup. Für eine echte Sicherung empfiehlt sich ein vollständiger Mirror-Clone inklusive Historie, Tags und – falls genutzt – externer Artefakte wie LFS-Objekte. Auch hochverfügbare Git-Hosting-Plattformen ersetzen kein kundenseitig kontrolliertes Backup – insbesondere nicht bei versehentlicher Löschung, Account-Kompromittierung oder Fehlkonfiguration.
2. Repository-Backups
   Ein Remote allein ist kein Backup. Für eine echte Sicherung empfiehlt sich ein vollständiger Mirror-Clone inklusive Historie, Tags und – falls genutzt – externer Artefakte wie LFS-Objekte. Auch hochverfügbare Git-Hosting-Plattformen ersetzen kein kundenseitig kontrolliertes Backup – insbesondere nicht bei versehentlicher Löschung, Account-Kompromittierung oder Fehlkonfiguration.
3. Releases und Artefakte
   Ein Release sollte eindeutig identifizierbar und unabhängig von CI-Retention verfügbar sein, etwa über versionierte Build-Pakete oder Container-Images.
4. Konfiguration und Secrets
   Secrets gehören in dedizierte Systeme. Gleichzeitig braucht es einen dokumentierten Notfallprozess, um im Incident handlungsfähig zu bleiben.
5. Datenstände und Object Storage
   Konsistente Datenbank-Backups sowie geschützte Datei-Backups sind essenziell. Je nach System kommen Snapshots oder Point-in-Time-Recovery zum Einsatz.
6. Externe Ablage und Zugriffskontrolle
   Backups erfüllen ihren Zweck nur dann, wenn sie extern abgelegt sind und nicht vom gleichen Ausfall betroffen sind wie das Primärsystem. In der Praxis bedeutet das: getrennte Infrastruktur, klar definierte IAM-Rollen, versionierte Speicherung und – je nach Schutzbedarf – Retention-Regeln oder Object Lock in einem S3-kompatiblen Object Storage.

Offsite-Backup als Bestandteil moderner Entwicklungsprojekte

Für die externe, technisch unveränderbare Ablage von Backups eignet sich S3-kompatibler Object Storage besonders gut. Richtig konfiguriert – etwa mit Object Lock und definierten Retention-Regeln – erlaubt er die Kombination aus:

• Versionierung
• definierten Aufbewahrungsfristen (Retention / Lifecycle)
• unveränderbarer Speicherung (Object Lock)

Der Backup ONE Swiss S3 Storage kann dabei als Offsite-Ziel für Repository-Mirrors, Build-Artefakte oder Log-Exporte dienen – betrieben in einer vollständig in der Schweiz gehosteten Cloud-Infrastruktur:

Ebenso entscheidend ist das Zugriffsmodell. Lifecycle-Regeln, Retention und IAM-Policies müssen gemeinsam gedacht werden, damit klar definiert ist, wer Backups lesen, schreiben oder verwalten darf. Für typische S3-Szenarien lassen sich solche Rollenmodelle und Policies auch über Policy-Generatoren abbilden.

Restore-Tests: Der oft vergessene Teil

Ein Backup ist nur dann wertvoll, wenn sich ein System auch tatsächlich wiederherstellen lässt. Regelmässige Restore-Tests zeigen, ob definierte Zielwerte wie Wiederanlaufzeit oder maximaler Datenverlust realistisch erreichbar sind.

Ohne diese Tests bleibt ein Backup eine Annahme – keine verlässliche Grundlage für den Ernstfall.

Warum Wiederherstellbarkeit keine reine Betriebsaufgabe ist

Backup-Strategien werden häufig dem Betrieb zugeordnet. In modernen Projekten greift das zu kurz:

• Build-Prozesse entstehen in der Entwicklung
• CI/CD-Pipelines werden von der Entwicklung definiert
• Datenmodelle und Migrationen kommen aus der Entwicklung
• Konfigurations- und Secret-Logik wird im Code mitgeprägt

Wiederherstellbarkeit muss deshalb früh berücksichtigt werden. Der Gedanke des „Shift Left“ unterstreicht genau das: Resilienz entsteht nicht am Ende, sondern während der Entwicklung.

Fazit

Git ist unverzichtbar – aber Git ist kein Backup.

Ein tragfähiges Konzept beantwortet nicht nur die Frage, wo der Code liegt, sondern vor allem:

Wie lässt sich ein System reproduzierbar, zeitnah und kontrolliert wieder lauffähig machen?

Wer diese Frage früh stellt, baut Anwendungen, die nicht nur sauber versioniert sind, sondern auch im Ernstfall bestehen.