Werkzeug für automatisierte Datensicherung BorgBackup: Open-Source-Backup mit Deduplizierung

Anbieter zum Thema

FTAPI Software GmbH

BorgBackup kombiniert blockbasierte Deduplizierung mit lokaler Verschlüsselung und ist in heterogenen Systemlandschaften eine technisch saubere Lösung. Der Artikel gibt einen Überblick über typische Einsatzszenarien, Abläufe und sinnvolle Konfigurationen.

BorgBackup ist ein quelloffenes Backup-Werkzeug, das sich auf Dateisystem-Ebene einsetzen lässt und dabei effizient mit Ressourcen umgeht. Die Software ist geeignet für lokale Sicherungen ebenso wie für Backups über Netzwerkverbindungen. Das Tool setzt auf deduplizierte, verschlüsselte und komprimierte Archive. Dadurch sinkt die Menge an zu übertragenden und zu speichernden Daten. Diese Eigenschaften machen Borg auch für Szenarien interessant, in denen Netzwerkanbindungen limitiert sind oder Speicherplatz effizient genutzt werden muss.

Deduplizierung und Verschlüsselung als Fundament

Die Arbeitsweise von Borg unterscheidet sich von herkömmlichen Backup-Tools. Anstatt komplette Dateien zu kopieren, analysiert Borg den Datenbestand blockweise. Diese Blöcke, sogenannte Chunks, werden anhand ihres Inhalts gehasht. Wiederkehrende Inhalte erkennt Borg dadurch automatisch und speichert sie nur einmal.

Bei regelmäßigem Einsatz wächst das Repository kaum noch an, wenn sich nur wenige Dateien ändern. Die integrierte AES-Verschlüsselung schützt sowohl Inhalte als auch Metadaten vor Zugriff durch Dritte. Die Verschlüsselung findet bereits lokal auf dem Quellrechner statt. Das Zielsystem muss nicht vertrauenswürdig sein, selbst bei der Übertragung über öffentliche Netzwerke.

Security-Insider Podcast – Folge 98

Wo Daten lagern, lauern Risiken!

Backups auf lokalen Systemen effizient gestalten

Ein verbreitetes Szenario ist die Absicherung eines Servers unter Linux. Dafür wird zunächst ein Repository angelegt. Dies erfolgt mit dem Befehl:

Dabei entsteht ein gesichertes Verzeichnis, in dem alle folgenden Sicherungen abgelegt werden. Die Option „--encryption=repokey“ legt fest, dass sowohl der Schlüssel als auch der Zugriffsschutz im Repository selbst gespeichert werden. Für automatisierte Abläufe wird das Passwort in einer Umgebungsvariable definiert:

Ein Beispiel für ein tägliches Backup könnte so aussehen:

Dieser Befehl erstellt eine neue Sicherung mit Zeitstempel, komprimiert die Daten mit dem zstd-Algorithmus auf Stufe 5 und speichert sie im angegebenen Repository. Das Backup ist dabei vollständig, arbeitet aber inkrementell.

Backup über SSH auf einen externen Server übertragen

Für entfernte Sicherungsziele wird Borg typischerweise über SSH genutzt. Dazu initialisiert man ein Repository auf dem entfernten System:

Ein laufendes Backup erfolgt anschließend mit:

Die Daten werden während der Übertragung verschlüsselt und auf dem Zielsystem abgelegt. Für eine sichere Automatisierung wird ein SSH-Schlüsselpaar eingerichtet, das eine passwortlose Verbindung erlaubt. Die Übergabe der Passphrase erfolgt ebenfalls per Umgebungsvariable oder mittels „BORG_PASSCOMMAND“, falls ein Passwortmanager verwendet wird.

Security-Insider Podcast – Folge 71

So machen Sie beim Backup keine Fehler!

Nextcloud mit BorgBackup sichern

Eine typische Anwendung ist die Sicherung einer selbstgehosteten Nextcloud-Umgebung. Hierzu gehören nicht nur der Webserver-Code, sondern auch das Benutzer-Datenverzeichnis und die zugehörige Datenbank. Vor der Sicherung wird ein Dump der Datenbank erstellt:

Anschließend sichert Borg alle relevanten Verzeichnisse:

Die Rücksicherung erfolgt wahlweise über Mount oder direkten Restore. Um das Backup zu durchsuchen, wird es gemountet:

In „/mnt/restore“ lassen sich dann gezielt Dateien oder Konfigurationsdaten einsehen und kopieren. Alternativ wird gezielt extrahiert:

Speicherbedarf kontrollieren durch gezielte Aufbewahrung

Backups erzeugen mit der Zeit große Datenmengen. Borg bietet mit dem Parameter „prune“ eine Lösung, alte Sicherungen anhand fester Regeln zu löschen. Ein Beispiel:

Dieser Befehl sorgt dafür, dass nur die letzten sieben Tages-, vier Wochen- und sechs Monatssicherungen erhalten bleiben. Um danach nicht mehr referenzierte Blöcke endgültig zu löschen, wird „borg compact“ ausgeführt:

Beide Befehle lassen sich in einem Skript automatisieren und regelmäßig per Cron ausführen, etwa jeden Morgen um 3 Uhr.

Video-Tipp #59: Nextcloud Security Essentials

Mehr Sicherheit für die eigene Nextcloud

Zugriff über Netzwerkdateisysteme vermeiden

Ein häufiger Fehler besteht darin, entfernte Speicher über SSHFS oder NFS einzubinden und darüber Backups mit Borg auszuführen. In diesem Fall steht kein Borg-Agent auf dem Zielsystem zur Verfügung. Alle Operationen erfolgen ausschließlich clientseitig, was sich deutlich negativ auf die Geschwindigkeit auswirkt. Effektiver ist es, Borg auf beiden Seiten zu installieren und per SSH im nativen Client-Server-Modus zu arbeiten. Dann sind die vollständige Deduplizierung und serverseitige Verarbeitung möglich.

Flexible Kompression für verschiedene Umgebungen

Borg bietet verschiedene Kompressionsmodi für unterschiedliche Anforderungen. Die Standardeinstellung „lz4“ ist besonders schnell und eignet sich für Systeme mit schwacher CPU. Wer mehr Platz sparen will, verwendet „zstd“ mit einstellbarer Stufe:

Noch flexibler ist der automatische Modus, der Daten nur dann komprimiert, wenn sie sich dafür eignen:

Dadurch lassen sich Backup-Zeiten reduzieren, ohne bei ungeeigneten Inhalten unnötig Rechenzeit zu verschwenden.

Backup-Tests effizient gestalten

Ein nicht getestetes Backup ist schlimmer als gar kein Backup!

Integritätsprüfung und Fehlerbehandlung im Repository

Ein oft unterschätzter Bestandteil jeder Backup-Strategie ist die regelmäßige Überprüfung auf Datenintegrität. BorgBackup bietet hierfür mit dem Befehl „borg check“ ein Werkzeug, das Archive und Repositorys gezielt auf Fehler prüft. Dabei wird die Konsistenz der gespeicherten Datenblöcke anhand von Prüfsummen und Metadaten verifiziert. In produktiven Umgebungen empfiehlt es sich, diese Prüfung regelmäßig automatisiert durchzuführen, um schleichende Dateisystemfehler oder Bitrot frühzeitig zu erkennen. Falls Inkonsistenzen auftreten, kann mit „borg check –repair“ versucht werden, defekte Segmente zu isolieren und beschädigte Archive wiederherzustellen.

Ergänzend lassen sich Logs der Prüfungen erfassen, um bei Bedarf gezielt in den betroffenen Zeitrahmen zurückzuspringen. So trägt die Integritätsprüfung entscheidend zur Verlässlichkeit und Langzeitstabilität des Sicherungskonzepts bei, besonders bei Repositorys, die über Jahre hinweg Daten archivieren. Ein grundlegender Check des gesamten Repositorys inklusive Metadaten lässt sich so ausführen:

Dieser Befehl veranlasst Borg, alle Archive im angegebenen Repository zu überprüfen. Dabei vergleicht es gespeicherte Metadaten mit dem tatsächlichen Zustand der Datenblöcke. Ziel ist es, Inkonsistenzen wie fehlende oder beschädigte Chunks zu identifizieren. Für eine genauere Kontrolle über alle archivierten Dateien kann der Befehl erweitert werden:

Mit der Option „--verify-data“ geht Borg über die reine Strukturprüfung hinaus und validiert die gespeicherten Inhalte gegen ihre Prüfsummen. Diese Variante ist deutlich langsamer, eignet sich aber für regelmäßige Tiefenkontrollen, etwa bei langfristig genutzten Backups oder vermutetem Festplattendefekt. Wenn ein Check Probleme meldet, besteht die Möglichkeit zur gezielten Reparatur:

Der Parameter „—repair“ versucht, erkannte Probleme automatisch zu beheben. Defekte Archive oder Chunks werden markiert, um weitere Nutzung zu vermeiden. Nicht alle Fehler lassen sich vollständig korrigieren, daher sollte dieser Schritt nur auf einer Kopie des Repositorys durchgeführt werden, wenn kein aktuelles vollständiges Backup vorliegt. In großen Repositorys kann ein vollständiger Daten-Check zeitintensiv sein. Wenn nur geprüft werden soll, ob die Archive formal korrekt sind, reicht:

Die Option „--archives-only“ beschränkt sich auf die Archivstruktur und überspringt tiefergehende Chunk-Prüfungen. Das ist sinnvoll, wenn die Datenquelle bereits regelmäßig verifiziert wird oder wenn kurzfristig keine Zeit für umfassende Prüfungen vorhanden ist.

Wie ging das nochmal mit der Datensicherung?

Backup-Strategien für Security-Spezialisten

Backup-Wiederherstellung automatisieren und testen

Wer BorgBackup produktiv einsetzt, sollte nicht nur die Erstellung, sondern auch die Wiederherstellung regelmäßig testen und automatisieren. Eine einfache Methode zur regelmäßigen Prüfung von Restores besteht darin, ein Archiv auf ein temporäres Verzeichnis einzuhängen und gezielt Dateien zu überprüfen. Zunächst wird das gewünschte Backup eingebunden:

Borg stellt dabei das Archiv mit dem Namen „server-2025-05-01“ im Verzeichnis „/mnt/testrestore“ bereit. Die Daten erscheinen dort lesbar, aber nicht schreibbar, das Repository bleibt geschützt. In einem Cronjob lässt sich das kombinieren mit einem Vergleichsbefehl:

Diese Zeile prüft, ob sich die gesicherte Datei vom aktuellen Zustand unterscheidet. Wer ganze Verzeichnisse prüfen möchte, kann „rsync“ im Dry-Run-Modus verwenden:

Die Optionen „-nrc“ bedeuten: kein Kopieren (nur Testen), rekursiv, und prüfe per Checksumme. Damit lassen sich unerwartete Unterschiede erkennen. Nach Abschluss sollte das gemountete Archiv wieder ausgehängt werden:

Solche Tests lassen sich täglich oder wöchentlich automatisieren, um die Integrität nicht nur des Repositorys, sondern auch der Restore-Fähigkeit nachzuweisen.

(ID:50479765)