DecaTec

Home-Server | Linux | Nextcloud | Raspberry Pi | Programmierung | Fotografie

Backup-Strategie für Linux-Server mit Borg Backup

Logo Backup

Wer einen eigenen (Home-)Server betreibt, sollte sich auf jeden Fall Gedanken über Backups machen. Spätestens, wenn wichtige Dateien mal unbeabsichtigt gelöscht wurden, kann man froh sein, wenn man auf Backups zurück greifen kann.

Deshalb möchte ich an dieser Stelle meine Backup-Strategie für Linux-Server vorstellen. Diese basiert hauptsächlich auf dem Programm Borg Backup und wird ergänzt durch eigene Backup-Skripte.

Als Betriebssystem kommt hier Ubuntu Server 18.04 zum Einsatz, das Gezeigte kann allerdings auch auf anderen Distributionen umgesetzt werden.

Die Inspiration zu dieser Tutorial stammt aus einem Artikel von Thomas Leister: Borg Backup für Serversicherungen. Ich habe diese Strategie jedoch an meine Bedürfnisse angepasst.
Genau dies solltet ihr übrigens auch machen: Jeder hat hier individuelle Anforderungen, daher wird es nicht die eine Lösung geben. Daher könnt ihr die hier gezeigte Lösung/Skripte als Vorlage nehmen, die ihr dann an eure eigenen Bedürfnisse anpasst.

Borg Backup

Den größten Teil der Arbeit übernimmt das Programm Borg Backup. Dies ist ein Backup-Programm, welches einige Vorteile bietet:

  • Kompression: Die Backups werden komprimiert.
  • Verschlüsselung: Die Backups können verschlüsselt werden.
  • Deduplizierung: Bei mehreren aufeinander folgenden Backups werden nur die inkrementellen Änderungen gesichert. Wenn mit dem ersten Backup beispielsweise 1 GB Daten gespeichert wurden und es ändern sich darauf hin nur 100 MB, dann werden im folgenden Backup nur diese 100 MB an Daten gesichert.

Durch die Verschlüsselung ist die Sicherheit der Backups gewährleistet, so dass man diese auch z.B. auf einem FTP-Server im Internet sichern könnte.
Durch die Verschlüsselung und Deduplizierung sind die Backups recht kompakt und werden schnell angefertigt.

Um Borg Backup zu installieren, bringen wir das System erst einmal auf den aktuellen Stand:

Anschließend kann Borg Backup installiert werden:

Nun kann es schon an die Einrichtung des Backups gehen.

Backup einrichten

Übersicht

Zunächst ein paar Worte zum grundsätzlichen Vorgehen.

Ziel ist ein Backup-Skript, welches alle wichtigen Teile des Systems sichert:

  • Wichtige Dateien und Verzeichnisse.
  • Komplette Anwendungen.

Unter kompletten Anwendungen verstehe ich hier ein komplettes Backup einer Anwendung, welches grundsätzlich auch erst mal für sich allein angefertigt werden kann. Als Beispiel für eine solche Anwendung dient im Rahmen dieses Artikels Nextcloud, eine selbst gehostete Cloud-Lösung. Wie ein Backup von Nextcloud angefertigt werden kann, habe ich bereits im Artikel Nextcloud: Backups erstellen und wiederherstellen – manuell oder per Skript beschrieben. Das Skript, welches im Rahmen dieses Artikels erstellt wurde, kann nun für das komplette Backup des Servers wiederverwendet werden.

Jedoch kann auch jede beliebige andere Anwendung mittels des Server-Backup-Skripts gesichert werden: Weitere Beispiele wären hier z.B. FHEM, oder auch ein Firefox Sync-Server.

Das grundsätzliche Vorgehen sieht nun so aus, dass zunächst alle zu sichernden Anwendungen einzeln auf einen temporären Speicherort gesichert werden. Anschließend werden diese einzelnen Backups zusammen mit den zu sichernden Verzeichnissen des Systems an Borg Backup für die Gesamt-Sicherung übergeben. Anschließend werden die temporären Backups der Anwendungen wieder gelöscht.

In diesem Zusammenhang ist es nur wichtig, dass keine Teile des Systems doppelt gesichert werden. Wenn z.B. das Web-Verzeichnis (meist unter /var/www zu finden) gesichert werden soll, ist bei der Übergabe an Borg Backup das Nextcloud-Verzeichnis (unter /var/www/nextcloud) vom Backup auszuschließen, da dies ja schon durch die Nextcloud-Sicherung gespeichert wurde.

Individuelle Sicherung von Anwendungen

Zunächst beschäftigen wir uns mit dem Backup einzelner Anwendungen. Wie bereits erwähnt, dient hier Nextcloud als Beispiel-Anwendung, die es nun zu sichern gilt. Dieses Thema wurde hier bereits im Blog mit dem Artikel Nextcloud: Backups erstellen und wiederherstellen – manuell oder per Skript behandelt. Aus diesem Grund sei hier auf das dazugehörige Bash-Skript verwiesen, welches auf Codeberg verfügbar ist: Nextcloud Backup Restore

Wenn andere Anwendungen gesichert werden sollen, empfiehlt es sich, hier ebenfalls ein gesondertes Skript anzufertigen. Als weiteres Beispiel sei an dieser Stelle WordPress erwähnt (WordPress: Backups erstellen und wiederherstellen – manuell oder per Skript). Das dazugehörige Bash-Skript ist ebenfalls auf Codeberg verfügbar: WordPress Backup Restore

Borg Repository einrichten

Vor der Erstellung des Backup-Skripts muss noch das sog. Borg-Repository angelegt werden. In diesem Beispiel erfolgt dies auf einer zweiten internen HDD (/media/hdd2). Es kann aber auch ein beliebiges anderes Verzeichnis sein (z.B. ein per fstab gemountetes NAS). Das Repository wird dabei mit folgenden Befehlen angelegt:

Beim Angelgen wird nach einem Passwort gefragt. Dieses sollte ein ausreichend sicheres Passwort sein. Dieses Passwort sollte man sich auch gut merken, denn ohne das Passwort kann kein Zugriff auf die Backups erfolgen. Am besten speichert es man sich gleich in einem Passwort-Safe (wie z.B. KeePass ab).

Der Befehl zum Initialisieren eines Repositories bietet noch weitere Optionen. So ist es auch möglich, die Verschlüsselung mittels einer Schlüssel-Datei zu realisieren. Eine genaue Beschreibung zum Initialisieren von Borg-Repositories ist in der offiziellen Dokumentation zu finden.

Auch wenn es möglich ist, ein Repository ohne Verschlüsselung anzulegen, rate ich davon ab. Die Verschlüsselung sollte beim Initialisieren immer verwendet werden.

Backup-Skript erstellen

Wie sämtliche Skripte speichere ich auch die Backup-Skripte im Verzeichnis /home/<user>/scripts. Hier wird erst einmal das Skript selbst erstellt:

Der Inhalt sieht dann wie folgt aus:

Das komplette Skript ist auch als Git-Repository auf Codeberg verfügbar: Linux-Server-Backup @ Codeberg

Bevor man das Skript also mühselig kopiert und einfügt, kann einfach das Repository gecloned werden:

Wichtig: In diesem Skript sind alle Stellen, die individuell angepasst werden müssen mit einem TODO im Kommentar gekennzeichnet (die betrifft v.a. Verzeichnis-Angaben). Daher das Skript bitte nicht einfach übernehmen, sondern immer auf die eigenen Bedürfnisse anpassen.

Erläuterungen zum den einzelnen Schritten des Backup-Skripts (bitte auch die Kommentare im Skript selbst beachten):

  • Als erstes werden Variablen zum Bedienen des Borg-Repositories gesetzt. Die betrifft v.a. das vergebene Passwort (Variable BORG_PASSPHRASE).
  • Mit der Variable logDirectory wird das Verzeichnis festgelegt, in das pro Backup ein Log-File geschrieben wird.
  • Mit localBackupDir wird das Verzeichnis angegeben, in das die lokalen Backups gespeichert werden – also in diesem Fall das gesondert angefertigte Nextcloud-Backup. Nach dem Aufruf von Borg werden die Inhalte dieses Verzeichnisses wieder gelöscht.
  • Anschließend wird das Verzeichnis des Borg-Repositories angegeben (borgRepository) und die Verzeichnisse definiert, die später von Borg direkt gesichert werden sollen (borgBackupDirs).
  • Es folgen die Verzeichnis-Angaben für das separate Nextcloud-Backup. Da /var/www ja schon direkt per Borg gesichert wird, ist das Web-Verzeichnis von Nextcloud später vom Backup auszuschließen (nextcloudDirBorgExclude).
  • Anschließend erfolgt bei der Ausführung des Skripts die Überprüfung, ob dieses auch mit Root-Rechten ausgeführt wird.
  • Nun beginnt die eigentliche Ausführung des Skripts: Es wird eine Liste der installierten Pakete im lokalen Backup-Verzeichnis gespeichert (sinnvoll, wenn das Backup auf einem anderen System wiederhergestellt werden sollte).
  • Das Nextcloud-Backup wird dann einfach durch das Aufrufen des Nextcloud-Backup-Skripts erstellt.
  • Es folgt der eigentliche Aufruf von Borg Backup.
  • Anschließend werden die (temporären) lokalen Backups wieder gelöscht.
  • Nun wird das Borg-Repository bereinigt. In diesem Beispiel sollen Backups der letzten 7 Tage, 4 wöchentliche Backups und 6 monatliche Backups behalten werden. Backup-Sets, die nicht mehr diesem Muster entsprechen, werden aus dem Respository gelöscht und dieses wird konsolidiert.
  • Ganz am Ende des Skripts wird noch eine E-Mail versendet. Damit dies funktionieren kann, muss auf dem System ein MTA installiert sein (siehe Linux: Einfach E-Mails versenden mit msmtp).

Ist das Skript erstellt, werden die Zugriffsrechte noch eingeschränkt (hier ist ja das Passwort des Borg-Repositories gespeichert) und das Skript wird als ausführbar gekennzeichnet:

Das Backup-Skript kann nun für einen ersten Lauf manuell ausgeführt werden:

Die erste Ausführung dauert in der Regel etwas länger, da alle zu sichernden Verzeichnisse und lokalen Backups gesichert werden müssen. Weitere Ausführungen des Skripts sollten dann aber deutlich schneller ablaufen.

Backups automatisieren

Das Anfertigen der Backups kann nun mittels Cron einfach automatisiert werden. Dazu muss lediglich für den Root-User ein Cronjob eingerichtet werden:

Hier fügen wir nun ganz unten z.B. folgende Zeile hinzu:

Nun wird das Backup-Skript jede Nacht um 02:00 aufgerufen.

Hinweis: Der Pfad zum Skript muss in der Crontab immer absolut (also mit dem kompletten Verzeichnis-Pfad) angegeben werden.

Wenn das Skript zu einem anderen Zeitpunkt ausgeführt werden soll, kann ich die Seite contab guru empfehlen: Dies ist eine Seite zum einfachen Erstellen von Crontab Zeitplänen. Hiermit wird es einfacher, die Syntax für den Zeitplan eines Cronjobs zu erzeugen.

Off-Shore Backups

Das Backup kann mit diesem Skript an jeden beliebigen Ort gespeichert werden, der auf der lokalen Maschine verfügbar ist (z.B. eine zweite interne Festplatte, ein NAS, etc.). Nun kann man sich Gedanken über ein „Offshore-Backup“ machen: Dies bedeutet, dass man ein weiteres Backup anfertigt, welches jedoch örtlich getrennt vom ersten Backup ist. Im einfachsten Fall ist dies ein Backup auf einer externen Festplatte, welche bei Freunden/Verwandten gelagert wird, oder auch ein Backup in eine Cloud. Sinn und Zweck hierbei ist die Datensicherheit im Katastrophenfall (z.B. bei Hausbrand, Überschwemmung, Diebstahl, etc.).

Das Borg-Repository kann dazu in seiner Gesamtheit an einen beliebigen Ort kopiert werden und schon hat man ein zweites identisches Backup. Durch die Verschlüsselung des Backups muss man sich hierbei auch keine Gedanken um unbefugten Zugriff machen: Selbst, wenn die externe Festplatte in die falschen Hände gerät, kann ein Dritter keinen Zugriff auf die Daten des Backups erlangen.

Um das Borg-Repository (/media/hdd2/server_backup) beispielsweise auf eine externe Festplatte (hier z.B. gemountet unter /media/hdd_ext) zu kopieren, kann einfach rsync verwendet werden:

Das zweite Backup ist dann eine identische Kopie des ersten Backups und kann genau so zur Wiederherstellung verwendet werden.

Dies kann dann auch auf einem anderen Rechner geschehen. Die einzige Voraussetzung ist eine Installation von Borg Backup und das Passwort des Original-Repositories.

Backups wiederherstellen

Ein Backup anzufertigen ist die eine Sache. Bevor man im Problemfall darauf angewiesen ist, sollte man sich auf jeden Fall damit vertraut machen, wie man die Daten aus dem Backup wiederherstellen kann.

Für die Wiederherstellung von Dateien und Verzeichnissen gibt es z.B. den Befehl borg extract (siehe Borg Dokumentation).

Ich gehe hier aber meistens einen anderen Weg, da dies für mich persönlich komfortabler ist. Zunächst kann man sich eine Liste an „Backup-Sets“ anzeigen lassen:

Nach der Eingabe des Passworts werden alle verfügbaren Backup-Sets aufgelistet (hier rot markiert):

Borg: Auflistung der Backup-Sets

Borg: Auflistung der Backup-Sets

Ein Backup-Set kann nun einfach in das Dateisystem gemountet werden:

Wieder wird nach dem Passwort gefragt und anschließend ist das komplette Backup (mitsamt Unterverzeichnissen) unter /mnt/borg gemountet und man kann mit normalen Dateioperationen darauf zugreifen.

Um nun beispielsweise eine einzelne Datei auf dem Backup zu extrahieren, kann ganz einfach cp verwendet werden:

Nach dem Extrahieren der benötigten Dateien aus dem Backup kann das Backup-Set wieder ausgehängt werden:

Wenn nun keine einzelnen Dateien, sondern das Backup einer kompletten Applikation wiederhergestellt werden muss, wird das Backup der Anwendung aus dem Borg-Repository extrahiert. Anschließend wird dies separat wiederhergestellt. Siehe beispielsweise die Restore-Anweisungen für Nextcloud.

Troubleshooting

Das hier gezeigte Skript ist natürlich nur ein Beispiel und kann beliebig erweitert werden. Damit kann das Skript auch durchaus umfangreich werden. Wenn das Skript dann nicht richtig funktionieren sollte, ist der erste Schritt immer die Kontrolle der Logs, die durch das Skript angelegt werden. Sollte dies nicht zur Lösung des Problems führen, sollten die einzelnen Schritte, die im Skript enthalten sind, einzeln und in genau der Reihenfolge auf der Kommandozeile ausgeführt werden. Hier sollte dann zumindest der Schritt identifiziert werden können, ab dem das Skript „aus dem Ruder läuft“. Wenn das Problem gefunden wurde, sollte anschließend das Skript dementsprechend angepasst werden.

Fazit

Dieser Artikel hat eine einfache und effiziente Möglichkeit skizziert, wie ein Linux-System gesichert werden kann. Das bereit gestellt Skript kann als Ausgangspunkt für eigene Backup-Strategien verwendet werden.

Wenn das System erst einmal eingerichtet wurde (und das Wiederherstellen der angefertigten Backups getestet wurde!), können die Backups automatisiert werden, so dass man hier in Zukunft nicht mehr viel Zeit investieren muss. Im Problemfall kann man dann ganz einfach auf die erstellten Backups zurückgreifen.

Habt ihr euch für euren Server auch schon eine Backup-Strategie ausgedacht? Wie sieht diese im Detail aus? Hinterlasst mir dazu doch einfach einen Kommentar.

Weiterführende Artikel

Links

, , , , , , ,

Kommentare: 13

  • Predrag sagt:

    Hallo Jan,
    Ist denn Veeam Backup Agent for Linux nicht einfacher einzurichten? Zumindest für die die keine besonderen Anpassungen am Backup vornehmen wollen …

  • Tobias sagt:

    Hi,
    danke für das Tutorial. Ich benutze lieber Duplicati, dass lässt sich einfacher mit einer GUI verwalten.

    Gruß Tobi

  • Jan sagt:

    Hallo Jan,
    vielen Dank für diese 1A Anleitung, alles hat wie beschrieben super funktioniert. Schöne Feiertage und einen Guten Rutsch ins neue Jahr.

  • Frank sagt:

    Hallo Jan,
    Hast du dir einmal Vorta für Borg (https://vorta.borgbase.com/) als GUI angeschaut? Was denkst du darüber?
    Grüsse

    • Jan sagt:

      Hi Frank,

      nein, das sagt mir nichts. Da ich (speziell für diesen Artikel) eher auf einem Server unterwegs bin, fällt hier eine GUI natürlich weg. Mir persönlich reicht hier auch der Zugriff per Kommandozeile. Über Scripts lässt sich dass alles auch gut automatisieren.

      Gruß,
      Jan

  • Daniel sagt:

    Hallo Jan,

    vielen Dank für das ausführliche Tutorial und die Skripte. Ich hab eine Frage zur Strategie.
    Wenn du in dem Beispiel erst die Nextcloud-Ordner mit tar komprimierst (über das nextcloud-backup Skript) und dann diese Archive mit Borg sicherst, ist doch der Vorteil des Deduplizierens dahin, oder verstehe ich dein Beispiel falsch?

    Viele Grüße,
    Daniel

    • Jan sagt:

      Hallo Daniel,

      genau das dachte ich ursprünglich auch, da ja z.B. die Sicherung (das Archiv) des NC-Datenverzeichnisses sich ja immer ändert.
      Borg sichert das jedoch nicht Datei-weise, sondern Block-weise. Daher funktioniert in diesem Szenario die Deduplizierung ausgesprochen gut. Ansonsten hätte ich das an meinen eigenen Cloud-Instanzen schon längst gemerkt, wenn die Backups hier „explodiert“ wären.

      Gruß,
      Jan

  • Tom sagt:

    Hallo Jan,

    ich bin dabei meine Backups auf BorgBackup umzustellen.
    Habe bisher RSnapshot verwendet (dies wird aber nicht mehr so richtig gewartet).

    Dazu habe ich eine Frage:
    Warum sicherst du die NC-Daten zuerst in einen Temp-Ordner um sie dann mit BorgBackup zu sichern ?

    Ich würde meine NC-Database über ein Script zwischensichern und BorgBackup direkt auf /var/www/nextcloud laufen lassen.

    LG
    Tom

    • Jan sagt:

      Hi Tom,

      man muss NC nicht separat sichern, das Daten-Verzeichnis kann auch einfach Teil des Borg Backups sein (wenn die DB separat gesichert wird).
      Warum ich das etwas anders mache, hat folgende Gründe:

      • Bei NC bilden DB, Daten- und Datei-Verzeichnis immer eine Einheit. Darum sollten diese immer zusammen gesichert werden.
      • Wenn diese Bestandteile separat gesichert werden: Wie stellst du diese im Extremfall wieder schnell her? Weil man sich das dann aus den verschiedensten Teilen des Backups zusammen suchen muss, dürfte dies länger dauern, als einfach nur ein Restore-Script aufzurufen (siehe hier).
      • Für kleinere Cloud-instanzen vielleicht nicht so wichtig, aber durch das separate Backup der NC wird die Zeit minimiert, in der NC im Maintenance-Mode bleibt und somit nicht erreichbar ist (weil eben nicht gewartet werden muss, bis Borg Backup durchgelaufen ist). Dies kann besonders für größere Cloud-Instanzen wichtig sein, wo die Verfügbarkeit eine große Rolle spielt und evtl. per Borg auch noch viele andere Daten neben NC gesichert werden müssen.

      Aus diesen Gründen sichere ich lieber alles separat und schalte das dann alles möglichst schnell wieder „online“.

      Gruß,
      Jan

  • Tom sagt:

    Hallo Jan,

    bin gerade dabei, auch mithilfe deiner Anleitung, meinen Server auf BorgBackup-Sicherungen umzustellen.

    Dabei sind mir zwei Sachen aufgefallen :
    – localBackupDir hast du in borgBackupDirs und bei „borg create“ angegeben
    – du empfiehlst mit rsync ein borgbackup-Repository zu clonen. Das wird in der Borg-Doku nicht empfohlen weil man sich damit evtl. Festplatten-Datenfehler von der Repo holt. Stattdessen wird empfohlen ein zweites Borg-Repo anzulegen.

    Gruss
    Tom

    • Jan sagt:

      Hallo Tom,

      bei Punkt 1 hast du recht, das habe ich gleich angepasst (auch im Git-Repo). Danke für den Hinweis!
      Bei Punkt 2 muss man sich überlegen, was der Zweck dieser Kopie (bzw. dem zweiten Backup-Repo) ist. In meinem Fall ist das nur eine zusätzliche Absicherung, falls die Platte mit dem originalen Repo mal ausfallen sollte. Wenn natürlich mit dem Borg-Repo (Platte 1) was schief gehen sollte, dann sind diese Sachen auch in der Kopie enthalten. Das ist aber eine bewusste Entscheidung.

      Gruß,
      Jan

  • Tom sagt:

    Hallo Jan,

    mir ist jetzt bei meinen Backups nach deiner Anleitung folgendes aufgefallen :

    Dein Script NextcloudBackup.sh sichert immer in einem Unterverzeichnis (Zeitstempel), z.B.

    … /nextcloud/20200403_030006/nextcloud-db.sql
    … /nextcloud/20200404_030001/nextcloud-db.sql

    Ich denke nicht, dass hier die Deduplizierung funktioniert !
    Borg diff liefert dann z.B. 4GB removed und 4GB added.

    Ich denke, man muss in diesem Fall NextcloudBackup.sh anpassen so dass es nicht in ein Zeistempel-Unterverzeichnis sichert !

    Gruss
    Tom

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.