Die Menge an Daten sowie deren Bedeutung für den Geschäftsbetrieb wächst laut EMC Globaler Data-Protection-Index (2018) in einem rasanten Tempo: Von 1.45 PB (Petabyte) in 2016 auf 9.70 PB in 2018. Zusätzlich gaben in der Studie 41 % der befragten Unternehmen an, innerhalb der letzten 12 Monate bereits Datenverluste oder unerwartete Ausfallzeiten verzeichnet zu haben. Mit $996.000 sind die Durchschnittskosten im Falle von Datenverlust dabei fast doppelt so hoch wie die Kosten für ungeplante Systemausfallzeiten, die im Schnitt bei $527.000 liegen.

Längst ist jedoch Datenverlust nicht mehr nur ein Resultat von Hardware- oder Anwenderfehlern, auch Hackerangriffe und Schadsoftware wie Ransomware stellen ein erhebliches Risiko für die Verfügbarkeit und Integrität von Daten dar. Gemäß einer Studie von Sophos (2020) gaben von 5.000 befragten Unternehmen mehr als die Hälfte (51 %) an, in den vergangenen 12 Monaten einen Lösegeldangriff erlebt zu haben. In 73 % der Fälle, bei denen es Angreifer schafften, in die Organisation einzudringen, gelang es diesen in Folge ebenfalls, Daten zu verschlüsseln, was abermals die immense Bedeutung von Datensicherung für IT-Infrastrukturen unterstreicht.

Auf dem Markt existieren zahlreiche Lösungen zur Datensicherung, jedoch sollten diese stets nach konkretem Anforderungsprofil gewählt werden. Dennoch wird im Folgenden mit BorgBackup eine beispielhafte Open-Source Softwarelösung vorgestellt.

BorgBackup

BorgBackup (kurz: Borg) ist ein deduplizierendes Backup-Programm. Dabei unterstützt die Anwendung eine Komprimierung der Daten sowie eine authentifizierte Verschlüsselung. Durch die schnelle und platzsparende Erstellung von inkrementellen Backups sowie die Nutzung von Kryptografie stellt Borg eine effiziente und sichere Möglichkeit zur Datensicherung dar. Dank dem inkrementellen Ansatz, bei dem nur Änderungen gespeichert werden, sowie der Deduplizierung von Daten ist Borg zudem für tägliche Backups geeignet.

Durch den Einsatz von Verschlüsselung kann dabei die Sicherung sogar auf nicht vollständig vertrauenswürdigen Zielen erfolgen, bspw. auf externen Zielen unter Nutzung des als sicher angesehenen SSH-Protokolls. Ist Borg ebenfalls auf dem Remote-Host installiert, so nimmt Borg dabei eine Sonderrolle im Vergleich zu diversen anderen Backuplösungen ein, die ebenfalls eine Verschlüsselung von Backuparchiven unterstützen:

Es können große Leistungsgewinne gegenüber der Verwendung reiner Netzwerk-Dateisysteme (wie SSHFS, NFS etc.) erreicht werden, da bspw. Integritätsprüfungen lokal auf dem Backup-Zielsystem durchgeführt werden können und somit ein potenziell langsamer Zugriff über das Netzwerk vermieden wird.
Borg unterstützt zudem den sogenannten „Append-Only“-Modus, mittels welchen nur weitere (inkrementelle) Sicherungen hinzugefügt werden, bestehende Sicherungen jedoch niemals überschrieben oder gelöscht werden können. Dieser Modus ist im Nachfolgenden ausführlicher beschrieben.

„Append-Only“-Modus

Betrachtet man bei der Umsetzung einer Datensicherungslösung den Fall, dass einem versierten Angreifer das Eindringen in zumindest ein System gilt, also bspw. entweder das Quellsystem mit den Primärdaten oder das Backup-Ziel, so zeigt sich schnell die Problematik einer etwaigen Eskalation der Zugriffsrechte auf das jeweilige andere System. Ein Zugriff auf beide Systeme birgt die Gefahr der Löschung von sowohl den Primärdaten (Datenquelle) als auch deren Sicherungen. Die möglichen Varianten der Umsetzung von Sicherungslösungen werden im Folgenden genauer erörtert – hierbei bezeichnet Q die Datenquelle und Z das Zielsystem.

Wird die Datensicherungssoftware auf dem System Q ausgeführt und schreibt dabei Daten auf Z, könnte ein Angreifer, der in Q eindringt, ebenfalls die Sicherung auf Z manipulieren (wie bspw. löschen).
Wird hingegen die Datensicherungssoftware auf Z ausgeführt und somit auf Q (lesend) zugegriffen, könnte ein Angreifer, der in Z eindringt, ebenfalls die Ausgangsdateien auf Q manipulieren, sofern für diese auch schreibender Zugriff vorliegt. Außerdem führt dieses Szenario zu weiteren Komplikationen, da hierbei Z vollumfänglich vertraut werden muss, da dieses auf unverschlüsselte Dateien von Q zugreift. Das bedeutet, falls ein Angreifer die Kontrolle über Z erlangt, dieser die Quelldateien in unverschlüsselter Form auslesen kann, selbst wenn eine Ausweitung der Zugriffsrechte von Z auf Q nicht möglich ist.

Dieses Problem wird von Borg mittels dem „Append-Only“-Modus gelöst.

Hierbei wird die Datensicherung zunächst auf der Datenquelle Q veranlasst. Die Datensicherungssoftware wird dabei jedoch zusätzlich ebenfalls auf dem Zielsystem Z ausgeführt und ist dabei so konfiguriert, dass nur weitere Sicherungen hinzugefügt, bestehende jedoch nicht gelöscht oder manipuliert werden können. Betrachtet man erneut das zuvor dargestellte Szenario, ergibt sich hierbei eine höhere Sicherheit der Daten:

Würde ein Angreifer auf Q eindringen, könnten die Sicherungen auf Z nicht manipuliert oder gelöscht werden, da derartige Anweisungen von Z abgelehnt werden würden.
Gelingt es hingegen einem Angreifer, die Kontrolle über Z zu erlangen, so könnten zwar die Sicherungen gelöscht werden, dabei besteht jedoch kein Zugriff auf Q oder dessen Daten, weshalb die Ausgangsdaten unversehrt bleiben. Wird zudem für die Datensicherung Verschlüsselung und Integritätsschutz eingesetzt, ist es einem Angreifer somit ebenfalls nicht möglich, auf die Daten zuzugreifen, und etwaige Manipulationsversuche bestehender Sicherungen können erkannt werden.

Trotz Nutzung des „Append-Only“-Modus ist die Nutzung des prune-Kommandos möglich, welches das Löschen alter Backups ermöglicht. Hierbei sind jedoch einige Besonderheiten zu beachten. Da im „Append-Only“-Modus das Löschen von Sicherungen bzw. Datensegmenten verhindert wird, werden diese Sicherungen auf dem Zielsystem nicht tatsächlich gelöscht, sondern lediglich als gelöscht markiert – eine Freigabe von Speicherplatz erfolgt daher zunächst nicht.

Die Freigabe von Speicherplatz ist dennoch möglich, indem von einem vertrauenswürdigen System zugegriffen wird, welches die Berechtigung besitzt, Wartungsmaßnahmen an den Datensicherungen vorzunehmen und dabei den „Append-Only“-Modus zu umgehen. Da in Folge derartiger Wartungsmaßnahmen tatsächlich Daten vom Zielsystem entfernt werden, wird hierbei dringend die vorherige Überprüfung der Daten empfohlen. Andernfalls wäre es einem Angreifer, der die Kontrolle über das Zielsystem erlangt hat, möglich, Backuparchive unbemerkt zu beschädigen, selbst wenn augenscheinlich die Archivdateien noch auf dem System liegen. Daher sollte stets vor entsprechenden Schreib- oder Löschoperationen eine Integritätsprüfung durchgeführt werden, um versehentliche oder böswillige Beschädigungen auszuschließen.

Die Prüfung der Integrität der Daten auf dem Zielsystem wird ebenfalls von Borg unterstützt und kann bspw. mit nachfolgendem Befehl durchgeführt werden:

Syntax Highlighter$ borg check --verify-data /path/to/repo

Für weitere Besonderheiten im Umgang mit dem „Append-Only“-Modus wird hierbei auf die offizielle Dokumentation verwiesen.

Installation

Kompilierte Binärdateien stehen für die Plattformen Linux, MacOS und FreeBSD zur Verfügung, alternativ kann Borg auch selbst kompiliert werden, da als Open-Source-Projekt der Quellcode öffentlich zugänglich ist.

In zahlreichen Linux Distributionen kann zudem BorgBackup auch über die Paketverwaltung installiert werden. Jedoch ist die in den Paketquellen enthaltene Version von Borg oftmals veraltet, weshalb sich eine Überprüfung dieser empfiehlt.

Da die Erläuterung der verschiedenen Installationspfade den Rahmen dieses Blog-Beitrags sprengen würde, wird an dieser Stelle auf die offizielle Dokumentation verwiesen.

Schnellstart

Zunächst sei erwähnt, dass Borg über eine enorme Anzahl an Konfigurationsmöglichkeiten und Optionen verfügt, dieser Blog-Beitrag jedoch nur als Einführung zu verstehen ist und einen ersten Überblick verschaffen soll. Weitere Informationen über die verfügbaren Optionen und Eigenschaften können jedoch der Kommandozeilen-Dokumentation entnommen werden.

Initialisierung: Anlegen eines Repositorys (Backup-Speicherort)

Ein Repository stellt den Speicherort dar, unter welchem die Sicherungsarchive abgelegt werden können. Bevor ein Speicherort wie bspw. ein Ordner auf dem Dateisystem genutzt werden kann, muss dieser jedoch initialisiert werden – sozusagen das Repository angelegt werden. Hierbei erfolgt zudem die Konfiguration des Repositorys, wie bspw. der Verschlüsselungsmodus. Beispiel:

Syntax Highlighter$ borg init --encryption=repokey /path/to/repo

(Anmerkung: Weitere Optionen, wie u.a. --append-only und --storage-quota QUOTA werden ebenfalls unterstützt.)

Der hierbei wichtigste Parameter ist wohl --encryption=repokey, da mit diesem der Verschlüsselungsmodus definiert wird. Folgende Modi werden dabei unterstützt:

Name	Hash/MAC	Authentisierung	Verschlüsselung	Speicherort Schlüssel
none	SHA-256	❌ Nein	❌ Nein	n/a
authenticated	SHA-256	✔️ Ja	❌ Nein	n/a
repokey	SHA-256	✔️ Ja	✔️ Ja	Repository (=ggf. Remote)
keyfile	SHA-256	✔️ Ja	✔️ Ja	Lokal
authenticated-blake2	BLAKE2b	✔️ Ja	❌ Nein	n/a
repokey-blake2	BLAKE2b	✔️ Ja	✔️ Ja	Repository (=ggf. Remote)
keyfile-blake2	BLAKE2b	✔️ Ja	✔️ Ja	Lokal

Wird Verschlüsselung genutzt, wird neben der Schlüssel-Datei stets zusätzlich ein Passwort abgefragt. Nur wenn sowohl der Schlüssel als auch das zugehörige Passwort bekannt sind, ist es möglich, auf den Inhalt der Datensicherung(en) zuzugreifen. Wird der Modus repokey oder repokey-blake2 genutzt, so wird der Schlüssel innerhalb des Repositorys abgelegt, also auf dem Zielsystem. Dabei kann es sich entweder um dasselbe System (lokal) oder ein entferntes System (Remote) handeln. Erlangt ein Angreifer Zugriff auf dieses, verfügt er zwar über die Schlüsseldatei, benötigt jedoch für den Zugriff auf die Sicherungen zusätzlich das zugehörige Passwort.

Wird hingegen keyfile oder keyfile-blake2 genutzt, so verbleibt der Schlüssel auf dem System, welches die Sicherung veranlasst. Einem Angreifer, der Zugriff auf das Zielsystem erhält, fehlen somit sowohl die Schlüsseldatei als auch das Passwort, um auf den Inhalt der Datensicherungen zugreifen zu können.

Im Umkehrschluss bedeutet dies jedoch auch: Sollten im Ernstfall die Schlüsseldatei oder das Passwort nicht mehr zugänglich sein, ist keine Datenwiederherstellung möglich, selbst wenn die Sicherungsarchive unversehrt sind.

Daher sollten sowohl der Schlüssel als auch das zugehörige Passwort sicher und getrennt verwahrt werden, beispielsweise ausgedruckt in einem Safe.

Für den Export des Schlüssels kann das Kommando borg key export genutzt werden, bspw.:

Syntax Highlighter$ borg key export --paper /path/to/repo ./key.txt

Achtung: Dieses Kommando exportiert lediglich die Schlüsseldatei, das zugehörige Passwort wird weiterhin benötigt.

Durchführen einer Sicherung

Im nachfolgenden Beispiel sollen die Ordner ~/src und ~/Documents gesichert werden. Jedem Backuparchiv kann dabei ein Name gegeben werden. Im nachfolgenden Beispiel wird angenommen, dass die erste Sicherung an einem Montag erfolgt, weshalb diese Sicherung „Monday“ benannt wird:

Syntax Highlighter$ borg create --stats /path/to/repo::Monday ~/src ~/Documents

Am darauffolgenden Tag erfolgt eine weitere Sicherung, diesmal mit dem Namen „Tuesday“. Bei der Sicherung wird zudem der Parameter --stats genutzt, bei welchem zusätzlich die Ausgabe einer Statistik erfolgt:

Syntax Highlighter$ borg create --stats /path/to/repo::Tuesday ~/src ~/Documents

------------------------------------------------------------------------------
Archive name: Tuesday
Archive fingerprint: bd31004d58f51ea06ff735d2e5ac49376901b21d58035f8fb05dbf866566e3c2
Time (start): Tue, 2016-02-16 18:15:11
Time (end):   Tue, 2016-02-16 18:15:11

Duration: 0.19 seconds
Number of files: 127
------------------------------------------------------------------------------
                      Original size      Compressed size    Deduplicated size
This archive:                4.16 MB              4.17 MB             26.78 kB
All archives:                8.33 MB              8.34 MB              4.19 MB

                      Unique chunks         Total chunks
Chunk index:                     132                  261
------------------------------------------------------------------------------

Wie am obigen Beispiel zu sehen ist, beträgt die zu sichernde Datenmenge (Quell-Ordner) 4.16 MB. Da bereits am Vortag eine Sicherung stattgefunden hat, beträgt die Datenmenge aller Archive 8.33 MB, da zwei Sicherungen mit jeweils ~4.16 MB stattgefunden haben. Der für die zweite Sicherung tatsächlich benötigte Speicherplatz beträgt hingegen nur 26.78 kB, da aufgrund der Datendeduplikation Dateien, die sich nicht geändert haben, nicht erneut gesichert wurden.

Der tatsächlich insgesamt benötigte Speicherplatz für alle Archive beträgt daher nur 4.19 MB (ergibt sich grob aus 4.17 MB für die erste Sicherung plus 26.78 kB für die inkrementelle zweite Sicherung).

Auflisten von Sicherungen und deren Inhalt

Liste verfügbarer Archive:

Syntax Highlighter$ borg list /path/to/repo
Monday                               Mon, 2016-02-15 19:14:44
Tuesday                              Tue, 2016-02-16 19:15:11

Inhalt eines Archivs:

Syntax Highlighter$ borg list /path/to/repo::Monday
drwxr-xr-x user   group          0 Mon, 2016-02-15 18:22:30 home/user/Documents
-rw-r--r-- user   group       7961 Mon, 2016-02-15 18:22:30 home/user/Documents/Important.doc
...

Wiederherstellen eines Archivs

Nachfolgendes Kommando extrahiert den Inhalt des Archivs mit dem Namen „Monday“ in den aktuellen Ordner:

Syntax Highlighter$ borg extract /path/to/repo::Monday

Einbinden von Archiven in das Dateisystem („Mounten“)

Statt dem Extrahieren von Dateien aus einem Sicherungsarchiv können Archive auch dynamisch als FUSE Dateisystem mittels dem Befehl borg mount eingebunden werden. Voraussetzung ist dabei, dass FUSE auf dem System, auf welchem der Befehl ausgeführt wird, unterstützt wird. Beispiel:

Syntax Highlighter$ borg mount /path/to/repo /tmp/mymountpoint
$ ls /tmp/mymountpoint
root-2016-02-14 root-2016-02-15
$ ls /tmp/mymountpoint/root-2016-02-14
bin  boot  etc      home  lib  lib64  lost+found  media  mnt  opt
root  sbin  srv  tmp  usr  var
$ borg umount /tmp/mymountpoint

Dabei ist es nicht erforderlich, dass sich das Repository auf dem lokalen Dateisystem befindet, sondern kann sich ebenfalls auf einem Remote-Server befinden und über SSH eingebunden werden:

Löschen eines Archivs

Nachfolgendes Kommando löscht ein einzelnes Archiv und gibt nicht mehr benötigten Speicher frei. Dabei werden ausschließlich die Segmente gelöscht, welche nicht länger benötigt werden. Somit können trotz inkrementeller Sicherung Archive gelöscht werden, ohne die Integrität neuerer Sicherungen zu gefährden.

Ausblick

Aufgrund der diversen Konfigurationsmöglichkeiten können die Kommandozeilenbefehle zum Erstellen und Warten von Sicherungen sehr komplex und somit unübersichtlich werden. Um die Verwaltung und Steuerung von Sicherungen zu vereinfachen, bietet sich daher der Einsatz des Tools borgmatic an, welches eine einfache Konfiguration von BorgBackup mittels der YAML-Syntax ermöglicht.

Ferner kann die Sicherheit beim Einsatz von BorgBackup sowohl bei der Datenquelle als auch beim Backupziel durch den Einsatz von Containern weiter gehärtet werden.

Außerdem ist mit BorgBackup auch die Sicherung von Windows-basierten Systemen möglich, bspw. durch den Einsatz von Windows Subsystem for Linux (WSL).

Diese Themen werden in zwei weiteren Blogposts ebenfalls vorgestellt. Lesen Sie jetzt Teil 2.

BorgBackup: Einführung – Verschlüsselte inkrementelle Datensicherung (Teil 1/3)