Restic oder BorgBackup: Was ist besser für Backups?

Restic im Vergleich zu BorgBackup, in einem Absatz

Restic und BorgBackup erfüllen beide dieselbe Kernaufgabe: deduplizierte, verschlüsselte, inkrementelle Backups eines Linux-Servers. Der entscheidende Unterschied bei der Wahl ist der Speicherort des Backups. Restic unterstützt S3 und andere Object-Storage-APIs nativ, sodass ein Bucket ein direktes Ziel ohne zusätzliche Software auf der Gegenseite darstellt. Borg erfordert die Installation des Programms borg auf dem Rechner, der das Repository hostet, da ein Borg-Repository von einem Prozess und nicht von einem Dateisystem oder einer API bereitgestellt wird. Wenn das Ziel 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 geringfügig. Beide verwenden inhaltsbasierte Chunking-Verfahren, sodass bei einem 40 GB großen Verzeichnis, das sich um 200 MB geändert hat, auch nur etwa 200 MB hochgeladen werden. Beide verschlüsseln die Daten auf dem Client. Beide können einen Snapshot mittels FUSE (Filesystem in Userspace) einbinden, damit Sie einzelne Dateien kopieren können. Stand Juli 2026 ist restic bei Version 0.19.1 und die stabile Serie von Borg ist 1.4, aktuell in Version 1.4.5. Borg 2.0 befindet sich seit Jahren im Beta-Stadium und ist weiterhin nur als Testversion gekennzeichnet, daher sollten Sie heute Version 1.4 einsetzen.

Das Repository-Modell ist der eigentliche Unterschied

Ein restic-Repository ist ein Verzeichnis von Dateien: config, keys/, snapshots/, index/ und data/, die voller Pack-Dateien stecken. 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 Binärdatei 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 die Transaktion aus und beantwortet Index-Anfragen. Deshalb hat Borg kein S3-Backend und deshalb hat das Projekt bisher keines hinzugefügt. Es gibt keinen Prozess, der innerhalb eines Buckets ausgeführt werden kann.

Diese einzelne Design-Entscheidung 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 davon lässt sich deaktivieren

Restic ist immer verschlüsselt. Es gibt keinen unverschlüsselten Modus. restic init fragt nach einem Passwort, leitet daraus mit scrypt einen Schlüssel ab, und jede danach geschriebene Pack-Datei wird verschlüsselt und authentifiziert. Geht das Passwort verloren, sind die Daten weg, da es konzeptbedingt keinen Wiederherstellungspfad gibt.

Borg macht die Verschlüsselung bei der Erstellung des Repositorys zu einer Wahlmöglichkeit, und diese Wahl ist permanent. borg init --encryption=repokey speichert den verschlüsselten Schlüssel innerhalb des Repositorys, sodass die Passphrase allein zur Wiederherstellung ausreicht. --encryption=keyfile speichert den Schlüssel auf dem Client in ~/.config/borg/keys/. Wer also das gesamte Repository stiehlt, hat dennoch nichts in der Hand; Sie müssen diese Schlüsseldatei separat sichern, da Ihre Archive sonst unlesbar sind. Jeder Modus hat eine -blake2-Variante, die mit BLAKE2b anstelle von HMAC-SHA256 authentifiziert, was auf Hardware ohne SHA-Beschleunigung schneller ist. --encryption=none existiert ebenfalls und ist eine echte Option, wenn das Repository auf einer verschlüsselten Festplatte liegt, die Ihnen gehört.

Die praktische Regel: 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 einer gemieteten Maschine.

Komprimierung und warum restic sie erst spät erhielt

Borg unterstützt Komprimierung seit Beginn. Der Standardwert ist lz4, da dieser 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 Fälle vorgesehen, in denen Speicherplatz wichtiger ist als Verarbeitungszeit. 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 keinerlei Komprimierung an, welches restic 0.14.0 oder neuer erfordert. Format 2 ist mittlerweile der Standard für neue Repositories, und die Komprimierung wird mit --compression auf die Werte auto, off oder max eingestellt. Ein altes Repository im Format 1 bleibt unkomprimiert, bis Sie es migrieren. Wenn Ihr restic-Repository also älter als 0.14 ist und Sie es nie migriert haben, belegen Textdateien, Protokolle und Datenbank-Dumps weiterhin den vollen Speicherplatz.

Remote-Ziele: S3 versus SSH

Hier wird üblicherweise die Entscheidung getroffen.

Damit restic auf S3 zugreifen kann, werden lediglich Anmeldedaten in der Umgebung benötigt; es muss sonst nirgendwo etwas laufen. Das gleiche Schema funktioniert auch mit einem selbst gehosteten Bucket, was eine häufige Kombination ist: Betreiben Sie MinIO für eine S3-API auf Ihrem eigenen VPS und lassen Sie restic darauf zeigen.

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

Damit Borg ein entferntes Repository erreichen kann, werden SSH sowie eine Borg-Installation auf der Gegenseite benötigt. Zudem muss die dortige Version mit dem Client kompatibel sein. Dies stellt einen Mehraufwand dar, wenn die Gegenseite nicht unter Ihrer Kontrolle steht. Wenn es sich bei der Gegenseite jedoch um einen zweiten Server handelt, den Sie bereits verwalten, ist dies vernachlässigbar. Zudem erhalten Sie damit die stärkste Kontrolle gegen Ransomware, die eines der beiden Werkzeuge bietet: einen SSH-Key mit "Append-only"-Berechtigung. Erzwingen Sie für den Key die Ausführung von borg serve, sodass der Client zwar Archive hinzufügen, diese aber nicht löschen kann. Ein kompromittierter Rechner kann somit seine eigene Historie nicht löschen.

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

Restic bietet eine vergleichbare Funktion nur dann, wenn Sie den eigenen REST-Server betreiben, welcher einen "Append-only"-Modus unterstützt. Bei einfachem S3 erreichen Sie denselben Effekt über Bucket-Richtlinien oder Object Lock; dies ist die Aufgabe des Anbieters, nicht die von restic. Sichern Sie auch den Transport ab, da die SSH-Seite die gleiche Sorgfalt wie jeder andere Login erfordert: Verwenden Sie SSH nur mit Keys und einem eingeschränkten authorized_keys-Eintrag für das Backup-Konto.

Geschwindigkeit: Was die jeweiligen Konzepte bedeuten

Keines der Projekte veröffentlicht Benchmarks, denen Sie für Ihre eigenen Daten vertrauen sollten. Leiten Sie die Leistung daher aus dem jeweiligen Mechanismus ab.

Borg over SSH ist bei einer Verbindung mit hoher Latenz schnell, da die Serverseite intelligent agiert. Der Client stellt eine Anfrage, der entfernte borg serve-Prozess beantwortet diese anhand des Repository-Index und die Transaktion wird an einem Ort abgeschlossen. Suchvorgänge nach Chunks führen nicht für jede kleine Datei zu einem Netzwerk-Roundtrip.

Restic auf Objektspeichern besitzt keine Serverseite. Es muss sein Abbild daher aus Index- und Pack-Dateien zusammensetzen, die es per HTTP abruft. Um die Anzahl der Anfragen in einem vernünftigen Rahmen zu halten, packt es viele kleine Chunks in größere Pack-Dateien, bevor diese hochgeladen werden. Zudem unterhält es einen lokalen Cache in ~/.cache/restic, damit der nächste Durchlauf nicht den gesamten Index erneut abrufen muss. Löschen Sie diesen Cache, ist das nächste Backup langsam, während er neu aufgebaut wird. Bei einer Verbindung mit hoher Latenz und Millionen kleiner Dateien ist dies der Fall, in dem sich restic langsamer anfühlt als Borg bei identischen Daten.

Auf einer lokalen Festplatte oder in einem schnellen LAN schließt sich diese Lücke weitgehend. Beide Werkzeuge werden dann primär dadurch limitiert, wie schnell sie die Quelle lesen und hashen können.

Sperren und Sichern mehrerer Maschinen

Borg 1.4 setzt für die gesamte Operation eine exklusive Sperre auf das Repository. Zwei Clients, die gleichzeitig in ein Repository schreiben, funktionieren nicht: Der zweite Client wartet und schlägt dann mit einem Sperr-Timeout fehl. Das unterstützte Muster ist ein Repository pro Client. Das bedeutet auch, dass die Deduplizierung nur innerhalb des Repositorys einer Maschine stattfindet, sodass zehn nahezu identische Server zehn Kopien desselben Basissystems speichern.

Restic erlaubt es mehreren Clients, gleichzeitig Sicherungen in ein Repository zu schreiben, da eine Sicherung eine geteilte Sperre verwendet und nur Wartungsarbeiten wie prune eine exklusive Sperre erfordern. Zehn ähnliche Server, die auf ein restic-Repository verweisen, deduplizieren gegeneinander, und der zweite Server speichert oft nur sehr wenige Daten. Der Preis dafür ist der Schadensradius: Ein Passwort und ein Repository enthalten alles, sodass der Verlust des Passworts zum Verlust aller zehn Sicherungen führt.

Aufbewahrung: forget und prune im Vergleich zu prune und compact

Beide Werkzeuge trennen die Entscheidung „was soll behalten werden“ von der „Freigabe des Speicherplatzes“. Bei beiden müssen Sie den zweiten Schritt manuell 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 Falle ist bei beiden Werkzeugen identisch und sollte klar benannt werden. In Borg entfernt borg prune zwar Archive, gibt aber von sich aus keinen Speicherplatz frei. Der Speicherplatz wird erst durch den Befehl borg compact freigegeben. Ein Cron-Job, der nur aufräumt (prune), aber niemals komprimiert (compact), hinterlässt ein Repository, das unendlich wächst, während die Archivliste kurz bleibt. In restic löscht forget ohne --prune lediglich Snapshot-Referenzen; die Daten verbleiben im Speicher, bis ein Prune-Vorgang ausgeführt wird.

Führen Sie nach dem Aufräumen restic check aus. Dieser Befehl überprüft die Repository-Strukturen und meldet, falls Daten beschädigt sind. Dies ist deutlich besser, als einen Defekt erst während einer Wiederherstellung zu bemerken.

Wiederherstellung, der einzige Test, der zählt

Beide Werkzeuge binden einen Snapshot ein, damit Sie ihn durchsuchen können. Dies ist der schnellste Weg, um 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 das Pfadformat in borg extract. Pfade innerhalb eines Archivs werden ohne führenden Schrägstrich gespeichert. Daher ist etc/nginx korrekt, während /etc/nginx auf nichts passt und nichts extrahiert, ohne dass eine Fehlermeldung den Grund nennt. Die Extraktion schreibt zudem in das aktuelle Arbeitsverzeichnis. Wechseln Sie daher zuerst in ein temporäres Verzeichnis, da Sie sonst aktive Dateien mit alten überschreiben.

Unabhängig davon, welches Werkzeug Sie wählen, ist der Zeitplan nur die halbe Miete. Führen Sie eine Wiederherstellung in ein temporäres Verzeichnis nach einem Zeitplan durch, den Sie tatsächlich überwachen, genau wie es die vollständige Anleitung in dem restic Backup-Leitfaden für einen VPS mit einem systemd-Timer beschreibt.

Welche Lösung für welchen Zweck

Wählen Sie restic, wenn das Ziel ein Objektspeicher ist, wenn Sie eine einzelne Binärdatei ohne zusätzliche Software auf der Gegenseite benötigen, wenn mehrere Maschinen ihre Daten gegenseitig deduplizieren sollen oder wenn die Person, die die Wiederherstellung durchführt, nicht Sie selbst sind. Es handelt sich um eine einzelne statische Binärdatei mit einer URL für ein Repository, was betrieblich kaum zu übertreffen ist.

Wählen Sie Borg, wenn das Ziel ein Linux-System ist, das Sie kontrollieren, wenn die Verbindung eine hohe Latenz aufweist und der Datensatz aus Millionen kleiner Dateien besteht, wenn Sie einen "Append-only"-SSH-Key als Schutz gegen Ransomware benötigen oder wenn Sie die Kompression pro Aufgabe individuell anpassen möchten. Es ist das ältere Werkzeug, dessen stabile Serie sich nur langsam weiterentwickelt; bei Backup-Software ist dies ein Qualitätsmerkmal.

Beide Lösungen sind korrekt. Die falsche Antwort ist diejenige, die Sie niemals testen. Wenn Sie bereits Dumps auf Anwendungsebene erstellen, behalten Sie diese bei: Das Muster in der Nextcloud-auf-Docker-Einrichtung mit Datenbank-Dumps lässt sich auf beide Werkzeuge anwenden, da eine laufende Datenbankdatei, die zu einem beliebigen Zeitpunkt kopiert wurde, kein Backup einer Datenbank darstellt.

FAQ

Sind restic oder BorgBackup schneller?

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

Kann BorgBackup Sicherungen auf S3 oder Backblaze B2 schreiben?

Nicht direkt. Ein Borg-Repository wird über den borg serve-Prozess via SSH bereitgestellt; ein solcher Prozess läuft nicht innerhalb eines Buckets. Als Umgehungslösung wird Object Storage mittels rclone als Dateisystem eingebunden. Das Borg-Projekt rät davon ab, da ein Verbindungsabbruch während einer Transaktion das Repository beschädigen kann. Wenn Sie Object Storage benötigen, verwenden Sie restic.

Kann ich beide Werkzeuge für dieselben Daten verwenden?

Ja, manche Anwender tun dies: Borg auf einen zweiten Server für eine schnelle lokale Wiederherstellung und restic auf Object Storage für die externe Kopie. Da sie keine Daten teilen, fallen die Lese- und Hash-Kosten doppelt an und Sie müssen zwei Passwörter sicher verwalten. Führen Sie dies nur durch, wenn Sie die Wiederherstellung mit beiden Werkzeugen getestet haben.

Was passiert, wenn ich das Repository-Passwort verliere?

Die Daten sind bei beiden Werkzeugen unwiederbringlich verloren. Restic leitet seinen Schlüssel mittels scrypt vom Passwort ab; es gibt keine Umgehung. Borg speichert im Modus repokey den verschlüsselten Schlüssel im Repository, sodass die Passphrase allein genügt. Im Modus keyfile benötigen Sie zusätzlich die Schlüsseldatei aus ~/.config/borg/keys/. Bewahren Sie das Passwort in einem Passwort-Manager auf, der nicht auf dem zu sichernden Server liegt, und exportieren Sie den Borg-Schlüssel mit borg key export, falls Sie keyfile verwenden.

Sollte ich auf Borg 2.0 warten?

Nein. Stand Juli 2026 befindet sich Borg 2.0 noch im Beta-Stadium, aktuell bei 2.0.0b22, und das Projekt kennzeichnet es ausschließlich 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 mit, sodass Sie bei einem heutigen Start nicht blockiert werden.