Homelab-Backup mit restic oder Borg

Ein Backup, das nie wiederhergestellt wurde, ist ein Lottoschein in schönerer Verpackung. Dieser Guide macht daraus eine langweilige Routine.

Kurz gesagt

restic und Borg schreiben beide verschlüsselte, deduplizierte Sicherungen in ein Repository, und beide sind für ein Homelab ausgereift. Welches besser passt, hängt vor allem davon ab, wohin die Kopien sollen, ob Windows-Rechner dabei sind und wie du dich vor Ransomware schützen willst. Die Schritte, an denen ein Backup steht oder fällt, sind bei beiden gleich: Schlüssel getrennt vom Repository aufbewahren, das Repository regelmäßig prüfen und vorab eine Testdatei zurückholen.

So funktioniert’s

1. Gleiche Grundlage. Beide Werkzeuge schreiben in ein Repository, also ein Verzeichnis oder einen entfernten Speicher. Jeder Lauf erzeugt einen Snapshot (restic) oder ein Archiv (Borg). Die Werkzeuge zerlegen Dateien in Chunks, also kleine Datenstücke, und speichern nur die, die das Repository noch nicht kennt. Der zweite Lauf ist deshalb viel kleiner als der erste. Das nennt man Deduplizierung. restic beschreibt ein Repository aus Dateien, die einmal geschrieben und nie verändert werden, mit Daten in Packs gebündelt [4]. Borg beschreibt ein Archiv als Ergebnis eines einzelnen borg create und ein Repository, das bereits vorhandene Chunks nur referenziert [13]. Beide verschlüsseln auf dem Client, bevor etwas geschrieben wird. Die Speicherseite sieht deine Daten also nie im Klartext [4][13].
2. Versionsstand am 18. Okt. 2026. Die neueste restic-Version, die wir auf der Release-Seite des Projekts gefunden haben, ist 0.19.1 vom 5. Juli 2026, überwiegend Fehlerkorrekturen [8]. Davor erschien 0.19.0 im Juni 2026 [9]. Die Dokumentation nennt zwei Repository-Formate. Version 1 funktioniert mit jedem restic. Version 2 braucht restic 0.14.0 oder neuer, bringt Kompression mit und ist der aktuelle Standard [1]. Eine dritte Version haben wir in der Dokumentation nicht gefunden. Bei Borg nennt die Projektseite 1.4 als aktuelle stabile Serie, mit 1.4.5 vom 19. Juli 2026 [10]. Borg 1.2 gilt als „oldstable“ [10]. Borg 2.0 ist laut Projekt im Test und nicht für den Produktivbetrieb gedacht [10]. Die Release-Liste führt 2.0.0b25 als Vorabversion [11], und die Sicherheitsrichtlinie des Projekts deckt 2.0.x nicht mit Sicherheitsupdates ab [20]. Borg 2.0 ist ein Release mit Bruch der Kompatibilität: Es liest 1.x-Repositories nicht direkt, ändert die Kommandozeile und bietet borg transfer, um Archive zu übernehmen [12]. Unsere Einschätzung: Wer heute ein neues Borg-Setup braucht, das zuverlässig laufen muss, nimmt Borg 1.4.
3. Ziele und Plattformen. restic dokumentiert lokale Verzeichnisse, SFTP, einen REST-Server, S3 und S3-kompatiblen Speicher und weitere Ziele, mit rclone als Brücke zu zusätzlichen Diensten [1][2]. Die restic-Dokumentation rät unter Linux davon ab, ein Repository auf einer CIFS-Freigabe (SMB) abzulegen oder von einer zu sichern, wegen Kernel-Kompatibilitätsproblemen [1]. Das zählt, wenn dein NAS nur eine SMB-Freigabe anbietet. Borg 1.4 erreicht ein Repository per lokalem Pfad oder über SSH [13]. Die Beta von Borg 2.0 ergänzt SFTP, S3/B2 und rclone [12]. Unter Windows liefert restic offizielle Binaries, installierbar über Scoop oder WinGet [7], und hat eine Backup-Option für Windows-Volumenschattenkopien [5]. Die Borg-Dokumentation nennt den Betrieb unter Windows experimentell [18]. restic bietet für offizielle Binaries den Befehl self-update [7]. Borg gibt es als Distributionspaket, als eigenständiges Binary oder per pip [18].
4. Verschlüsselung und Schlüssel. restic verschlüsselt mit AES-256 im Counter-Modus, prüft die Echtheit mit Poly1305-AES und leitet Schlüssel mit scrypt aus deinem Passwort ab. Ein Repository kann mehrere Passwörter haben, jedes mit eigener Schlüsseldatei [4]. Verlierst du das Passwort, sind die Daten weg [1]. Ein durchgesickerter Schlüssel lässt sich nicht widerrufen, ohne das ganze Repository neu zu verschlüsseln [4]. Borg legt den Verschlüsselungsmodus beim Anlegen fest und lässt ihn später nicht mehr ändern [14]. Bei repokey liegt der Schlüssel im Repository, geschützt durch deine Passphrase. Bei keyfile liegt er auf dem Client. Du brauchst immer Schlüssel und Passphrase [14]. Die Borg-Dokumentation verlangt eine Kopie des Schlüssels außerhalb des Repositorys und außerhalb des gesicherten Systems und nennt dafür borg key export [14]. Borg 1.x nutzt AES-CTR mit HMAC-SHA256 [14]. Die Beta von 2.0 wechselt zu neuerer authentifizierter Verschlüsselung und Argon2 [12].
5. Schutz vor Ransomware. Die Idee ist auf beiden Seiten dieselbe: Ein kompromittierter Client darf Daten hinzufügen, aber nicht löschen. Der REST-Server von restic hat einen Append-only-Modus, andere Standard-Backends meist nicht, und rclone kann dazwischengeschaltet werden [2]. Das Aufräumen braucht vollen Zugriff, deshalb empfiehlt die restic-Dokumentation einen separaten, gut gesicherten Admin-Client. Sie warnt außerdem, dass gefälschte Snapshots echte aus einer Aufbewahrungsregel verdrängen können, und rät bei Append-only-Repositories zu --keep-within [2]. Borg nutzt borg serve --append-only in den SSH-Schlüsseloptionen für wenig vertrauenswürdige Clients [19]. Der Append-only-Modus von Borg betrifft nur die Struktur auf unterer Ebene. Prune und Delete bleiben erlaubt, und sobald du im normalen Modus schreibst, werden Löschungen endgültig. Werkzeuge wie rm ignorieren den Modus ganz [17]. Keiner der Modi ersetzt eine saubere Zugriffskontrolle.
6. Aufbewahrung und Aufräumen. restic räumt in zwei Schritten auf. forget entfernt Snapshots nach Regel, etwa mit --keep-daily, und prune gibt danach unreferenzierte Daten frei. forget --prune führt beides aus. Prune sperrt das Repository, Backups können in der Zeit nicht abschließen. Standardmäßig gilt die Regel je Gruppe aus Host und Pfad, und --dry-run zeigt vorab, was passieren würde [2]. Auch Borg arbeitet in zwei Schritten. borg prune wählt Archive mit eigenen Keep-Optionen aus, und Speicherplatz wird erst nach borg compact frei [16]. Ohne Namensmuster betrachtet Prune alle Archive im Repository. Beschränke es deshalb pro Rechner und probiere zuerst --dry-run --list [16].
7. Konsistente Daten. Keines der Werkzeuge versteht deine Datenbanken. Die Borg-Dokumentation nennt die üblichen Mittel: Datenbanken exportieren oder anhalten, Container vor dem Kopieren ihrer Volumes stoppen oder das Dateisystem per Snapshot einfrieren [13]. restic kann die Ausgabe eines Befehls mit --stdin-from-command speichern. Schlägt der Befehl fehl, bricht restic ab und legt keinen Snapshot an. Eine einfache --stdin-Pipe kann Fehler verdecken und ein leeres Backup erzeugen [5]. Wir empfehlen einen Dump-Schritt vor jedem Lauf und eine Prüfung, dass die Dump-Datei nicht leer ist.
8. Prüfen und Restore-Test. restic check prüft die Struktur. --read-data liest alle Pack-Dateien, --read-data-subset prüft pro Lauf nur einen Teil [3]. Die restic-Dokumentation rät außerdem zu einer Prüfung nach dem Prune [2]. borg check prüft Repository und Archive. --verify-data ergänzt eine vollständige kryptografische Prüfung und ist langsam, --max-duration teilt die Repository-Prüfung in Abschnitte, und --repair kann Daten kosten [15]. Eine bestandene Prüfung sagt, dass das Repository heil ist, nicht dass du zurückholen kannst, was du brauchst. Diese Lücke schließt der Restore-Test. Stelle in ein leeres Verzeichnis mit restic restore [6] oder borg extract [13] wieder her, öffne ein paar Dateien und starte einen Dienst aus einem wiederhergestellten Dump. Mach das auf einem zweiten Rechner, nur mit dem getrennt abgelegten Schlüssel und Passwort. So prüfst du gleich deine Schlüsselablage mit.

Ein Homelab-Beispiel

So könnte ein Setup aussehen. Es ist ein Beispiel und kein Bericht über unsere Systeme. Zu unserem Homelab ist für diesen Artikel nur dokumentiert: Es gibt ein QNAP-NAS mit einer Freigabe zum Austauschen und Sichern von Dateien (Stand 14. bis 18. Okt. 2026). Zum eingesetzten Backup-Werkzeug und zum Backup-Zustand unserer Server machen wir keine Aussage.

Angenommen, die Daten liegen in /srv/daten, samt Datenbank-Dumps und Docker-Volumes, und eine zweite Platte ist unter /mnt/backup eingebunden.

Kopie 1, lokal auf der zweiten Platte, mit restic: restic init --repo /mnt/backup/restic-lokal und restic -r /mnt/backup/restic-lokal backup /srv/daten. Mit Borg 1.4: borg init --encryption=repokey-blake2 /mnt/backup/borg-repo und borg create --stats /mnt/backup/borg-repo::'{hostname}-{now}' /srv/daten.

Kopie 2, auf dem NAS oder einem zweiten Host. Bei restic legst du das Ziel mit den Chunker-Einstellungen der Quelle an, restic -r sftp:backup@nas-host:/backup/restic init --from-repo /mnt/backup/restic-lokal --copy-chunker-params, und kopierst dann mit restic -r sftp:backup@nas-host:/backup/restic copy --from-repo /mnt/backup/restic-lokal. Die Dokumentation weist darauf hin, dass Kopieren die Daten liest und neu hochlädt, weil die Schlüssel verschieden sind [3]. Bei Borg 1.4 würden wir ein zweites borg create gegen ein zweites Repository ausführen, zum Beispiel borg create --stats /mnt/nas-backup/borg-repo::'{hostname}-{now}' /srv/daten. Das ist unsere Einschätzung, keine dokumentierte Funktion.

Kopie 3, extern: dasselbe Vorgehen gegen eine Platte oder einen Speicher, der das Haus verlässt, zum Beispiel restic -r /mnt/extern/restic copy --from-repo /mnt/backup/restic-lokal.

Aufbewahrung, zuerst als Probelauf: restic -r /mnt/backup/restic-lokal forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --dry-run, oder mit Borg borg prune --list --dry-run --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --glob-archives '{hostname}-*' /mnt/backup/borg-repo. Danach den echten Befehl ausführen, bei Borg gefolgt von borg compact /mnt/backup/borg-repo. Die Zahlen sind Beispielwerte. Wähle sie danach, wie lange eine beschädigte Datei unbemerkt bleiben könnte.

Prüfen und Restore: restic -r /mnt/backup/restic-lokal check --read-data-subset=10% oder borg check --verify-data /mnt/backup/borg-repo, danach restic -r /mnt/backup/restic-lokal restore latest --target /tmp/restore-test. Für den Schlüssel führst du borg key export /mnt/backup/borg-repo schluessel-export.txt aus und legst die Datei getrennt vom Repository ab. Bei restic legst du das Passwort genauso ab.

Prüfliste

• Prüfe, ob dein Backup-Ziel ein lokaler Pfad, SFTP oder ein anderes dokumentiertes Backend ist, und vermeide unter Linux eine SMB-Freigabe als restic-Repository.
• Lege vor dem Start die Borg-Linie fest: 1.4 für den Betrieb, 2.0 nur als Testumgebung, solange es Beta bleibt.
• Bewahre das restic-Passwort oder Borg-Schlüssel und Passphrase an einem Ort auf, der weder das Repository noch der gesicherte Host ist.
• Exportiere jede Datenbank vor dem Lauf und prüfe, dass der Dump existiert und nicht leer ist.
• Führe das erste forget oder prune als Probelauf aus und bestätige, dass es behält, was du erwartest.
• Beschränke Borgs prune mit einem Namensmuster auf die Archive eines Rechners.
• Plane das Aufräumen auf einem separaten Admin-Client, wenn du Append-only nutzt, und verwende dort bei restic --keep-within.
• Plane restic check oder borg check ein, bei großen Repositories mit --read-data-subset oder --max-duration.
• Stelle jedes Quartal ein Testverzeichnis auf einem zweiten Rechner wieder her und notiere Datum und Ergebnis.