Restic oder BorgBackup: Welches Backup passt?

Restic und BorgBackup in einem Absatz

Restic und BorgBackup erledigen dieselbe Kernaufgabe: deduplizierte, verschlüsselte und inkrementelle Backups eines Linux-Servers. Für die Auswahl ist entscheidend, wo das Backup gespeichert 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. Bei 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 verwalten, kommt Borg infrage und ist häufig schneller.

Alle anderen Unterschiede sind weniger bedeutend. Beide teilen Dateien anhand ihres Inhalts in Chunks auf. Wenn sich in einem Verzeichnis mit 40 GB Daten im Umfang von 200 MB ändern, werden ungefähr 200 MB hochgeladen. Beide verschlüsseln die Daten auf dem Client. Beide können einen Snapshot mit FUSE (filesystem in userspace) einhängen, sodass Sie einzelne Dateien herauskopieren können. Im Juli 2026 ist Restic in Version 0.19.1 verfügbar. Die stabile Borg-Serie 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 zahlreiche Pack-Dateien enthalten. 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. Auf diese Weise unterstützt eine einzige Binärdatei lokale Pfade, SFTP, den eigenen REST-Server, S3, Backblaze B2, Azure, Google Cloud Storage und alles, was rclone erreichen kann.

Auch ein Borg-Repository besteht 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 Gegenseite borg serve und verwendet für diesen Prozess sein eigenes Protokoll. Die Serverseite übernimmt dabei echte Aufgaben: Sie enthält das Repository, wendet die Transaktion an und beantwortet Abfragen zu den Indizes. Deshalb besitzt Borg kein S3-Backend und hat auch keines hinzugefügt. Innerhalb eines Buckets kann kein Prozess ausgeführt werden.

Diese einzelne Designentscheidung verursacht die meisten praktischen Unterschiede im folgenden Abschnitt.

# 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.

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

Borg komprimiert seit Beginn. Der Standard ist lz4, weil diese Einstellung schnell genug ist, um sie für alles aktiviert zu lassen. zstd akzeptiert die Stufen 1 bis 22 und verwendet standardmäßig 3. zlib und lzma sind für Fälle vorgesehen, in denen die Anzahl der Bytes wichtiger ist als die benötigte Zeit. auto verwendet eine Heuristik für jeden Chunk. Dadurch werden bereits komprimierte Daten nicht nochmals komprimiert.

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. Bei einem neuen Repository ist Format 2 inzwischen die Standardeinstellung. 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 0.14 ist und Sie es nie migriert haben, belegen Textdateien, Logs und Datenbank-Dumps weiterhin ihre volle Größe.

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

Ist restic oder BorgBackup schneller?

Auf einer lokalen Festplatte oder in einem schnellen LAN liegen beide Programme nah beieinander. Bei beiden wird die Geschwindigkeit letztlich durch die Lese- und Hashrate der Quelle begrenzt. Borg ist über eine SSH-Verbindung mit hoher Latenz und sehr vielen kleinen Dateien meist schneller, weil ein borg serve-Prozess auf der Gegenstelle Indexabfragen beantwortet, ohne pro Chunk einen Netzwerk-Roundtrip zu benötigen. Restic ist meist schneller, wenn das Ziel ein Object Storage ist, den Borg überhaupt nicht direkt verwenden kann.

Kann BorgBackup Sicherungen auf S3 oder Backblaze B2 erstellen?

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

Kann ich beide Programme für dieselben Daten verwenden?

Ja, einige Benutzer tun das: Borg auf einem zweiten Server für eine schnelle lokale Wiederherstellung und restic im Object Storage für die Offsite-Kopie. Die Programme verwenden nichts gemeinsam. Daher fallen die Kosten für das Lesen und Hashing doppelt an, und Sie müssen zwei Passwörter sicher speichern. Verwenden Sie diese Kombination nur, wenn Sie beide Wiederherstellungen getestet haben.

Was passiert, wenn ich das Repository-Passwort verliere?

Die Daten sind bei beiden Programmen 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 genügt die Passphrase für die Wiederherstellung. Im keyfile-Modus benötigen Sie zusätzlich die Schlüsseldatei aus ~/.config/borg/keys/. Bewahren Sie das Passwort in einem Passwortmanager auf, der nicht auf dem zu sichernden 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 weiterhin 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 bietet einen dokumentierten Upgrade-Pfad. Ein heutiger Start führt daher nicht in eine Sackgasse.