Backup & Restore
BorgBackup
BorgBackup (Borg) ist ein quelloffenes CLI-Backup mit starker Deduplizierung, authentifizierter Verschlüsselung und Append-only-Modus als Ransomware-Schutz.
- Dedup über Content-Defined Chunking
- Authentifizierte Verschlüsselung
- Repository und Archive
- Append-only gegen Ransomware
- Open Source (BSD)
BorgBackup (kurz Borg) ist ein quelloffenes Kommandozeilen-Backup-Programm, das 2015 als Fork von Attic entstand. Es kombiniert eine starke, repository-weite Deduplizierung mit authentifizierter Verschlüsselung und einem Append-only-Modus, der gespeicherte Backups vor nachträglichem Löschen schützt. Borg ist schlank, effizient und auf SSH-basierte Szenarien zugeschnitten.
Dieser Artikel erklärt das Content-Defined Chunking, die Verschlüsselungsmodi (mit dem Unterschied zwischen 1.4 und der 2.0-Beta), die Begriffe Repository und Archive, den Append-only-Schutz, die Kernbefehle inklusive der wichtigen Trennung von prune und compact, das Locking-Verhalten sowie das Ökosystem an Wrappern. Eine sachliche Abgrenzung zu Restic gehört dazu.
1. Deduplizierung über Content-Defined Chunking
Borg zerlegt Dateien mit einem Buzhash-basierten Rolling-Hash in inhaltsabhängige Chunks (Content-Defined Chunking). Die Chunk-Grenzen richten sich nach dem Inhalt, nicht nach festen Offsets: Wird mitten in einer Datei etwas eingefügt, verschiebt sich nur der betroffene Bereich, nicht alle nachfolgenden Chunks. Jeder Chunk wird über einen kryptografischen Schlüssel identifiziert und nur einmal gespeichert, repository-weit, also auch über verschiedene Backup-Läufe und (bei gemeinsamem Repo) Maschinen hinweg. Komprimiert wird wahlweise mit lz4, zstd, zlib oder lzma.
2. Verschlüsselung (1.4 vs. 2.0)
Borg verschlüsselt clientseitig und authentifiziert. In der stabilen Serie 1.4 kommt AES-256 im CTR-Modus mit HMAC-SHA-256 oder BLAKE2b zum Einsatz; die Chunk-ID wird kryptografisch aus dem Inhalt abgeleitet, sodass keine fremden Chunks eingeschleust werden können. Der Schlüssel liegt je nach Modus im Repository (repokey) oder in einer lokalen Keyfile (keyfile). Die kommende Borg 2.0 (noch Beta) wechselt auf moderne AEAD-Verfahren (AES-256-OCB bzw. ChaCha20-Poly1305) und auf Argon2 zur Schlüsselableitung; bestehende Repositories sind nicht kompatibel und werden per borg transfer migriert.
Borg 2.0 ist noch Beta
Zum aktuellen Stand ist die 1.4er-Serie die stabile Wahl; Borg 2.0 befindet sich in der Beta und bringt geänderte Verschlüsselung und Befehlssyntax (etwa borg repo-create statt borg init). 1.x-Skripte laufen ohne Anpassung nicht auf 2.0. Für Produktivbetrieb gehört der Versionsstand bewusst gewählt.
3. Repository, Archive und Append-only
Ein Repository ist der Speicherort (lokal oder per SSH erreichbar), ein Archive ein benannter Snapshot darin; mehrere Archive teilen sich dieselben Chunks (Grundlage der Deduplizierung). Der Append-only-Modus ist Borgs Ransomware-Schutz: Daten werden nur angehängt, prune/delete markieren nur, geben aber nichts frei. Robust umgesetzt wird das über einen SSH-Forced-Command auf dem Backup-Server (borg serve --append-only), sodass ein kompromittierter Client alte Archive nicht löschen kann.
Borg: Repo anlegen, Backup, aufräumen
borg init --encryption=repokey-blake2 user@host:/backup/repo
borg create user@host:/backup/repo::'{hostname}-{now}' /etc /home /var
borg prune -d 7 -w 4 -m 6 user@host:/backup/repo
borg compact user@host:/backup/repo4. Prune, compact, check und Locking
Borg trennt bewusst zwei Schritte: prune markiert Archive nach Retention-Regeln (keep-daily/weekly/monthly u. a.) als gelöscht, gibt aber keinen Platz frei; erst compact gibt den Speicher tatsächlich frei. Diese Trennung macht prune im Append-only-Betrieb sicher. borg check prüft Repository- und Archiv-Integrität (mit --verify-data auch die Chunk-Inhalte). Wichtig: Borg setzt einen exklusiven Lock, ein Repository darf nicht von mehreren Maschinen gleichzeitig beschrieben werden.
5. Ökosystem und Einordnung
Borg bringt selbst keinen Scheduler und keine GUI mit. Für den Betrieb dienen Wrapper: Borgmatic (YAML-Konfiguration plus systemd/cron, Hooks für Datenbank-Dumps), Vorta (Desktop-GUI) oder Hosted-Dienste wie BorgBase; ein SSH-/SFTP-Ziel wie eine Storage Box ist eine verbreitete Kombination. Gegenüber Restic ist Borg SSH-zentriert und gilt bei der Deduplizierung tendenziell als sehr effizient, hat aber keine nativen Cloud-Backends; Restic punktet dort mit S3 und Co. und erlaubt mehrere Clients pro Repository.
6. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Sehr effiziente, repository-weite Deduplizierung | CLI-only, kein Scheduler/GUI im Kern |
| Clientseitige, authentifizierte Verschlüsselung | Exklusiver Lock: kein paralleler Mehrclient-Zugriff |
| Append-only-Modus (SSH-Forced-Command) gegen Ransomware | Nativ nur lokal und SSH; Cloud nur über Umwege |
| FUSE-Mount für selektive Wiederherstellung | Borg 2.0 noch Beta, Repos nicht kompatibel |
| BSD-Lizenz, schlank, gut dokumentiert | prune und compact sowie check müssen eingeplant werden |
Häufige Fragen zu BorgBackup
prune markiert Archive nach den Retention-Regeln als gelöscht, gibt aber keinen Speicher frei; erst compact gibt den Platz tatsächlich frei. Die Trennung erlaubt es, prune auch im Append-only-Modus sicher auszuführen, ohne dass Daten sofort unwiederbringlich verschwinden.
Beide deduplizieren und verschlüsseln clientseitig per CLI. Borg ist SSH-zentriert und bei der Deduplizierung tendenziell sehr effizient, erlaubt aber keinen parallelen Mehrclient-Zugriff und hat keine nativen Cloud-Backends. Restic bietet breite native Cloud-Backends (S3, Azure, GCS) und Multi-Client-Betrieb. Die Wahl hängt vom Speicherziel ab.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
BorgBackup im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.