Restic oder BorgBackup: Welches Backup-Tool passt?

Restic vs. BorgBackup in einem Absatz

Restic und BorgBackup übernehmen beide dieselbe Kernaufgabe: deduplizierte, verschlüsselte und inkrementelle Backups eines Linux-Servers. Für die Auswahl ist entscheidend, wohin das Backup geschrieben wird. Restic unterstützt S3 und andere Object-Storage-APIs nativ. Ein Bucket ist daher ein direkt nutzbares Ziel, ohne dass am anderen Ende Software installiert werden muss. Für Borg muss das Programm borg auf dem Rechner installiert sein, auf dem das Repository liegt. Ein Borg-Repository wird von einem Prozess bereitgestellt, nicht von einem Dateisystem oder einer API. Wenn Ihr Ziel Object Storage ist, ist die Entscheidung damit bereits gefallen. Wenn Ihr Ziel ein zweiter Linux-Rechner ist, den Sie kontrollieren, kommt Borg infrage und ist häufig schneller.

Alle anderen Unterschiede sind weniger bedeutend. Beide teilen Dateien mithilfe einer inhaltsdefinierten Chunk-Aufteilung auf. Wenn sich in einem Verzeichnis mit 40 GB Daten 200 MB ändern, werden daher ungefähr 200 MB hochgeladen. Beide verschlüsseln die Daten auf dem Client. Beide stellen einen Snapshot mit FUSE (filesystem in userspace) bereit, sodass Sie einzelne Dateien daraus kopieren können. Im Juli 2026 ist Restic bei 0.19.1, und die stabile Borg-Reihe ist 1.4, aktuell in Version 1.4.5. Borg 2.0 befindet sich seit Jahren in der Beta-Phase und ist weiterhin nur als testing gekennzeichnet. Daher sollten Sie heute 1.4 einsetzen.

Das Repository-Modell ist der eigentliche Unterschied

Ein restic-Repository ist ein Verzeichnis mit Dateien: config, keys/, snapshots/, index/ und data/, die mit Pack-Dateien gefüllt sind. Zum Lesen des Repositorys ist nichts Weiteres erforderlich. Deshalb kann restic so viele Backends verwenden. Jeder Speicher, der Blobs speichern, abrufen, auflisten und löschen kann, kann ein restic-Repository aufnehmen. Dadurch unterstützt ein einzelnes Binary lokale Pfade, SFTP, den eigenen REST-Server, S3, Backblaze B2, Azure, Google Cloud Storage und alles, was rclone erreicht.

Ein Borg-Repository besteht ebenfalls aus Dateien auf dem Datenträger. Borg greift jedoch niemals über einen einfachen Transport darauf zu. Bei einem entfernten Repository startet Borg über SSH auf der entfernten Seite borg serve und verwendet für die Kommunikation mit diesem Prozess sein eigenes Protokoll. Die Serverseite führt die eigentliche Arbeit aus: Sie enthält das Repository, wendet die Transaktion an und beantwortet Abfragen an den Index. Deshalb besitzt Borg kein S3-Backend und hat auch keines hinzugefügt. In einem Bucket gibt es keinen Prozess, der ausgeführt werden kann.

Diese einzelne Designentscheidung verursacht die meisten praktischen Unterschiede im Folgenden.

# 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: Bei einem von beiden kann sie deaktiviert werden

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

Bei Borg ist die Verschlüsselung eine Option bei der Repository-Erstellung. Diese Auswahl ist dauerhaft. borg init --encryption=repokey speichert den verschlüsselten Schlüssel im Repository, sodass die Passphrase allein für die Wiederherstellung ausreicht. --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, sonst sind Ihre Archive nicht lesbar. Für jeden Modus gibt es 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.

Komprimierung und warum restic sie spät eingeführt hat

Borg komprimiert seit Beginn. Der Standard ist lz4, weil diese Einstellung schnell genug ist, um sie überall aktiviert zu lassen. zstd akzeptiert die Stufen 1 bis 22 und verwendet standardmäßig Stufe 3. zlib und lzma sind für Fälle vorgesehen, in denen die Dateigröße wichtiger ist als die Laufzeit. auto verwendet für jeden Chunk eine Heuristik, damit bereits komprimierte Daten nicht ein zweites Mal komprimiert werden.

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

Restic unterstützte bis zum Repository-Format 2 überhaupt keine Komprimierung. Dafür ist restic 0.14.0 oder neuer erforderlich. Format 2 ist inzwischen der Standard für neue Repositories. Die Komprimierung wird mit --compression und den Werten auto, off oder max festgelegt. Ein Repository im alten Format 1 bleibt unkomprimiert, bis Sie es migrieren. Wenn Ihr restic-Repository älter als Version 0.14 ist und Sie es nie migriert haben, belegen Textdateien, Logs und Datenbank-Dumps weiterhin ihre vollständige Größe.

Remote-Ziele: S3 im Vergleich zu SSH

An dieser Stelle fällt die Entscheidung normalerweise.

Für den Zugriff von restic auf S3 benötigen Sie Zugangsdaten in der Umgebung. Auf der Gegenseite muss kein weiterer Dienst laufen. Dasselbe Muster funktioniert mit einem Bucket, den Sie selbst betreiben. Das ist eine häufige Kombination: Betreiben Sie MinIO für eine S3-API auf Ihrem eigenen VPS und richten Sie restic darauf aus.

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 Gegenseite. Die dort installierte Version muss mit dem Client kompatibel sein. Das ist umständlich, wenn Sie die Gegenseite nicht verwalten. Wenn es sich um einen zweiten Server handelt, den Sie bereits administrieren, spielt es keine Rolle. Dafür erhalten Sie den stärksten Schutz vor Ransomware, den eines der beiden Werkzeuge bietet: einen SSH-Schlüssel, der nur Anhänge zulässt. Zwingen Sie den Schlüssel, borg serve auszuführen. Dann kann der Client Archive hinzufügen, sie aber nicht löschen. Ein kompromittierter Rechner kann dadurch seine eigene Historie nicht löschen.

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

Bei restic gibt es eine gleichwertige Möglichkeit nur mit dem eigenen REST-Server, der einen Modus nur zum Anhängen unterstützt. Bei einfachem S3 erreichen Sie denselben Effekt über eine Bucket-Richtlinie oder Object Lock. Das ist Aufgabe des Providers und nicht von 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 einzelnen Designs bedeuten

Keines der beiden Projekte veröffentlicht einen Benchmark, dem Sie für Ihre eigenen Daten vertrauen sollten. Leiten Sie die Einschätzung daher aus dem jeweiligen Mechanismus ab.

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

Restic auf Object Storage hat keine Serverseite. Daher muss es sein Abbild aus Indexdateien 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 in ~/.cache/restic einen lokalen Cache vor, damit beim nächsten Lauf nicht der gesamte Index erneut abgerufen werden muss. Wenn Sie diesen Cache löschen, ist die nächste Sicherung langsam, während 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 schließt sich der Abstand größtenteils. Beide Werkzeuge werden dann hauptsächlich dadurch begrenzt, wie schnell sie die Quelldaten lesen und hashen können.

Sperren und mehrere Rechner sichern

Borg 1.4 setzt während des gesamten Vorgangs eine exklusive Sperre auf das Repository. Zwei Clients können nicht gleichzeitig in ein Repository schreiben: Der zweite wartet und schlägt anschließend wegen einer abgelaufenen Sperrfrist fehl. Das unterstützte Muster ist ein Repository pro Client. Das bedeutet auch, dass die Deduplizierung nur innerhalb des Repositorys eines Rechners erfolgt. Zehn nahezu identische Server speichern dadurch zehn Kopien desselben Basissystems.

Restic ermöglicht 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, werden gegenseitig dedupliziert. Der zweite Server speichert dadurch oft nur sehr wenige zusätzliche Daten. Der Nachteil ist die größere Auswirkung eines Verlusts: Ein Passwort und ein Repository enthalten alles. Geht das Passwort verloren, sind alle zehn Sicherungen verloren.

Aufbewahrung: forget plus prune gegenüber prune plus compact

Beide Tools trennen die Entscheidung, was behalten wird, von der Freigabe 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 Falle ist bei beiden Tools 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 freigegeben, wenn borg compact ausgeführt wird. Ein Cron-Job, der nur prune ausführt und niemals compact, lässt das Repository daher unbegrenzt wachsen, während die Archivliste kurz bleibt. In restic entfernt forget ohne --prune lediglich Snapshot-Referenzen. Die Daten bleiben erhalten, bis prune ausgeführt wird.

Führen Sie nach dem Aufräumen restic check aus. Der Befehl überprüft die Repository-Strukturen und meldet, ob etwas beschädigt ist. Das ist wesentlich besser, als eine Beschädigung erst bei einer Wiederherstellung festzustellen.

Wiederherstellung als einziger wirklich aussagekräftiger Test

Beide Werkzeuge mounten einen Snapshot, 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 den führenden Schrägstrich gespeichert. Daher ist etc/nginx korrekt. /etc/nginx findet nichts und extrahiert nichts. Es gibt dabei keine Fehlermeldung, 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 aktive Dateien mit älteren Versionen.

Unabhängig vom gewählten Werkzeug ist der Zeitplan nur die halbe Aufgabe. Führen Sie regelmäßig eine Wiederherstellung in ein temporäres Verzeichnis durch und überwachen Sie diesen Vorgang tatsächlich. Die ausführliche Anleitung in dem restic-Leitfaden zur Sicherung eines VPS macht dies ebenfalls mit einem 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 einsetzen möchten, wenn mehrere Rechner untereinander 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 operativen Gesichtspunkten schwer zu übertreffen.

Wählen Sie Borg, wenn das Ziel ein von Ihnen kontrollierter Linux-Rechner ist, wenn die Verbindung eine hohe Latenz hat und der Datenbestand aus Millionen kleiner Dateien besteht, wenn Sie den append-only-SSH-Schlüssel als Schutz gegen Ransomware einsetzen möchten oder wenn Sie die Komprimierung pro Auftrag abstimmen wollen. Borg ist das ältere Werkzeug. Seine stabile Serie entwickelt sich langsam weiter. Bei Backup-Software ist das ein Vorteil.

Beide Lösungen sind richtig. Falsch ist die Lösung, die Sie nie testen. Wenn Sie bereits Dumps auf Anwendungsebene erstellen, behalten Sie diese bei: Das Muster aus dem Nextcloud-Setup mit Docker und Datenbank-Dumps gilt für beide Werkzeuge, weil eine zu einem beliebigen Zeitpunkt kopierte Datei einer laufenden Datenbank kein Datenbank-Backup ist.

FAQ

Ist restic oder BorgBackup schneller?

Auf einer lokalen Festplatte oder in einem schnellen LAN sind beide ähnlich schnell. Bei beiden wird die Geschwindigkeit letztlich durch die Lese- und Hash-Geschwindigkeit der Quelle begrenzt. Borg ist bei einer SSH-Verbindung mit hoher Latenz und sehr vielen kleinen Dateien meist schneller, weil ein borg serve-Prozess auf der Gegenstelle Indexabfragen beantwortet, ohne für jeden Chunk einen Netzwerk-Roundtrip zu benötigen. Restic ist meist schneller, wenn das Ziel ein Objektspeicher ist, den Borg überhaupt nicht direkt unterstützt.

Kann BorgBackup Backups in S3 oder Backblaze B2 speichern?

Nicht direkt. Ein Borg-Repository wird vom borg serve-Prozess über SSH bereitgestellt. In einem Bucket läuft kein solcher Prozess. Als Workaround mounten manche Benutzer den Objektspeicher mit rclone als Dateisystem. Das Borg-Projekt empfiehlt dieses Vorgehen jedoch nicht, weil ein Mount, der während einer Transaktion abbricht, das Repository beschädigen kann. Wenn Sie einen Objektspeicher benötigen, verwenden Sie restic.

Kann ich beide Tools für dieselben Daten verwenden?

Ja, das tun manche Benutzer: Borg auf einem zweiten Server für eine schnelle lokale Wiederherstellung und restic im Objektspeicher für die Kopie an einem anderen Standort. Die Tools teilen nichts miteinander. Daher fallen die Kosten für das Lesen und Hashing zweimal an, und Sie müssen zwei Passwörter sicher speichern. Tun Sie dies nur, wenn Sie beide Wiederherstellungen getestet haben.

Was passiert, wenn ich das Repository-Passwort verliere?

Die Daten sind bei beiden Tools nicht wiederherstellbar. Restic leitet seinen Schlüssel mit scrypt aus dem Passwort ab. Es gibt keine Umgehungsmöglichkeit. Borg im repokey-Modus speichert den verschlüsselten Schlüssel im Repository. Daher reicht die Passphrase für die Wiederherstellung aus. 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 nicht auf dem gesicherten Server betrieben wird. Exportieren Sie den Borg-Schlüssel mit borg key export, wenn Sie keyfile verwenden.

Sollte ich auf Borg 2.0 warten?

Nein. Im Juli 2026 ist Borg 2.0 mit Version 2.0.0b22 noch eine Beta-Version. Das Projekt kennzeichnet diese Version ausschließlich als Testversion. Die stabile Serie ist 1.4, derzeit in Version 1.4.5. Beginnen Sie jetzt mit 1.4. Borg 2 ändert das Repository-Format und stellt einen dokumentierten Upgrade-Pfad bereit. Ein heutiger Start führt daher nicht in eine Sackgasse.