Open-Source-Backup-Strategie: BorgBackup vs. Restic

Wenn ein Notebook gestohlen wird, ein Cloud-Ordner versehentlich geleert ist oder ein Server nach einem Update nicht mehr startet, zählt nicht „ob“ ein Backup existiert, sondern ob es schnell und sauber zurückgespielt werden kann. Im Open-Source-Umfeld haben sich zwei Werkzeuge für verschlüsselte, inkrementelle Backups etabliert: BorgBackup und Restic. Beide sind keine „One-Click“-Wunder, sondern solide Bausteine für eine belastbare Backup-Strategie – mit unterschiedlichen Stärken bei Performance, Bedienung und Betriebsmodell.

Der Kern einer guten Lösung bleibt gleich: Daten werden versioniert (Snapshots), redundant gespeichert, regelmäßig geprüft und der Restore wird geübt. Dieser Beitrag vergleicht BorgBackup und Restic entlang typischer Fragen aus Praxis und Betrieb: Welche Ziele (lokal, NAS, SSH, Objekt-Speicher) sind sinnvoll? Wie wirkt sich das auf Schlüsselmanagement, Rotation und Automatisierung aus? Und woran lässt sich erkennen, ob ein Projekt langfristig tragfähig ist?

Welche Backup-Anforderungen in der Praxis wirklich zählen

Snapshot-Backups statt „Kopie in einen Ordner“

Im Alltag entstehen viele Änderungen in kleinen Schritten: Dokumente werden überschrieben, Quellcode-Branches wechseln, Fotos werden sortiert. Moderne Backup-Tools speichern deshalb Snapshots: Jeder Lauf erzeugt einen konsistenten Stand, der später gezielt wiederherstellbar ist. Entscheidend ist dabei die Deduplizierung (nur neue oder geänderte Datenblöcke werden gespeichert), denn sie reduziert Speicherbedarf und Laufzeiten deutlich. Genau hier punkten BorgBackup und Restic gegenüber simplen Synchronisations-Tools.

Verschlüsselung und Schlüsselverwaltung

Backups sollten standardmäßig verschlüsselt werden, sobald ein Ziel außerhalb der eigenen Kontrolle liegt (externe Platte im Büro, NAS im Keller, Storage beim Provider). Beide Werkzeuge unterstützen clientseitige Verschlüsselung: Daten werden vor dem Upload verschlüsselt, das Ziel sieht nur Chiffretext. In einer Open-Source-Backup-Strategie gehört deshalb ein klarer Prozess dazu: Wo liegt der Schlüssel, wie wird er gesichert, wer darf restaurieren, und wie wird ein Schlüsselwechsel gehandhabt? Ohne diese Antworten sind selbst perfekte Backups riskant.

Restore-Zeit und Restore-Qualität

Backup-Erfolg misst sich am Restore: Können einzelne Dateien schnell zurückgeholt werden? Gibt es eine einfache Möglichkeit, einen kompletten Stand in ein leeres System zurückzuschreiben? Und: Lassen sich Metadaten (Rechte, Owner, Timestamps, Symlinks) korrekt wiederherstellen? Für Server und Entwickler-Workstations ist das oft wichtiger als die reine Backup-Geschwindigkeit.

BorgBackup und Restic richtig einordnen

BorgBackup: Repository über SSH, Fokus auf Effizienz

BorgBackup arbeitet mit einem Repository-Konzept: Ein Zielverzeichnis (lokal oder via SSH) enthält alle Datenblöcke und Snapshots. Borg ist in vielen Setups beliebt, weil es sehr effizient mit Speicher umgeht und sich gut in klassische Admin-Workflows einfügt. Typische Muster sind: Server sichert per SSH auf einen Backup-Host, oder ein Laptop sichert auf ein NAS. Für Teams ist das attraktiv, weil sich Zugriffe und Berechtigungen sauber über SSH-Schlüssel und System-Policies steuern lassen.

Restic: leichtgewichtig, stark bei vielen Backends

Restic setzt ebenfalls auf Snapshots und Deduplizierung, ist aber besonders flexibel bei Zielen: Neben lokalen Pfaden und SSH sind Objekt-Speicher-Backends (S3-kompatibel, B2, Azure, etc.) ein häufiges Motiv. Das ist praktisch, wenn kein eigener Backup-Server betrieben werden soll oder wenn Offsite-Backups über günstigen Objekt-Speicher laufen. Restic ist zudem oft einfach zu „verkapseln“: ein Binary, eine Konfiguration, Cron oder Systemd Timer, fertig.

Gemeinsamkeiten, die für die Entscheidung wichtig sind

Beide Tools adressieren denselben Kern: verifizierbare Snapshots mit Verschlüsselung und Deduplizierung. Für Unternehmen zählen dabei weniger Feature-Listen als Betriebsfragen: Wie wird das Backup überwacht? Wie werden Zugänge rotiert? Wie wird im Notfall restauriert? Und wer kann ein Repository administrieren, ohne Einzelwissen zu horten? Wer sich zusätzlich mit organisatorischen Aspekten beschäftigen möchte, findet im Beitrag zur Open-Source-Governance passende Grundlagen zu Rollen und Verantwortlichkeiten.

Vergleich: Ziele, Betrieb und Alltagstauglichkeit

Backup-Ziele: NAS/SSH vs. Objekt-Speicher

In der Praxis entscheidet oft das Zielsystem:

• SSH (eigener Backup-Host oder NAS mit SSH): sehr transparent, gut auditierbar, gut integrierbar in bestehende Admin-Strukturen.
• Objekt-Speicher (S3 & Co.): gute Offsite-Eigenschaften, oft günstig skalierbar, aber braucht klare Policies für Zugangsdaten, Lifecycle-Regeln und Kostenkontrolle.

Wer bereits einen dedizierten Backup-Server betreibt, wird BorgBackup häufig als „natürliche“ Ergänzung erleben. Wer Offsite ohne eigenen Server will, findet in Restic oft den geradlinigeren Weg.

Automatisierung und Wartung

Beide Tools lassen sich gut automatisieren, etwa über Cron, Systemd Timer oder CI-Jobs. In Unternehmen ist ein standardisiertes Runbook wichtiger als das Tool selbst: Startzeitfenster, Retry-Logik, Benachrichtigungen, und eine klare Trennung zwischen Backup-Credentials und normalen Nutzerkonten. Zusätzlich sollte festgelegt werden, wie lange Snapshots aufbewahrt werden (Retention) und wann Repositories auf Konsistenz geprüft werden (Prüfläufe). Solche Prozesse passen gut zu dem, was im Kontext Open Source im Unternehmen typischerweise als Nachhaltigkeits- und Betriebsfähigkeit bewertet wird.

Typische Stolpersteine in echten Setups

In vielen Umgebungen scheitern Backups nicht an fehlender Verschlüsselung, sondern an Alltagsthemen:

• Falsche Annahmen über Konsistenz (z.B. Datenbanken werden „hot“ kopiert, ohne passende Mechanismen).
• Zu große Ausschlusslisten: „Temp“-Ordner oder Build-Artefakte sind sinnvoll, aber nicht, wenn wichtige Daten versehentlich darunter fallen.
• Keine Restore-Übung: Der erste Restore findet im Ernstfall statt.
• Fehlende Offsite-Kopie: Ein NAS neben dem Server schützt nicht vor Brand, Diebstahl oder Ransomware im selben Netzsegment.

Lizenz und Ökosystem: Was für den Einsatz zählt

Lizenzfolgen realistisch einordnen

Für Anwender:innen ist meist entscheidend, dass ein Tool als freie Software verfügbar ist: Transparenz, Auditierbarkeit, langfristige Nutzbarkeit auch ohne Hersteller. Im Unternehmenskontext zählt zusätzlich, wie sich Lizenzen auf Distribution und Integration auswirken (z.B. bei internen Appliances oder Managed Services). Wer tiefer in die Abwägung zwischen permissiven und Copyleft-Lizenzen einsteigen möchte, kann die Orientierung im Beitrag Open-Source-Lizenzen: MIT, Apache oder GPL? nutzen.

Community-Signale: Wartung, Reviews, Releases

Bei Backup-Tools ist Nachhaltigkeit besonders wichtig, weil Repositories oft über Jahre genutzt werden. Ein Wechsel ist möglich, aber mit Migrationsaufwand verbunden. Sinnvolle Signale für Projektreife sind: nachvollziehbare Release-Prozesse, dokumentierte Upgrade-Pfade, aktive Issue-Bearbeitung, Tests/CI, sowie klare Zuständigkeiten für Security-Themen. Entscheidend ist nicht „Hype“, sondern die Fähigkeit, Bugs über längere Zeit sauber zu managen.

Entscheidung nach Szenario statt nach Bauchgefühl

Laptop/Workstation: schnell, verschlüsselt, wenig Admin-Aufwand

Für Einzelgeräte zählt: einfache Bedienung, verlässliche Verschlüsselung, klare Restore-Kommandos. Ein typisches Muster ist „Backup auf externes Laufwerk + Offsite in Objekt-Speicher“. Wichtig ist eine Passphrase-Policy, die im Notfall funktioniert (z.B. Hinterlegung in einem abgesicherten Notfallumschlag oder Unternehmens-Tresor).

Server: planbare Jobs, zentrale Überwachung, getrennte Rechte

Auf Servern sollten Backup-Jobs unter eigenen Service-Accounts laufen. Zugänge zum Zielsystem (SSH-Key oder Objekt-Speicher-Key) gehören streng eingeschränkt. Zusätzlich lohnt eine klare Trennung zwischen „Backup schreiben“ und „Backup löschen“: Retention sollte automatisiert sein, aber nicht jedem Prozess Vollzugriff geben. Wer Monitoring-Patterns für Cron-Jobs und SLOs sucht, kann sich an Konzepten orientieren, die auch beim Open-Source-Monitoring typisch sind: Alarmierung auf fehlgeschlagene Läufe, auf ausbleibende Läufe und auf stark wachsende Repositories.

Kleine Teams: Standardisierung und Vertretbarkeit

In Teams entsteht schnell „Backup-Wissen“ bei Einzelpersonen. Besser ist ein minimales Betriebsmodell: einheitliche Pfade, gleiche Retention-Regeln, dokumentierte Restore-Schritte, und regelmäßige Übungen. Bei Offsite-Zielen sollte klar sein, wer Zugriff auf Credentials hat und wie Rotationen ablaufen.

Konkrete Schritte für eine robuste Umsetzung

Die folgenden Punkte lassen sich unabhängig vom Tool als Startpunkt nutzen:

• Zu sichernde Daten in Kategorien einteilen (kritisch, wichtig, bequem) und pro Kategorie RPO/RTO grob festlegen (maximaler Datenverlust vs. maximale Wiederherstellungszeit).
• Ein Ziel für schnelle Restores wählen (lokal/NAS) und ein Offsite-Ziel ergänzen (physisch getrennt oder Objekt-Speicher).
• Verschlüsselung aktivieren und Schlüsselmanagement festlegen (Passphrase, Backup der Schlüssel, Notfallzugriff).
• Retention definieren (z.B. mehrere tägliche, wöchentliche und monatliche Stände) und Löschrechte bewusst einschränken.
• Monatlich einen Restore testen: einzelne Datei, kompletter Ordner, und mindestens einmal ein „Blank-System“-Restore in eine Testumgebung.
• Repository-Prüfläufe einplanen und Backup-Logs zentral sammeln (damit Fehler nicht still bleiben).

Tabelle: Orientierung für die Tool-Wahl

Wann ein Wechsel oder eine Kombination sinnvoll ist

Migration: Aufwand realistisch planen

Ein Wechsel zwischen Tools ist möglich, aber selten „verlustfrei“ im Sinne identischer Historie, da Repository-Formate unterschiedlich sind. In der Praxis bedeutet Migration häufig: neuer Backup-Startpunkt plus parallele Aufbewahrung alter Repositories bis zum Ablauf der Retention. Das ist nicht schlimm, wenn es geplant ist. Ungeplant wird es teuer, wenn Restore-Prozesse nicht dokumentiert sind.

Kombination: lokale Schnelligkeit plus Offsite-Sicherheit

Manche Setups nutzen bewusst zwei Stufen: schnelle Backups auf ein lokales Ziel (für kurze Restore-Zeiten) und zusätzlich Offsite für Desaster-Fälle. Entscheidend bleibt, dass beide Stufen getestet werden. Besonders bei Ransomware-Szenarien hilft es, wenn Offsite-Ziele nicht mit denselben Schreibrechten permanent erreichbar sind.

Unterm Strich sind BorgBackup und Restic beides ernstzunehmende Werkzeuge. Die bessere Wahl hängt weniger vom Feature-Detail ab als von Zielsystem, Betriebsmodell und Disziplin bei Tests. Wer diese Punkte sauber definiert, erreicht mit beiden Lösungen robuste Backups, die in der Praxis tatsächlich wiederherstellbar sind.