Restic oder BorgBackup: Welches Backup passt?

Restic im Vergleich zu BorgBackup

Restic und BorgBackup erfüllen denselben Kernzweck: deduplizierte, verschlüsselte und inkrementelle Backups eines Linux-Servers. Die entscheidende Wahl hängt davon ab, wo das Backup gespeichert wird. Restic unterstützt S3 und andere Object-Storage-APIs nativ, wodurch ein Bucket ein direktes Ziel ohne zusätzliche Software auf der Gegenseite darstellt. Das stabile Borg benötigt das Programm borg auf dem Zielrechner, da ein Borg-Repository von einem Prozess und nicht von einem Dateisystem oder einer API bereitgestellt wird. Wenn das Ziel ein Object Storage ist, ist die Entscheidung bereits gefallen. Wenn das Ziel ein zweiter Linux-Server unter Ihrer Kontrolle ist, ist Borg eine Option und oft schneller.

Alle anderen Unterschiede sind zweitrangig. Beide verwenden inhaltsbasierte Chunking-Verfahren, sodass bei einem 40 GB großen Verzeichnis mit 200 MB Änderungen auch nur etwa 200 MB hochgeladen werden. Beide verschlüsseln die Daten clientseitig. Beide können Snapshots via FUSE (Filesystem in Userspace) einbinden, um einzelne Dateien wiederherzustellen. Stand Oktober 2026 ist restic in Version 0.19.1 verfügbar, während die stabile Serie von Borg bei 1.4.5 liegt. Da Borg 2.0 seit Jahren als Beta geführt wird und nur für Testzwecke vorgesehen ist, sollte aktuell die Version 1.4 eingesetzt werden.

Das Repository-Modell ist der entscheidende Unterschied

Ein restic-Repository ist ein Verzeichnis von Dateien: config, keys/, snapshots/, index/ und data/ voller Pack-Dateien. Es wird nichts weiter benötigt, um es zu lesen. Deshalb kann restic so viele Backends ansteuern. Jeder Speicher, der Blobs speichern, abrufen, auflisten und löschen kann, kann ein restic-Repository aufnehmen. So unterstützt eine einzige Binary lokale Pfade, SFTP, einen eigenen REST-Server, S3, Backblaze B2, Azure, Google Cloud Storage und alles, was rclone erreichen kann.

Ein Borg-Repository besteht ebenfalls aus Dateien auf der Festplatte, aber Borg kommuniziert niemals über einen einfachen Transport damit. Für ein entferntes Repository startet Borg borg serve auf der Gegenseite über SSH und spricht sein eigenes Protokoll mit diesem Prozess. Die Serverseite leistet echte Arbeit: Sie verwaltet das Repository, führt Transaktionen aus und beantwortet Index-Anfragen. Deshalb hat die stabile Borg 1.4-Serie kein S3-Backend. Es gibt keinen Prozess, der innerhalb eines Buckets ausgeführt werden könnte. Borg 2 ändert dies: Es verlagert die Speicherung in eine neue Schicht namens borgstore, und die Dokumentation beschreibt sftp://, rclone:remote:path und s3: oder b2: Repository-URLs. Borg 2 ist jedoch noch eine Beta-Version, die laut Projekt nicht produktiv eingesetzt werden sollte; für echte Backups besteht die S3-Lücke daher weiterhin.

Diese einzelne Designentscheidung führt zu den meisten der unten aufgeführten praktischen Unterschiede.

# restic: the repository is a URL, and the backend is part of it
restic -r /srv/restic-repo init
restic -r sftp:backup@198.51.100.20:/srv/restic-repo init
restic -r s3:s3.us-east-1.amazonaws.com/my-backup-bucket init

# borg: a local path, or user@host:path, with borg installed on that host
borg init --encryption=repokey-blake2 /srv/borg/vps1
borg init --encryption=repokey-blake2 backup@198.51.100.20:/srv/borg/vps1

Verschlüsselung: Eine der beiden Optionen kann deaktiviert werden

Restic ist immer verschlüsselt. Es gibt keinen unverschlüsselten Modus. restic init fordert ein Passwort an, leitet daraus mit scrypt einen Schlüssel ab und verschlüsselt und authentifiziert jede danach geschriebene Pack-Datei. Wenn Sie das Passwort verlieren, sind die Daten verloren, weil es absichtlich keinen Wiederherstellungsweg gibt.

Bei Borg wird die Verschlüsselung beim Erstellen des Repositorys ausgewählt. Diese Auswahl ist dauerhaft. borg init --encryption=repokey speichert den verschlüsselten Schlüssel im Repository. Dadurch reicht die Passphrase für die Wiederherstellung aus. --encryption=keyfile speichert den Schlüssel auf dem Client in ~/.config/borg/keys/. Wer das gesamte Repository stiehlt, kann damit allein nichts anfangen. Sie müssen diese Schlüsseldatei daher separat sichern. Andernfalls können Sie Ihre Archive nicht lesen. Für jeden Modus gibt es außerdem eine -blake2-Variante, die statt HMAC-SHA256 mit BLAKE2b authentifiziert. Auf Hardware ohne SHA-Beschleunigung ist sie schneller. --encryption=none ist ebenfalls verfügbar. Diese Option ist sinnvoll, wenn das Repository auf einer verschlüsselten Festplatte liegt, die Ihnen gehört.

Die praktische Regel lautet: repokey-blake2 für ein normales Server-Backup, keyfile, wenn das Repository an einem Ort liegt, dem Sie nicht vollständig vertrauen, und niemals none auf einem gemieteten Rechner.

Kompression und warum restic sie erst spät erhielt

Borg unterstützt Kompression von Beginn an. Der Standardwert ist lz4, da er schnell genug ist, um für alle Daten aktiviert zu bleiben. zstd akzeptiert Stufen von 1 bis 22 und verwendet standardmäßig 3. zlib und lzma sind für Anwendungsfälle gedacht, bei denen die Speicherplatzersparnis wichtiger ist als die benötigte Zeit. auto führt eine Heuristik pro Chunk aus, damit bereits komprimierte Daten nicht doppelt verarbeitet werden.

borg create --compression zstd,3 --stats --progress \
  /srv/borg/vps1::'{hostname}-{now}' /etc /home /srv

Restic bot bis zum Repository-Format 2, das restic 0.14.0 oder neuer erfordert, keinerlei Kompression. Format 2 ist mittlerweile der Standard für neue Repositories, und die Kompression wird mit --compression auf einen von fünf Werten eingestellt: auto (der Standardwert), off, fastest, better oder max. Die Modi fastest und better wurden mit restic 0.19.0 eingeführt; ältere Binärdateien akzeptieren daher nur auto, off und max. Ein altes Repository im Format 1 bleibt unkomprimiert, bis eine Migration durchgeführt wird. Wenn Ihr restic-Repository also älter als Version 0.14 ist und Sie es nie migriert haben, belegen Textdateien, Logs und Datenbank-Dumps weiterhin den vollen Speicherplatz.

Remote-Ziele: S3 im Vergleich zu SSH

Hier fällt die Entscheidung normalerweise.

Für den Zugriff von Restic auf S3 müssen die Zugangsdaten in der Umgebung gesetzt sein. Weitere Dienste müssen nirgendwo laufen. Dasselbe Muster funktioniert mit einem Bucket, den Sie selbst betreiben. Das ist eine gängige Kombination: Betreiben Sie MinIO für eine S3-API auf Ihrem eigenen VPS und konfigurieren Sie restic für den Zugriff darauf.

export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export RESTIC_REPOSITORY=s3:https://objects.example.com/backups
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic init
restic backup /etc /home /srv --exclude-caches

Für den Zugriff von Borg auf ein entferntes Repository benötigen Sie SSH sowie eine Borg-Installation auf der Gegenstelle. Die dort installierte Version muss mit dem Client kompatibel sein. Das ist problematisch, wenn Sie die Gegenstelle nicht verwalten. Wenn es sich um einen zweiten Server handelt, den Sie bereits administrieren, entsteht daraus kein zusätzlicher Aufwand. Dafür erhalten Sie den stärksten Schutz vor Ransomware, den eines der beiden Werkzeuge bietet: einen SSH-Schlüssel mit Append-only-Berechtigung. Erzwingen Sie, dass der Schlüssel borg serve ausführt. Dann kann der Client Archive hinzufügen, aber nicht löschen. Ein kompromittierter Rechner kann dadurch seine eigene Sicherungshistorie nicht entfernen.

command="borg serve --append-only --restrict-to-path /srv/borg/vps1",restrict ssh-ed25519 AAAA...

Bei restic gibt es eine entsprechende Möglichkeit nur beim Betrieb eines eigenen REST-Servers, der einen Append-only-Modus unterstützt. Bei einfachem S3 erreichen Sie denselben Effekt über eine Bucket-Richtlinie oder Object Lock. Dafür ist der Provider zuständig, nicht restic. Sichern Sie auch den Transport ab. Die SSH-Seite verdient dieselbe Sorgfalt wie jeder andere Login: Wenden Sie SSH nur mit Schlüssel und einem eingeschränkten authorized_keys-Eintrag auf das Backup-Konto an.

Geschwindigkeit: Was die jeweilige Architektur bedeutet

Keines der Projekte veröffentlicht einen Benchmark, dem Sie für Ihre eigenen Daten vertrauen sollten. Leiten Sie die zu erwartende Leistung stattdessen aus dem jeweiligen Verfahren ab.

Borg über SSH ist bei einer Verbindung mit hoher Latenz schnell, weil die Serverseite intelligent arbeitet. Der Client stellt eine Anfrage, der entfernte Prozess borg serve beantwortet sie anhand des Repository-Index, und die Transaktion wird an einer Stelle festgeschrieben. Die Suche nach Chunks führt dadurch nicht für jede kleine Datei zu einer zusätzlichen Netzwerk-Rundreise.

Restic auf einem Objektspeicher hat keine Serverseite. Deshalb muss es sein Abbild aus Index- und Pack-Dateien erstellen, die es über HTTP abruft. Damit die Anzahl der Anfragen überschaubar bleibt, bündelt es vor dem Upload viele kleine Chunks in größeren Pack-Dateien. Außerdem hält es unter ~/.cache/restic einen lokalen Cache vor, damit der Index beim nächsten Lauf nicht erneut vollständig abgerufen werden muss. Wenn Sie diesen Cache löschen, ist das nächste Backup langsam, weil Restic ihn neu aufbaut. Bei einer Verbindung mit hoher Latenz und Millionen kleiner Dateien ist dies der Fall, in dem sich Restic bei denselben Daten langsamer als Borg anfühlt.

Auf einer lokalen Festplatte oder in einem schnellen LAN ist der Unterschied meist gering. Beide Werkzeuge werden dann überwiegend dadurch begrenzt, wie schnell sie die Quelldaten lesen und hashen können.

Sperren und mehrere Maschinen sichern

Borg 1.4 sperrt das Repository für die gesamte Operation exklusiv. Zwei Clients können nicht gleichzeitig in ein Repository schreiben: Der zweite wartet und schlägt anschließend wegen eines Lock-Timeouts fehl. Das unterstützte Muster ist ein Repository pro Client. Dadurch findet die Deduplizierung nur innerhalb des Repositorys einer Maschine statt. Zehn nahezu identische Server speichern also zehn Kopien desselben Basissystems.

Restic erlaubt es mehreren Clients, gleichzeitig in ein Repository zu sichern, weil ein Backup eine gemeinsame Sperre verwendet und nur Wartungsarbeiten wie prune eine exklusive Sperre benötigen. Zehn ähnliche Server, die auf ein gemeinsames restic-Repository zeigen, deduplizieren untereinander. Der zweite Server speichert dadurch oft nur sehr wenig. Der Nachteil ist der größere Schadensradius: Ein Passwort und ein Repository enthalten alles. Geht das Passwort verloren, sind alle zehn Server betroffen.

Retention: forget und anschließend prune gegenüber prune und anschließend compact

Beide Werkzeuge trennen die Entscheidung, was aufbewahrt werden soll, von der Rückgewinnung des Speicherplatzes. Bei beiden müssen Sie den zweiten Schritt ausführen.

restic forget --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --prune
restic check

borg prune --list --glob-archives '{hostname}-*' \
  --keep-daily=7 --keep-weekly=4 --keep-monthly=6 /srv/borg/vps1
borg compact /srv/borg/vps1

Die Fehlerquelle ist bei beiden Werkzeugen gleich und sollte klar benannt werden. In Borg entfernt borg prune Archive, gibt aber nicht automatisch Speicherplatz auf dem Datenträger frei. Der Speicherplatz wird erst wieder verfügbar, wenn borg compact ausgeführt wird. Ein cron-Job, der prune ausführt, aber nie compact, lässt ein Repository daher unbegrenzt wachsen, während die Liste der Archive kurz bleibt. In restic entfernt forget ohne --prune lediglich Verweise auf Snapshots. Die Daten bleiben erhalten, bis prune ausgeführt wird.

Führen Sie nach dem Pruning restic check aus. Dadurch werden die Repository-Strukturen überprüft. Außerdem wird gemeldet, ob etwas beschädigt ist. Das ist deutlich besser, als die Beschädigung erst während einer Wiederherstellung zu entdecken.

Wiederherstellung als einziger aussagekräftiger Test

Beide Tools binden einen Snapshot ein, sodass Sie ihn durchsuchen können. Das ist der schnellste Weg, eine einzelne Datei wiederherzustellen.

restic snapshots
restic restore latest --target /tmp/restore --include /etc/nginx
restic mount /mnt/restore

borg list /srv/borg/vps1
borg extract --list /srv/borg/vps1::vps1-2026-07-30T02:00:00 etc/nginx
borg mount /srv/borg/vps1::vps1-2026-07-30T02:00:00 /mnt/restore

Beachten Sie die Pfadangabe in borg extract. Pfade in einem Archiv werden ohne führenden Schrägstrich gespeichert. Daher ist etc/nginx korrekt. /etc/nginx findet dagegen nichts und extrahiert nichts. Es wird keine Fehlermeldung ausgegeben, die den Grund nennt. Die Extraktion schreibt außerdem in das aktuelle Arbeitsverzeichnis. Wechseln Sie daher zuerst in ein temporäres Verzeichnis. Andernfalls überschreiben Sie produktive Dateien mit alten Versionen.

Eine Wiederherstellung, die ohne Fehler abgeschlossen wird, ist noch kein Beweis. Die darauf aufbauende Anwendung hat eigene Anforderungen daran, wann eine Wiederherstellung vollständig ist. Ein aus einer Kopie des Postgres-Datenverzeichnisses wiederhergestellter Immich-Server kann beispielsweise alle Fotos auf der Festplatte enthalten, während die Zeitleiste leer ist. Genau dieses Problem muss die Sicherung und Wiederherstellung von Immich umgehen.

Unabhängig vom gewählten Tool ist der Zeitplan nur die halbe Arbeit. Führen Sie regelmäßig eine Wiederherstellung in ein temporäres Verzeichnis durch und überwachen Sie diesen Vorgang tatsächlich. Der ausführliche Ablauf in der restic-Sicherungsanleitung für einen VPS verwendet dafür ebenfalls einen systemd-Timer.

Welche Lösung eignet sich für welche Aufgabe?

Wählen Sie restic, wenn das Ziel ein Objektspeicher ist, wenn Sie nur eine Binärdatei und keine Software auf der Gegenseite benötigen, wenn mehrere Rechner ihre Daten gegenseitig deduplizieren sollen oder wenn die Wiederherstellung möglicherweise nicht durch Sie erfolgt. restic besteht aus einer einzelnen statisch gelinkten Binärdatei und einer URL für ein Repository. Das ist unter betrieblichen Gesichtspunkten schwer zu übertreffen.

Wählen Sie Borg, wenn das Ziel ein von Ihnen kontrollierter Linux-Rechner ist, wenn die Verbindung eine hohe Latenz aufweist und der Datensatz aus Millionen kleiner Dateien besteht, wenn Sie den SSH-Schlüssel mit Append-only-Berechtigung als Schutz gegen Ransomware einsetzen möchten oder wenn Sie die Komprimierung pro Auftrag anpassen möchten. Borg ist das ältere Werkzeug. Seine stabile Versionen entwickeln sich langsam weiter. Bei Backup-Software ist das ein Vorteil.

Beide Lösungen sind vertretbare Entscheidungen. Die falsche Entscheidung ist die Lösung, die Sie nie testen. Wenn Sie bereits Dumps auf Anwendungsebene erstellen, behalten Sie diese bei: Das Muster aus der Nextcloud-Docker-Konfiguration mit Datenbank-Dumps gilt für beide Werkzeuge, weil eine Live-Datenbankdatei, die zu einem beliebigen Zeitpunkt kopiert wurde, kein Backup einer Datenbank ist.

FAQ

Sind restic oder BorgBackup schneller?

Auf einem lokalen Datenträger oder in einem schnellen LAN liegen beide nah beieinander; beide werden letztlich durch die Lese- und Hash-Geschwindigkeit der Quelle limitiert. Borg gewinnt meist bei einer SSH-Verbindung mit hoher Latenz und sehr vielen kleinen Dateien, da ein borg serve-Prozess auf der Gegenseite Index-Anfragen beantwortet, ohne dass für jeden Chunk ein Netzwerk-Roundtrip erforderlich ist. Restic gewinnt meist, wenn das Ziel ein Objektspeicher ist, da das stabile Borg dies gar nicht unterstützt.

Kann BorgBackup auf S3 oder Backblaze B2 sichern?

Nicht mit der stabilen 1.4-Serie. Ein Borg 1.4-Repository wird durch den borg serve-Prozess über SSH bedient, und ein solcher Prozess läuft nicht innerhalb eines Buckets. Borg 2 fügt s3:-, b2:- und rclone:-Repository-URLs über seine borgstore-Schicht hinzu, aber mit Stand Oktober 2026 ist Borg 2 noch im Beta-Stadium und das Projekt rät von einem produktiven Einsatz ab. Bei 1.4 umgehen Anwender diese Lücke, indem sie den Objektspeicher mittels rclone als Dateisystem einbinden. Die Borg-FAQ rät von Netzwerkdateisystemen für die Repository-Speicherung ab und warnt, dass FUSE und Netzwerkdateisysteme zu Verlangsamungen oder Datenbeschädigungen führen können. Wenn Sie heute Objektspeicher für produktive Backups benötigen, verwenden Sie restic.

Kann ich beide Tools für dieselben Daten verwenden?

Ja, manche Anwender tun dies: Borg auf einen zweiten Server für eine schnelle lokale Wiederherstellung, restic auf Objektspeicher für die externe Kopie. Da sie keine Ressourcen teilen, fallen die Lese- und Hash-Kosten doppelt an, und Sie müssen zwei Passwörter sicher verwahren. Führen Sie dies nur durch, wenn Sie beide Wiederherstellungsvorgänge getestet haben.

Was passiert, wenn ich das Repository-Passwort verliere?

Die Daten sind bei beiden Tools nicht wiederherstellbar. Restic leitet seinen Schlüssel mittels scrypt aus dem Passwort ab, es gibt keine Umgehungsmöglichkeit. Borg speichert im repokey-Modus den verschlüsselten Schlüssel innerhalb des Repositorys, sodass die Passphrase allein zur Wiederherstellung ausreicht; im keyfile-Modus benötigen Sie zusätzlich die Schlüsseldatei aus ~/.config/borg/keys/. Bewahren Sie das Passwort in einem Passwort-Manager auf, der sich nicht auf dem zu sichernden Server befindet, und exportieren Sie den Borg-Schlüssel mit borg key export, falls Sie keyfile verwenden.

Sollte ich auf Borg 2.0 warten?

Nein. Mit Stand Oktober 2026 ist Borg 2.0 noch im Beta-Stadium, bei Version 2.0.0b25 (veröffentlicht am 27. September 2026), und das Projekt kennzeichnet es nur für Testzwecke. Die stabile Serie ist 1.4, aktuell 1.4.5. Beginnen Sie jetzt mit 1.4. Borg 2 ändert das Repository-Format und liefert einen dokumentierten Upgrade-Pfad (borg transfer --from-borg1), sodass Sie bei einem heutigen Start nicht feststecken. Borg 2 ist zudem die Version, in der native S3-, B2- und rclone-Unterstützung Einzug hält, sobald sie stabil ist.