Sichere Sicherungen mit Borg anlegen & automatisieren

Sichere Sicherungen mit Borg anlegen & automatisieren

Software DMW007

Backups schützen die eigenen Daten gegen eine Vielzahl an Gefahren und verhindern damit Beschädigung oder Verlust. Borg ist eine freie & quelloffene Software, um Dateien effizient zu sichern – ob auf dem Raspberry Pi, (Heim-) Server oder anderen PCs. Dieser Beitrag zeigt, wie das Programm funktioniert und wie ihr damit Sicherungen einrichtet.

Warum Borg?

Nicht zwingend wird eine eigene Software zum Anlegen von Sicherungen benötigt. Ein einfaches Backup lässt sich beispielsweise mit dem GNU-Werkzeug rsync durchführen. Oder Erstellen von Archiven (z.B. ZIP). Per Skript kann dies zwar recht gut automatisiert werden und für sehr kleine Umgebungen ist das ggf. ausreichend. Doch diese Methode stößt schnell an ihre Grenzen (z.B. Speicherverbrauch). Zudem müssen wir uns um relativ viele Dinge selbst kümmern, etwa das Bereinigen alter Sicherungen.

Geht man anders an die Sache heran und überlegt sich, welche Kriterien an eine optimale Sicherungssoftware gestellt werden, dürfte folgendes Ergebnis entstehen. Vorneweg: Borg erfüllt all diese Kriterien.

  • Clientseitiges Verschlüsseln zum Schutz der Daten – insbesondere bei Nutzung von öffentlichen Clouddiensten Pflicht!
  • Sicherstellung der Datenintegrität
  • Komprimierung, Deduplizierung & inkrementelle Sicherungen zum Speicherplatz sparen
  • Regelmäßiges Aufräumen alter Sicherungen
  • Freie & quelloffene Software, damit z.B. die Sicherheit der Verschlüsselung prüfbar ist
  • Automatisierung möglich

Wo liegen die Sicherungen?

Für diese Entscheidung sollte zunächst überlegt werden, vor welchen konkreten Gefahren man sich schützen möchte bzw. muss. Viele denken zunächst an Hardwareausfälle, was durchaus berechtigt ist. Doch es gibt noch weitere Gefahren, wie etwa:

  • Versehentliches Löschen oder zerstören von Dateien (z.B. durch Software- oder Bedienfehler)
  • Physische Schäden (z.B. Feuer, Rohrbruch) und Naturkatastrophen
  • Entwendung/Zerstörung durch Dritte (etwa Laptop-Diebstahl oder Infektion mit Schadsoftware wie Ransomware)
  • Zugriffsverlust aus anderen Gründen: Dienstleister wird gehackt/geht pleite/sperrt das Konto usw.

Die 3-2-1 Regel ist eine bewährte Strategie, um möglichst vielen Risiken vorzubeugen. Dabei werden drei Sicherungen auf zwei Medien angelegt, eine Kopie liegt Extern. Mindestens zwei Sicherungen an getrennten Orten sollten von wichtigen Daten vorliegen. Als wichtig klassifiziere ich nicht bloß Unternehmensdaten, die kritisch für das Geschäft sind. Private Erinnerungen sind individuell sicher in der Regel ebenfalls wertvoll – auch wenn sich der Wert kaum in Euro beziffern lässt. Andererseits können z.B. Bilder von Familie oder Freunden bei Verlust mit Geld oft nicht wiederhergestellt werden. Es lohnt sich daher auch privat, die eigenen Daten zu sichern.

Was man sonst noch bedenken sollte

Der Einsatz von Verschlüsselung ist zum Schutz der Daten super. Unüberlegt eingesetzt kann man sich damit allerdings selbst aussperren. Es ist daher wichtig, den Ablauf einer Wiederherstellung gedanklich durchzuspielen – ausgehend vom schlimmsten Szenario. Ein Klassiker: Für die Sicherung wurde ein sicheres Kennwort verwendet und daher im Passwortsafe abgelegt. Der liegt allerdings in der verschlüsselten Sicherung – somit kommt man nicht mehr an die Daten heran.

In diesem Falle müsste man entweder den Passwortsafe ohne zusätzliche Verschlüsselung übertragen. Das ist ohne Sicherheitsverlust möglich, weil dieser bereits verschlüsselt ist. Oder alternativ ein Kennwort nutzen, auf das man in jedem Falle Zugriff hat: Beispielsweise ist es an einem sicheren Ort verwahrt oder man kennt es auswendig. Wobei beim auswendig lernen die Gefahr des Vergessens droht, wenn es längere Zeit nicht eingegeben werden muss.

Dies sind nur Beispiele. Es variiert je nach Umgebung und Umständen. Gerade deswegen ist wichtig, sich vorab Gedanken darüber zu machen.

Wie ist Borg aufgebaut?

Ein Repository dient als Container im Zielspeicher, um die Sicherungen in der gewünschten Konfiguration (Verschlüsselt, Komprimiert, Dedupliziert) zu bündeln. Als Archiv bezeichnet Borg eine einzelne Sicherung der übergebenen Verzeichnisse. Im Repository können mehrere Archive angelegt werden. Und zwar recht frei, wenn man es mit anderer Sicherungssoftware wie Duplicati vergleicht. Vorgegeben ist nur, dass der Archivname innerhalb eines Repository eindeutig sein muss.

Damit es nicht zu Chaos kommt, empfiehlt sich die Verwendung eines Namensschemas. Lässt man die Sicherungen über ein kleines Shell-Skript anlegen, bleibt diese gewahrt. Schon alleine deswegen macht das Sinn. Spätestens wenn mehrere Archive (= Sicherungen) pro Durchlauf angelegt werden sollen, wird das Skript zur Pflicht. Sonst ist die Handhabung umständlich und es passiert leicht, dass etwas vergessen wird.

Installation und Vorbereitung

Die verfügbaren Versionen finden sich auf der Webseite.1 Manche sind experimentell und sollten nicht produktiv verwendet werden. Zum Erstellungszeitpunkt des Beitrages war Borg 1.4 die aktuellste stabile Version, während sich 2.0 in der Testphase befindet. Es empfiehlt sich, die jeweils aktuelle stabile zu nutzen. Die Binärdateien finden sich auf der GitHub Release-Seite.2

wget https://github.com/borgbackup/borg/releases/download/1.4.0/borg-linux-glibc228
chmod +x borg-linux-glibc228
sudo mv borg-linux-glibc228 /usr/local/bin/borg

$ borg --version
borg 1.4.0

Es sollte sichergestellt werden, dass genügend freier Speicherplatz (mindestens die Größe der zu sichernden Daten) im Ziel vorhanden ist. Auch in ~/.cache werden mehrere Gigabyte benötigt. Borg benötigt freien Speicherplatz, um Dateien zu löschen. Auf voll gelaufenen Laufwerken kann daher nicht durch das Entfernen älterer Sicherungen Platz geschaffen werden!

Vorbereitung: Anlegen eines Repositories für Sicherungen

Zu Beginn muss ein Repository im Zielpfad (z.B. eine externe Festplatte) angelegt werden. Borg unterstützt auch entfernte Repositories über SSH. Einmalig lässt sich festlegen, ob und wie die späteren Sicherungen verschlüsselt werden. Dies lässt sich nicht nachträglich verändern! Nur über das Anlegen eines neuen Repositories, womit jedoch alle bisherigen Versionen verloren gehen. Ich halte es daher für wichtig, sich an dieser Stelle einen Überblick über die verschiedenen Methoden zu verschaffen und gezielt eine zu wählen.3

Borg empfiehlt Verschlüsselung, um die Sicherungen gegen unbefugten Zugriff (Cloudanbieter, Kompromittierung, Einbruch usw) zu schützen. Aber auch zur Sicherung der Integrität. Ansonsten könnten Angreifer mit Zugang beispielsweise Dateien manipulieren. Sicherheitstechnisch ist das zu empfehlen. Man sollte jedoch insbesondere hier darauf achten, das Rücksichern zu testen. Verschlüsselung und Kompression sind potenzielle zusätzliche Fehlerquellen. Wer darauf verzichtet, kann sie mit --encryption none komplett abschalten.

Im Falle verschlüsselter Sicherungen würde ich repokey verwenden: Intern legt das mehrere (private) Schlüssel an, die mit dem von euch eingegebenen Passwort (passphrase) geschützt werden. Wie der Name erahnen lässt, speichert Borg die Schlüssel im Repository – sie sind somit automatisch in eurer Sicherung enthalten. Ein gesonderter Export mit borg key export wird dennoch empfohlen, da zum Rückspielen sowohl der Schlüssel im Dateisystem, als auch euer Passwort notwendig ist. Das Risiko, sich selbst auszusperren, ist hier geringer. Bei keyfile liegt der Schlüssel dagegen in eurem Heimverzeichnis (~/.config/borg/keys). Hier kann es leicht passieren, dass dieser vergessen wird, außerhalb zu sichern. Eine Wiederherstellung wäre dann nicht möglich, weil der Schlüssel dafür benötigt wird. Um an den Schlüssel zu kommen, müsste jedoch die Sicherung entschlüsselt werden…

borg init --make-parent-dirs --encryption repokey /mnt/backup-8tb/borg_nas

Wie viele Repositories/Archive anlegen?

Das wichtigste ist, zusammenhängende Dateien im gleichen Repository zu sichern. Auf dessen Ebene findet nämlich die Deduplizierung statt. Möchte man z.B. einen Heimserver oder ein NAS sichern, reicht ein Repo in vielen Fällen aus. Eine explizite Trennung kann u.u. Sinn machen, etwa wenn man große Dateien hat und diese unterschiedlich kritisch sind. Eine große Filmsammlung möchte man evtl. weniger stark replizieren, als die privaten Dateien. Die gesicherten Dateien lassen sich nicht zerlegen – in diesem Falle wäre es sinnvoll, zwei Repos anzulegen.

Bei den Archiven dürften die Intervalle von Sicherungen das wichtigste Kriterium sein. Sollen bestimmte (wichtigere) Daten häufiger gesichert werden, als andere? Dann ist ein eigenes Archiv sinnvoll. Theoretisch kann das auch der Fall sein, wenn nur wenige Dateien häufiger gesichert werden sollen, als viele andere. Borg muss alle angegebenen Ordner rekursiv auf Änderungen gegenüber dem letzten Backup prüfen. In der Praxis ist das Programm dabei recht flott und es dürfte in den seltensten Fällen eine Rolle spielen, ob der Durchlauf etwas länger dauert. Das Bereinigen einzelner Dateien ist zwar auch im großen Archiv möglich – kann jedoch mit mehreren Archiven übersichtlicher werden, wenn man hier komplexere Ausnahmen machen möchte.

Was die Wiederherstellung angeht, lässt sich das gesamte Archiv einhängen und man kopiert nur benötigte Inhalte zurück. Ein einziges Archiv, aus dem man nur eine Datei holt, ist daher möglich. Sämtliche Daten wiederherzustellen ist mit mehreren Archiven ebenfalls möglich – allerdings mehr Arbeit. Tendenziell würde ich daher mit möglichst wenig Archiven starten.

Sichern von Dateien und Ordnern

Innerhalb eines Repositories können nun Ordner oder einzelne Dateien mit borg create in ein Archiv gesichert werden.4 Folgendes Beispiel sichert alle Heimverzeichnisse meines Servers in das zuvor erstellte Repository /mnt/backup-8tb/borg_nas als Archiv home-{zeitstempel}:

borg create --one-file-system  --dry-run --list --progress --stats --exclude '*/.cache' /mnt/backup-8tb/borg_nas::home-{now:%d.%m.%Y} /home

–one-file-system stellt sicher, dass keine innerhalb des Zielordners eingehängten Laufwerke gesichert sind. Beispielsweise externe Festplatten oder per SSHFS gemountete Server. Typischerweise legt man diese in /mnt. Zur Sicherheit finde ich die Option sinnvoll, bevor irgend etwas voll läuft, weil doch versehentlich eine andere Platte mit gesichert wird.

–dry-run führt lediglich eine Simulation durch. Zusammen mit –list zeigt es euch an, welche Dateien Borg sichern würde. Das hilft bei ersten Tests. Insbesondere um zu prüfen, ob Filter wie gewünscht funktionieren. Ist das der Fall, ersetze ich beide durch –stats.

–stats gibt nach Abschluss eine Zusammenfassung aus. Sie zeigt etwa, wie viele Dateien gesichert wurden, wie groß diese sind und wie hoch der tatsächliche Speicherplatzbedarf auf dem Zielmedium nach der Deduplizierung war.

–progress zeigt während der Sicherung den Fortschritt an.5 Vor allem anfangs nützlich, wenn man diese (testweise) von Hand ausführt.

–exclude schließt Dateien und Ordner aus, die dem übergebenen Muster entsprechen. In diesem Beispiel wird jeglicher .cache Ordner ignoriert. Typischerweise befindet er sich im Heimverzeichnis eines GNU/Linux-Benutzers und dient als temporärer Zwischenspeicher. Vor allem auf Desktop-Systemen kommen dort schnell einige Gigabyte zusammen, etwa durch Vorschaubilder im Datei-Explorer. Was hier liegt, ist flüchtig und kann aus den originalen Quellen/Dateien neu generiert werden. Beispielsweise werden beim Laden eines Ordners neue Thumbnails erzeugt, wenn sie hier nicht mehr vorhanden sind. Diesen Ordner zu sichern, macht daher wenig Sinn.

/mnt/backup-8tb/borg_nas::home-{now:%d.%m.%Y} ist das Sicherungsziel: Der Pfad stammt vom zuvor erstellten Repository, nach dem Doppelpunkt steht der Name des Archivs. Dieser muss einzigartig sein.

Wie viel Speicherplatz belegen die Sicherungen?

Bei jeglichen Statistiken unterscheidet Borg zwischen der originalen Größe (Original size) – das sind die originalen Dateien im Quellverzeichnis, wie sie das Programm zum Sicherungszeitpunkt vorgefunden hat. Beim Anlegen der Sicherungsarchive werden sie komprimiert (Compressed size) und es findet eine Deduplizierung statt: Liegt eine Kopie der gleichen Datei an mehreren Stellen, merkt sich Borg das und speichert die Datei nur einmal in der Sicherung. Wie viel durch Komprimieren gespart wird, hängt von der Art der Dateien ab. Text lässt sich z.B. stark verkleinern, bereits komprimierte Formate wie JPG-Bilder hingegen kaum.

Die Ausgabe mit --stats ist recht ausführlich, nicht alles erschließt sich jedoch auf Anhieb. Bei This archive seht ihr, dass in diesem Falle 1,24 TB im Quellordler liegen. Komprimiert reduziert sich das kaum auf 1,23 TB. Unter Deduplicated size sieht man den Speicherbedarf der jetzigen Sicherung – im Regelfall das, was nach einem Lauf am meisten interessiert. Beim ersten Durchlauf ist dieser Wert am Höchsten, weil eine Vollsicherung erfolgt. Danach sieht man hier nur noch das Delta, d.H. neue und veränderte Dateien seit der letzten Sicherung.

Direkt darunter findet sich in der gleichen Spalte der belegte Speicher von allen Archiven im Repository, hier 4,57 TB. Was verwirren kann: Die Originale Größe in der ersten Spalte rechnet nicht inkrementell! Die originale Größe aller Archive ist daher von 17.90 TB im vorherigen Archiv auf 19.14 TB gestiegen, weil die Originalgröße in diesem Archiv 1,24 TB beträgt. Tatsächlich blieben inkrementell mit Komprimierung & Deduplizierung aber eben nur die 1,72 GB übrig, welche wirklich auf dem Sicherungsmedium physisch liegen. All archives in der Original size Spalte wird somit schnell riesige Dimensionen annehmen, was jedoch eher ein theoretischer Wert ist, der die Sicherungsplatte nicht zum Überlaufen bringt.

Aufräumen

Beide Wege geben den belegten Speicher im Dateisystem nicht automatisch frei! Hierfür muss im Anschluss borg compact mit dem Repository-Pfad aufgerufen werden. Es wird empfohlen, dies regelmäßig zu tun.

borg compact /mnt/backup-8tb/borg_nas/

Automatisch nach bestimmten Mustern

Am sinnvollsten ist es, die Sicherungen nach einem bestimmten Zeitplan automatisch löschen zu lassen. Man sollte sich daher zunächst überlegen, wie weit zurück diese reichen sollen. Zum Wiederherstellen möglichst vieler Daten kann es nie genug Sicherungen geben. Allerdings kosten diese Speicherplatz – insbesondere wenn häufige Änderungen an größeren Inhalten vorgenommen werden. Borg nutzt inkrementelle Sicherungen, Komprimierung und Deduplizierung, um den Speicherbedarf so gering wie möglich zu halten. Anfangs kann man den Speicherbedarf auch erst mal beobachten, bis man sich für eine Löschstrategie entscheidet.

Wahlweise kann eine zeitliche Vorgabe für das gesamte Repository festgelegt werden. Oder mit --glob-archives ein Filter, um von wichtigere Daten mehr Sicherungen aufzuheben, als von anderen. Grundsätzlich ist es eine gute Idee, mehr aktuelle als ältere aufzubewahren. Wer alte Sicherungen komplett löscht, geht ein Risiko ein: Beispielsweise kann man eine Datei versehentlich zerstören, die aber nur selten benötigt wird. Fällt das erst einige Zeit später auf,

Folgendes Beispiel behält eine Sicherung pro Tag und Woche, 6 der letzten Monate (also jeden zweiten Monat) und 2 pro Jahr. Mit --list --dry-run führt es zunächst eine Trockenübung durch, die alle Archive auflistet, welche gelöscht werden würden. Entspricht das der Erwartung, ruft man es zur tatsächlichen Löschung ohne die beiden Parameter auf.

borg prune -v --list --dry-run --keep-daily=7 --keep-weekly=4 --keep-monthly=6 --keep-yearly=2  /mnt/backup-8tb/borg_nas/

Manuell

Mit -a kann ein glob angegeben werden, um Archive dieses Musters zu löschen. Sinnvoll ist, sich zunächst mit --list --dry-run simuliern zu lassen, auf welche Archive dies zutrifft. Insbesondere dann, wenn man Platzhalter (z.B. *-2024) nutzt.

borg delete -a 'nextcloud-daten_26.08.2024' --list --dry-run /mnt/backup-8tb/borg_nas/
Enter passphrase for key /mnt/backup-8tb/borg_nas: 
Would delete archive: nextcloud-daten_26.08.2024           Mon, 2024-08-26 12:33:45 [e6369857a90324be3e927cfa33a2d0bb11be07ae5f97831883956bd89d51bf95] (1/1)

Einzelne Sicherungen (Archive) lassen sich mit borg delete im gewohnten Format einzeln löschen:6

borg delete /mnt/backup-8tb/borg_nas::home-xxx

Tipps für Skripte

Borg besitzt ein paar nützliche Funktionen, um die Sicherungen in Skripten teilweise oder komplett zu automatisieren. Das dürfte fast immer Sinn machen: Schnell hat man mehrere Archive und/oder ein paar Ordner, die aus der Sicherung ausgeschlossen werden. Soll eine Bereinigung erfolgen, lassen sich prune & compact dort einbauen. Dank Skript wird nichts davon vergessen.

Wer das Passwort nicht bei jeder Sicherung eingeben oder den Prozess komplett automatisieren möchte, kann es in der Umgebungsvariable BORG_PASSPHRASE für alle Borg-Befehle setzen. Beim erzeugen mehrerer Archive im gleichen Repository ist BORG_REPO eine Hilfe, um diese Angabe beim Aufruf zu ersparen. Alternativ lassen sich Wiederholungen über eine Bash-Variable vermeiden.

export BORG_REPO=/mnt/backup-8tb/borg_nas
export BORG_PASSPHRASE='DeinSuperSicheresPasswortZumSchutzDeinerBackups!'

Im Skript empfehle ich folgenden Ablauf:

  • Anlegen der Sicherung(en), also Archive
  • Gegebenenfalls Passwortsafe außerhalb des Repos kopieren, um sich nicht auszusperren (siehe oben)
  • Bereinigen alter Sicherungen mit borg prune (hierfür definieren, wie lange ihr Sicherungen aufbewahren möchtet)
  • Freigabe des bereinigten Speicherplatzes im Dateisystem: borg compact

Es ist eine gute Idee, eine Sicherung zu automatisieren und die dortigen Ausgaben in eine Logdatei zu schreiben.

Wiederherstellen von Daten aus einer Sicherung

Es gibt eine alte Weisheit, die besagt: Ein nicht getestetes Backup ist kein Backup. Manche bewerten dies sogar noch schlimmer, weil es ein falsches Gefühl von Sicherheit vermitteln kann. Das kommt nicht von ungefähr – zwei gute Gründe sprechen dafür, das Rücksichern am besten direkt nach dem Durchlauf der ersten Sicherung zu testen:

  1. Sieht man, was enthalten ist. Wurden Dateien vergessen, kann rechtzeitig nachgebessert werden.
  2. Der Ablauf ist bekannt und am besten dokumentiert, um ihn im Ernstfall zeitnah durchführen zu können.

Auch darüber hinaus ist es ratsam, die Sicherungen in regelmäßigen Abständen zu prüfen. Schließlich gibt es weitere Dinge, die schief gehen können.

Borg bietet die Möglichkeit, eine Sicherung (also das Archiv in einem Repository) als Dateisystem einzuhängen.7 Dabei kann man wahlweise das ganze Repository einhängen und sieht die Archive als Unterordner – sehr praktisch, falls man z.B. eine fehlerhafte Datei wiederherstellen möchte, bei der nicht genau klar ist, welche Sicherung die aktuellste, funktionierende enthält. Oder man hängt ein spezifisches Archiv ein.

sudo mkdir /mnt/borg_restore
borg mount /home/daniel/backups_borg /mnt/borg_restore/

Wer sich für das Einhängen eines einzelnen Archivs entscheidet, möchte sich wahrscheinlich die existierenden vorher anzeigen lassen:

borg list /mnt/backup-8tb/borg_nas

Nun kann der Einhängepfad (hier /mnt/borg_restore/) beliebig durchsucht werden. Das erste Öffnen eines Archivs dauert einige Sekunden (meinen Tests ca. 15s), da das Laden erst beim Abruf erfolgt. Danach ist die Navigation nicht spürbar langsamer, als ein natives Dateisystem. Es kann einfach durchsucht werden und man kopiert sich benötigte Dateien heraus.

Nach Abschluss das Dateisystem wieder aushängen:

sudo umount /mnt/borg_restore

Fazit

Inkrementell, Komprimiert, Dedupliziert – viel mehr lässt sich kaum machen, um Datensicherungen möglichst sparsam zu speichern. Borg bietet viele Funktionen, um auch umfangreichere Sicherungen durchzuführen. In Anbetracht der zu durchsuchenden Datenmenge ist die Sicherung recht flott abgeschlossen: Für über 215.000 Dateien waren nur gute 3,5 Minuten notwendig, um 1,72 GB/1,24 TB neuer Dateien in das Backup aufzunehmen.

Es eignet sich besonders für Fans der Kommandozeile und damit zur (Teil-) Automatisierung. Durch inkrementelle Durchläufe können Sicherungen häufig stattfinden, ohne riesige Dateimengen zu verursachen. Über eine Client-Server Architektur lassen sich Backups per SSH auf entfernten Systemen anlegen.8 Eine Integration in z.B. öffentliche Clouddienste fehlt dagegen. Wer das benötigt oder lieber mit grafischen Oberflächen arbeitet, findet mit Duplicati eine Alternative.

Weiterführende Infos

  • Das Format der Repository URLs wird hier in allen Varianten beschrieben. Darunter auch für entfernte Repos.
    https://borgbackup.readthedocs.io/en/stable/usage/general.html
  • Flags, die Borg während der Sicherung anzeigt. Sie informieren darüber, ob eine Datei neu hinzugefügt/modifiziert wurde oder als unverändert übersprungen.
    https://borgbackup.readthedocs.io/en/stable/usage/create.html#item-flags
  • Eine gute Übersicht für den Einstieg bietet auch der Artikel im Ubuntu-Wiki:
    https://wiki.ubuntuusers.de/BorgBackup/

Quellen

  1. https://www.borgbackup.org/releases/ ↩︎
  2. https://github.com/borgbackup/borg/releases ↩︎
  3. https://borgbackup.readthedocs.io/en/stable/usage/init.html ↩︎
  4. https://borgbackup.readthedocs.io/en/stable/usage/create.html ↩︎
  5. https://github.com/borgbackup/borg/issues/5038#issuecomment-599491540 ↩︎
  6. https://borgbackup.readthedocs.io/en/stable/usage/delete.html ↩︎
  7. https://borgbackup.readthedocs.io/en/stable/usage/mount.html ↩︎
  8. https://borgbackup.readthedocs.io/en/stable/usage/serve.html ↩︎