Backups mit Restic, Borg und Kopia: lokale Snapshots, Offsite-Kopien und Wiederherstellung im Vergleich

Restic, Borg und Kopia dominieren die datenschutzfreundliche Datensicherung auf eigenen Systemen. Alle drei erzeugen verschlüsselte, deduplizierte Snapshots und lassen sich ohne Cloud-Zwang betreiben - für ein kleines Homelab ebenso wie für eine Firma mit 10 bis 30 Mitarbeitern. Die Unterschiede liegen im Detail: Speicherformat, Aufbau, Offsite-Tauglichkeit und die Frage, wie weh ein verlorener Schlüssel tut. Dieser Artikel vergleicht die drei Kandidaten sachlich.

Warum ein Backup ohne Restore-Test kein Backup ist - typische Fehlannahmen

Die häufigste Fehlannahme lautet, ein fehlerfrei durchgelaufener Backup-Job sei bereits ein Backup. Ein Job, der grün meldet, beweist nur, dass Daten geschrieben wurden - nicht, dass sie lesbar, vollständig und in der richtigen Reihenfolge wiederherstellbar sind. Typische Fehlannahmen in kleinen Umgebungen:

Eine Kopie auf derselben Maschine oder demselben NAS gilt als Backup, obwohl sie sich mit dem Original dieselbe Ausfallursache teilt.
Ein Synchronisationslauf wird mit einem versionsbehafteten Snapshot verwechselt. Wird eine Datei versehentlich gelöscht oder verschlüsselt, überträgt die Synchronisation den Schaden nur.
Laufende Datenbanken werden als Dateiordner kopiert, ohne dass ein konsistenter Zustand eingefroren wird. Das Ergebnis ist ein Archiv, das beim Wiederherstellen Referenzfehler zeigt.
Der Verschlüsselungsschlüssel liegt im selben Ordner wie das Backup. Fällt das Zielmedium aus, sind Kopie und Schlüssel zugleich weg.

Ein Backup ist erst dann eines, wenn mindestens eine Wiederherstellung geübt und protokolliert wurde. Deshalb behandelt dieser Vergleich die Restore-Praxis als gleichrangigen Punkt.

Die drei Kandidaten als Vergleichstabelle

Die folgende Tabelle fasst die Kernmerkmale zusammen. Angaben zu Speicherformaten und Plattformen beziehen sich auf die zum Redaktionszeitpunkt aktuellen stabilen Versionen; Versionsnummern ändern sich, das beschriebene Prinzip bleibt.

|---|---|---|---|

| Speicherprinzip | Content-adressierte Chunks, Deduplizierung über alle Snapshots | Deduplizierte Chunks in einem Repository, Segment-Dateien | Content-adressierte Chunks, Deduplizierung mit konfigurierbarer Splitter-Größe |

| Snapshot-Format | Eigenes Repository-Format, ein Verzeichnis pro Repo | Eigenes Repository-Format, append-only-tauglich | Eigenes Repository-Format, wahlweise Verzeichnis, S3 oder WebDAV |

| Dateisysteme | Dateisystem-unabhängig, sichert Verzeichnisse | Dateisystem-unabhängig, sichert Verzeichnisse | Dateisystem-unabhängig, optional Dateisystem-Snapshots (Btrfs, ZFS) |

| Besonderheiten | Einfache Offsite-Backends (S3, B2, SFTP), check prüft die Integrität | Effizient bei vielen Änderungen, append-only-Modus gegen Ransomware | Richtlinien pro Ordner, Snapshot-Zeitpläne und Aufbewahrung integriert |

Keines der Werkzeuge ist grundsätzlich überlegen. Restic punktet bei schlankem Offsite-Betrieb, Borg bei sparsamem Speicherverbrauch unter Linux, Kopia bei integrierter Bedienung und Richtlinienverwaltung.

Aufbau und Betrieb: Konfigurationsaufwand, Rechte, Datenbanken

Der Grundaufbau ist kurz. Ein Restic-Repository entsteht mit restic init, ein Borg-Repository mit borg init, Kopia über kopia repository create. Für einen täglichen Lauf genügen wenige Zeilen: ein Aufruf mit Ziel, ein Aufbewahrungsbefehl und ein Zeitgeber in Form eines systemd-Timers oder Cron-Eintrags. Grosse Konfigurationsdateien braucht keines der Werkzeuge.

Administratorrechte sind an einer Stelle unvermeidbar: Wer Systemverzeichnisse wie /etc oder /var/lib sichern will, muss den Lauf mit passenden Rechten ausführen, weil einzelne Dateien nur für root lesbar sind. Ein häufiges Rechteproblem: Wird ein Backup als normaler Benutzer erstellt und als root wiederhergestellt, gehören die Dateien anschliessend dem falschen Eigentümer. Die Wiederherstellung sollte mit derselben Benutzerkennung laufen wie das Backup, oder die Eigentümer werden danach gezielt angepasst.

Laufende Datenbanken stellen alle drei vor dasselbe Problem: Ein reiner Dateisystem-Snapshot einer aktiven PostgreSQL- oder MariaDB-Instanz kann inkonsistent sein. Sauber ist ein logischer Dump vor dem Lauf - pg_dump bei PostgreSQL, mysqldump bei MariaDB - oder ein kurzes Einfrieren des Dateisystems, damit der Snapshot einen konsistenten Stand sieht. Die Reihenfolge lautet: erst Datenbank konsistent sichern, dann Volumes und Konfigurationsdateien.

Offsite und Zweitkopie: Szenarien, Alternativen, Kosten

Eine zweite Kopie am selben Ort schützt nicht vor Brand, Diebstahl oder Überspannung. Für den Offsite-Anteil haben sich mehrere Szenarien bewährt:

NAS zu NAS: Zwei Geräte an unterschiedlichen Standorten synchronisieren ein Restic- oder Borg-Repository. Restic schreibt direkt über SFTP auf ein entferntes Ziel, Borg arbeitet über SSH. Günstig, setzt aber voraus, dass der Zweitstandort zuverlässig erreichbar ist.
NAS zu Cloud-Objektspeicher: Restic und Kopia sprechen von Haus aus S3-kompatible Ziele, Borg benötigt ein Zusatzwerkzeug wie rclone. Da alle drei clientseitig verschlüsseln, sieht der Anbieter nur unlesbare Chunks.
Zweitstandort zu Hause: Eine zweite Wohnung oder ein Elternhaus mit Internetanschluss kann das entfernte Repository aufnehmen.
Rustic und rsync als Alternative: Rustic ist eine Neuimplementierung des Borg-Formats und kann gemischte Umgebungen mit Borg-Repositories bedienen. rsync bleibt sinnvoll für schnelle, unversionierte Spiegelungen, bietet aber weder Deduplizierung noch Snapshots und darf nie die einzige Kopie sein.

Die Kostenfaktoren sind Bandbreite, Speicher und Rechenzeit. Die erste vollständige Übertragung ist immer die größte Last; jede weitere Sicherung überträgt nur geänderte Chunks. Bei mehreren hundert Gigabyte dauert die Erstsicherung über eine übliche Hausanschluss-Bandbreite oft einen oder mehrere Tage. Da Deduplizierung und Kompression die abgelegte Menge deutlich reduzieren, ist die monatliche Speichermiete bei einem Objektspeicher meist gering, häufig im Bereich weniger Euro pro Monat für kleinere Bestände. Preise verschieben sich und sind nur als Preisrahmen zu verstehen, nicht als Zusage.

Restore-Praxis: Datei, Verzeichnis, Komplettrest, Testumgebung

Die Wiederherstellung entscheidet, ob das Konzept trägt. Vier Stufen lassen sich unterscheiden, und alle drei Werkzeuge beherrschen sie:

Einzelne Datei: Restic holt sie mit restic restore --include, Borg entpackt über borg extract mit Pfadangabe, Kopia über kopia snapshot restore. Diese Stufe ist die tägliche Uebung und in Minuten erledigt.
Ganzes Verzeichnis: Derselbe Aufruf mit einem Pfad auf Verzeichnisebene. Hier zeigt sich, ob Zeitstempel und Rechte korrekt mitgeführt wurden.
Komplettrest auf leere Hardware: Der Ernstfall. Nach einem Hardwaretausch wird das Repository auf die neue Maschine gebracht und das System zurückgeschrieben. Dienste, Bootloader und Netzwerkkonfiguration sind separat wiederherzustellen - ein reines Datei-Backup deckt das nicht ab.
Testumgebung auf einer VM: Die sauberste Methode ist eine virtuelle Maschine ohne Zugang zum Produktionsnetz, in der die Wiederherstellung geübt und die Anwendung gestartet wird. Erst wenn die Anwendung ihre Daten liest, ist die Wiederherstellung belegt.

Zu jedem Test gehört ein kurzes Protokoll: Datum, Umfang, benötigte Zeit, Fehler. Ohne dieses Protokoll wird der Test nicht regelmäßig wiederholt. Für eine kleine Firma bietet es sich an, ihn quartalsweise und nach jeder größeren Änderung an der Backup-Konfiguration einzuplanen.

Aufbewahrung: stündlich, täglich, wöchentlich, Speicherbedarf

Aufbewahrung bestimmt, wie weit zurück ein Datenstand reicht, ohne dass das Ziel vollläuft. Restic nutzt forget --keep-hourly --keep-daily --keep-weekly --keep-monthly; Borg arbeitet mit prune und denselben Intervallen; Kopia verwaltet Aufbewahrungsrichtlinien pro Datenquelle.

Ein bewährter Ausgangspunkt für ein kleines Homelab ist die Großvater-Vater-Sohn-Methode: die letzten Tage, sieben Wochen, zwölf Monate. Entscheidend ist nicht die maximale Frequenz, sondern die Frage, wie viel Datenverlust im Ernstfall verkraftbar ist.

Der Speicherbedarf wächst durch Deduplizierung deutlich langsamer als die Summe der Snapshot-Größen vermuten lässt. Der erste Snapshot belegt den vollen Datenbestand, jeder weitere nur die Differenz. Der Verbrauch ist daher näherungsweise linear zur Menge der echten Änderungen plus einem kleinen Aufschlag für Metadaten. Wer starke Deduplizierung will, sollte Snapshots nicht zu aggressiv löschen, weil das Entfernen die gemeinsam genutzten Chunks erst dann freigibt, wenn kein verbleibender Snapshot sie noch braucht.

Stolperfallen je Lösung

Verschlüsselungsschlüssel und Schlüsselverlust: Ein verlorener Schlüssel macht das gesamte Repository unlesbar, auch bei vollständigen Daten. Der Schlüssel oder die Passphrase gehört getrennt vom Backup aufbewahrt, an einem anderen Ort als das Zielmedium.
Kryptomüll nach Hardwaretausch: Bei Restic lässt sich ein Repository mit restic rebuild-index reparieren, wenn Index-Dateien beschädigt sind. Bei Borg und Kopia ist der Umgang mit defekten Segment- oder Blob-Dateien jeweils unterschiedlich; wichtig ist, den offiziellen Reparaturweg zu kennen, bevor er gebraucht wird.
Zu aggressives Pruning: Wer Snapshots löscht, bevor genug neue existieren, verliert im schlimmsten Fall genau die Stufen, die im Ernstfall gebraucht werden. Aufbewahrung lieber zu großzügig beginnen.
Bandbreiten- und CPU-Kosten: Deduplizierung und Kompression kosten Rechenzeit. Auf schwacher Hardware verlängert sich besonders der erste Lauf spürbar. Für Offsite-Ziele ist die Bandbreite der begrenzende Faktor.
Rechteprobleme bei Root-Dateien: Wie oben beschrieben, führen unterschiedliche Benutzerkennungen zwischen Backup und Restore zu falschen Eigentümern.
Differenz gegen vollständig: Inkrementelle oder differenzielle Läufe sind effizient, aber die Abhängigkeit vom vorherigen Snapshot bedeutet, dass eine beschädigte Vorstufe mehrere spätere Stände unbrauchbar machen kann. Deshalb sollte die Integrität regelmäßig geprüft werden - Restic bietet dafür check, Borg check, Kopia snapshot verify.
Verschlüsselung der Backup-Metadaten: Alle drei Werkzeuge verschlüsseln nicht nur Inhalte, sondern auch Dateinamen und Metadaten. Das ist ein Vorteil für den Datenschutz auf fremden Zielen, bedeutet aber, dass ohne Schlüssel nicht einmal die Struktur lesbar ist - ein weiterer Grund, den Schlüssel sicher und getrennt zu verwahren.

Empfehlung: kleines Büro, Privathomelab, gemischte Umgebung

Kleines Büro mit 10 bis 30 Mitarbeitern: Wer VMs und Container betreibt und Verwaltungsaufwand minimieren will, fährt mit Kopia gut, weil Richtlinien, Zeitpläne und Aufbewahrung integriert sind. Ein vorhandener Proxmox Backup Server lässt sich sinnvoll um ein dateibasiertes Werkzeug für Nicht-VM-Daten ergänzen.
Privathomelab: Restic ist wegen der einfachen Offsite-Backends und der einzelnen Binärdatei meist die unkomplizierteste Wahl. Wer streng mit Speicherplatz haushalten muss und unter Linux arbeitet, findet in Borg den sparsameren Kandidaten.
Gemischte Umgebung mit VMs: Eine bewährte Aufteilung besteht aus einem dateibasierten Werkzeug für Daten und Konfigurationen und einer VM-basierten Sicherung für die Virtualisierungsebene. Rustic kann als Brücke dienen, wo Borg-Repositories und eine moderne Implementierung zusammenkommen sollen.

Unabhängig von der Wahl gilt derselbe Grundsatz: erst sichern, dann prüfen, dann wiederherstellen und das Ergebnis protokollieren. Kein Werkzeug entbindet von dieser Routine.

FAQ

Welches Werkzeug eignet sich für Anfänger ohne Kommandozeilen-Erfahrung?

Kopia ist die zugänglichste Wahl, weil es eine grafische Oberfläche, eine Weboberfläche und Richtlinien pro Ordner mitbringt. Restic und Borg sind reine Kommandozeilenwerkzeuge und setzen etwas Einarbeitung voraus, sind dafür schlanker und weit verbreitet.

Kann ich ein Restic-Backup später mit Borg oder Kopia weiterverwenden?

Nein. Die drei Formate sind nicht untereinander kompatibel. Ein Wechsel erfordert einen neuen vollständigen Lauf in das Zielwerkzeug. Rustic kann zwar Borg-Repositories lesen, ersetzt aber nicht die Migration zwischen den Formaten.

Wie oft sollte ich einen Restore-Test durchführen?

Für ein Homelab genügt ein quartalsweiser Test eines kritischen Datensatzes. In einer kleinen Firma sollte mindestens einmal pro Quartal eine repräsentative Wiederherstellung in einer isolierten VM erfolgen, zusätzlich nach jeder Änderung an der Backup-Konfiguration.

Was passiert, wenn ich den Verschlüsselungsschlüssel verliere?

Ohne Schlüssel oder Passphrase ist das gesamte Repository unlesbar, auch wenn alle Daten vollständig vorhanden sind. Es gibt keinen offiziellen Weg zur Wiederherstellung. Deshalb muss der Schlüssel getrennt und an mehreren Orten aufbewahrt werden.

Sind alle drei Werkzeuge für Offsite-Kopien geeignet?

Ja. Restic und Kopia sprechen S3-kompatible Objektspeicher direkt an, Borg benötigt dafür ein Zusatzwerkzeug wie rclone. In allen Fällen werden die Daten clientseitig verschlüsselt, sodass der Speicheranbieter nur unlesbare Chunks sieht.

Interne Verlinkungen

Ankertext: "3-2-1-Backup-Strategie" -> Zielslug: backup-3-2-1
Ankertext: "Datenbank-Backups richtig planen" -> Zielslug: datenbank-backups
Ankertext: "Proxmox Backups automatisieren" -> Zielslug: proxmox-backups-automatisieren
Ankertext: "Proxmox Backup Server" -> Zielslug: proxmox-backup-server

Veröffentlichungs-Hinweise

Zielsystem: Homelab-Auto-Publish-Pipeline. Die Datei liegt im Draft-Ordner und wird vom täglichen Lauf (homelab_daily_publish.py) über die YAML-Frontmatter erkannt.
Erwartete Pflichtfelder im Frontmatter: title, slug, meta_description, focus_keyword, date (2026-09-29). Der Slug restic-borg-kopia-backup-vergleich bestimmt den Dateinamen der Ausgabe unter site/artikel/.
Interne Links in diesem Entwurf sind als Slug-Liste hinterlegt und müssen beim Rendern in ../artikel/<slug>.html aufgelöst werden. Die vier Zielartikel existieren bereits im Artikelverzeichnis.
Keine Affiliate- oder Partner-Links enthalten. Preise sind als Preisrahmen formuliert und nicht als Zusage. Keine erfundenen Messwerte.
Bitte beim Rendern darauf achten, dass die Vergleichstabelle als HTML-Tabelle übernommen wird und die FAQ-Fragen als <h3> erscheinen.

Hinweis: Dieser Artikel ist redaktioneller Inhalt und enthält keine Affiliate- oder Partner-Links. Alle Angaben entsprechen dem Stand 2026 und können sich ändern.