Dieses Tutorial ist VALID.

Bitte lies Dir den Disclaimer durch, bevor Du eine Anleitung umsetzt...

Haftungsausschluss / Disclaimer

Backups auf dem Server

Save early, save often!

Dieser berühmte Spruch von Al Lowe aus der Larry Laffer Serie versinnbildlicht schön die Thematik: Lieber ein Backup zu viel, als eins zu wenig. Lieber doppelt gesichert, als gar nicht.

Aber wie machen wir das am Besten, ohne dass es zu lästig wird?

Mit ein paar kleinen Backup Scripts ;)

Backup – was und wohin?

Generell haben wir unsere Web-Projekte, die es zu sichern gilt. Und da gibt es pro Projekt meistens zwei Sachen: Die Datenbank und unsere Nutzerdaten. Gut, die Anwendung als Solche natürlich auch noch, aber die können wir schnell und einfach aus den Containern herauszaubern, die ist nicht so wichtig.

Und daneben haben wir noch unser Host-System: Das „root“-Verzeichnis, in dem alle unsere Docker-Instruktionen abgelegt sind. „etc“ mit der Konfiguration des Betriebssystems. Auch ganz interessant: Das „log“ Verzeichnis mit unseren System-Logs.

Wenn wir das alles vernünftig gesichert bekommen, kann eigentlich so viel schon nicht mehr schief gehen.
Also: Let’s fetz!

Skripts

Im Endeffekt mach ich mir vier Skrips für „nur Datenbank“, „nur www“, „Systembackup inkl. www und db“ und dann noch ein Skript, das alle drei hintereinander ausführt. Das ist ganz simpler, kruder Standard. Keine „Logik“, keine Versionierung oder inkrementelle Sicherung. Jedes Mal ein komplettes Vollbackup. Aber für unserer einfachen Anwendungsfelder sollte es diese Lösung tun. Und ja, ich hab schon einige Male die Systeme aus den Backups wiederhergestellt – sie funktionieren also tatsächlich :)

Zur Namensgebung: Ich füge noch den Namen des Servers in die Backup-Dateien ein (hier beispielsweise „xps“). Das ist natürlich erst dann interessant, wenn Du auch mehrere Server hast und die Backup-Dateien nebeneinander speichern möchtest. Oder für mehr Übersicht… Schaden kanns nicht, aber wenn Du Deine Dateien ohne Server-Prefix haben möchtest, dann lass ihn einfach weg.

Datenbank Backup

nano ~/backup-db.sh

#!/bin/bash
mysqldump -h 127.0.0.1 -A | bzip2 -zf > /var/backup/mysql_xps.sql.bz2
mysqldump -h 127.0.0.1 mysql | bzip2 -zf > /var/backup/mysql-only_xps.sql.bz2
#
mysqldump -h 127.0.0.1 matomo | bzip2 -zf > /var/backup/matomo.sql.bz2
mysqldump -h 127.0.0.1 nextcloud | bzip2 -zf > /var/backup/nextcloud.sql.bz2
mysqldump -h 127.0.0.1 wp_data | bzip2 -zf > /var/backup/wp_data.sql.bz2

Hier machen wir uns nun zu Nutze, dass wir eine „Zentraldatenbank“ laufen lassen, deren Container an den Host gekoppelt ist. Wir können somit nämlich einfach vom Host aus per „mysqldump“ auf den Server zugreifen (über -h 127.0.0.1 – also den Loopback) und damit einzelne Datenbanken wegsichern.

Im zweiten Schritt „pipen“ wir (mittels „|“) die Ausgabe von mysqldump durch den Komprimierer „bzip2“. „z und f“ bewirken, dass wir auch wirklich komprimieren, was durch bzip2 durchläuft.

Im dritten Schritt geben wir den Datenstrom dann in einer Datei aus (>) [Dateiname]. „.sql.bz2“ wähle ich als Endung, damit wir wissen, dass es sich um eine SQL-Datei handelt (also ein Datenbank-Backup) und bz2 weist darauf hin, dass die Datei komprimiert ist. Und gerade bei der Matomo-Datenbank schiebt bzip2 da ganz schön was zusammen. So wird auf meinem Live-System die 650M große Datenbank gleich auf 95M komprimiert.

Eine Ausnahme ist die erste Sicherung: Statt dem Datenbanknamen steht hier ein „-A“, was schlicht „Alle“ bedeutet und sämtliche Datenbanken von MariaDB in eine Datei ausleitet.

Kommt später eine neue Anwendung wie zum Beispiel eine neue WordPress Seite dazu, häng ich einfach eine neue Zeile mit der Datenbank und einem Backup-Namen an. Das gilt auch für das „www“-Backup Skript!

Web Backup

nano ~/backup-www.sh

#!/bin/bash
tar -cjpf /var/backup/matomo.tar.bz2 /var/www/matomo
tar -cjpf /var/backup/nextcloud.tar.bz2 /var/www/nextcloud
tar -cjpf /var/backup/wordpress.tar.bz2 /var/www/wordpress

Zum Sichern der Anwendungen und Anwendungsdaten benutze ich das gute alte „tar“. Die Optionen bedeuten

  • c – legt ein neues Archiv an
  • j – das Archiv wird mit bzip2 gepackt
  • p – Zugriffsrechte mit sichern (!!!)
  • f – das Archiv in eine Datei speichern, die gleich danach angegeben wird

Das Archiv landet dann direkt in /var/backup mit dem jeweiligen Dateinamen und der Endung .tar.bz2 – analog zu den Datenbank-Backup-Dateien.

Hinten steht dann die Quelle (verwirrt ein wenig, weil es gegen den „Fluss“ geschrieben ist). Als Quelle nehme ich das Wurzelverzeichnis der Anwendung direkt unterhalb von /var/www. Das hat den Vorteil, dass beim Entpacken auch wieder ein Verzeichnis z.B. „wordpress“ erstellt wird und nicht alle Dateien einzeln direkt im Ziel landen.

System Backup

nano ~/backup.sh

#!/bin/bash
echo ""
echo "Erstellung des Verzeichnisses im Backup-Ordner"
mkdir /var/backup/xps_$(date +"%Y-%m-%d")
echo "Geschafft, Bereit für Backup..."
echo ""
echo "Beginne mit dem Backup von ROOT"
tar -cjpf /var/backup/xps_$(date +"%Y-%m-%d")/root.tar.bz2 /root
echo "OK."
echo ""
echo "Beginne mit dem Backup von ETC und der Crontab"
tar -cjpf /var/backup/xps_$(date +"%Y-%m-%d")/etc.tar.bz2 /etc
crontab -l > /var/backup/xps_$(date +"%Y-%m-%d")/crontab.txt
echo "OK."
echo ""
echo "Beginne mit dem Backup der LOGS"
tar -cjpf /var/backup/xps_$(date +"%Y-%m-%d")/logs.tar.bz2 /var/log
echo "OK."
echo ""
echo "Beginne mit dem Backup von VAR-WWW"
time tar -cjpf /var/backup/xps_$(date +"%Y-%m-%d")/var_www.tar.bz2 /var/www
echo "OK."
echo ""
echo "Backup aller Datenbanken von MariaDB"
time mysqldump -h 127.0.0.1 -A | bzip2 -zf > /var/backup/xps_$(date +"%Y-%m-%d")/mysql_xps.sql.bz2
echo "OK."
echo ""
echo "FERTIG!"
echo "======="
echo ""

Das backup.sh Skript erstellt in /var/backup ein Verzeichnis mit dem aktuellen Jahr, Monat und Tag im Namen. Die Anweisung hinter dem „Dollar“-Zeichen ist dafür verantwortlich, dass das Verzeichnis dann zum Beispiel „xps_2020-01-29“ heißt.

Während ich mit dem Datenbank- und Anwendungdatei-Skript die Ausgabe jedesmal überschreibe, erzeuge ich hier ein Unterverzeichnis mit dem jeweiligen Sicherungsdatum, um im Zweifel mehrere Sicherungen zu haben, die weiter zurückreichen.

Ansonsten kennen wir die Instruktionen schon aus den beiden anderen Skripten. Wir sichern hier die Verzeichnisse „/root“, „/etc“, „/var/log“ und „/var/www“. Dazu noch alle Datenbanken.

Der „time“ Befehl bei /var/www und dem mysqldump schreibt uns nach der Sicherung, wie lange der Vorgang gedauert hat. Das ist manchmal ganz gut, wenn es größere Blöcke sind, um beim nächsten Mal einschätzen zu können, wie viele Kaffee wir in der Zeit trinken können ^^

Neu ist hier das Sichern der Crontab, da diese sonst nirgends erfasst wird. „crontab -l“ „listet“ den Inhalt der Datei auf. Und den schreiben wir dann als Datei weg.

Alles zusammen

nano ~/backup-all.sh

~/backup-db.sh && ~/backup-www.sh && ~/backup.sh

Die „backup-all.sh“ führt einfach nacheinander das Skript zum Sichern der Datenbanken, der Anwendungen und des kompletten Systems aus.

Backup ausführen

chmod 700 ~/backup*

~/backup-all.sh

Mittels chmod müssen wir einmalig vor dem ersten Start die Skripte „ausführbar“ (7 – lesen, schreiben und ausführen) machen. Dabei reduziere ich den Zugriff darauf gleich auf den „root“-Benutzer: 7-0-0 / Benutzer-Gruppe-Alle. root (7) – Gruppe (0) – Alle (0). 0 = Kein Zugriff…

Haben wir das erledigt, starten wir das Backup gleich mal an und schauen dann mittels

ls -la /var/backup

nach, ob die Dateien und Verzeichnisse wie gewünscht angelegt und erstellt worden sind.

Backup automatisieren mit CRON

Auf einem Server, auf dem nicht viel los ist – und wenn man moralisch gefestigt genug ist, das nicht zu vergessen – kann man die Skripte von Hand ausführen, wenn sich etwas wichtiges geändert hat. Oder im Begriff ist, sich zu ändern, und man vorher gerne ein Backup hätte. Nachher ist es zu spät :)

Für etwas mehr Komfort sorgt und auch eher urlaubstauglich ist aber die Variante über CRON. Da kümmert sich dann der Host um die Datensicherung…

crontab -e

## Jeden Montag um 01:44 Uhr die DATENBANKEN sichern (ausleiten aus MariaDB)
44 01 * * 1     /root/backup-db.sh > /dev/null 2>&1
## Jeden Montag um 03:35 Uhr die WEBSEITEN sichern (/var/www)
35 03 * * 1     /root/backup-www.sh > /dev/null 2>&1

Aber das darf jeder nach eigenem Ermessen so einstellen, wie er es braucht oder für nötig hält. Täglich, wöchtentlich, zwei Mal pro Woche oder alle 14 Tage – Du entscheidest…

Dateien „Off-Site“ sichern / herunterladen

Wir machen hier ein sogenanntes „On-Site“ Backup. Die Backups liegen also auf unserem Server, der auch die Anwendungen hält. Das kann man machen, wenn es Backups sind, die man vor Änderungen anfertigt. Aber „sicher“ ist man damit nicht, weil: Ist der Server weg, sind die Anwendungen weg und es sind auch alle unsere Backups futsch. Sehr Suboptimal…

Die einfachste Lösung in dem Fall ist, dass wir uns nach dem Anfertigen der Backups mit Filezilla auf unseren Server verbinden und die Backup-Dateien auf unseren Rechner herunterladen. Dann haben wir ein „Off-Site“ Backup.

Rücksichern

Der Ernstfall ist eingetreten: Irgendwas ist putt. Hai nun, was tun?

Haben wir die Backup-Datei noch auf unserer Maschine, kopieren wir die ins „root“ – nur zur Sicherheit.
Ansonsten per Filezilla verbinden und hochladen.

Die Syntax zum Entpacken lautet dann:

### für die Datenbankdateien
bzip2 -d datei.bz2

### für die "tar"-Archive
tar xjf datei.tar.bz2

Die Datenbank lesen wir folgendermaßen ins System ein:

mysql -h 127.0.0.1 -u nextcloud -p nextcloud < nextcloud.sql

-u [Datenbankbenutzer] | -p [Datenbankname] < [SQL-Datei]
Es folgt eine Passwortabfrage (nicht das root-PW von MariaDB, sondern das Passwort der Datenbankanwendung!) und die Datenbank wird zurückgesichert.

Das „tar“ Archiv entpackt sich unterhalb von „root“ in „var/www/[Anwendung]“. Von dort aus verschieben wir es mittels „mv“ einfach nach /var/www.

Vorbereitung

Bitte üb das Prozedere wenigstens einmal auf einem „Spielserver“ oder mit einer Anwendung, auf die es nicht ankommt.

Sollte der Ernstfall eintreten und Du machst das dann unter Druck zum allerersten Mal, hast Du sonst genau so viel Schweiß auf der Stirn, wie ich seinerzeit. Aber Du besitzt hier wenigstens einen schönen Plan mit allen Befehlen, den ich damals nicht hatte ^^

Fazit

Backup ist kein Hexenwerk. Es ist nicht schwer und per CRON müssen wir uns auch nicht dauernd dazu zwingen und vergessen es nicht.

Umso wichtiger ist, dass wir es wirklich umsetzen und wenigstens ein Mal die ganze Maschine wegsichern. Ausfall, „menschliches Versagen“ oder der nächste Virenbefall ist dann nicht mehr ganz so schrecklich, als die Vorstellung, noch mal alles direkt von „Null“ aus aufsetzen zu müssen…

Anzeige *

4 Kommentare zu „Backups auf dem Server“

  1. Coole Sache. Ich verwende dein Backup Script. Lassen sich beispielsweise alte und nicht mehr relevante Backup Dateien automatisiert nach einem bestimmten Zeitraum wieder entfernen?

    Danke dir!

    1. Peter Fiedler

      Ich bin an der Stelle kein Freund von Automatismen. Aber ja, das geht über CRON.
      Wenn ich ein wenig Zeit hab und wieder Daheim am Rechner sitze, schicke ich Dir den Befehl, den Du dann auf Deine Gegebenheiten anpassen kannst.

      1. Peter Fiedler

        crontab -e
        # Jeden Tag um 05:15 Uhr LÖSCHEN von allen Backups in /var/backup, die älter als 30 Tage sind.
        15 05 * * * /usr/bin/find /var/backup/*.* -mtime +30 -exec rm {} \; > /dev/null 2>&1

Kommentar verfassen

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

Verwendung
von Cookies

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen zu Cookies erhalten Sie in unserer Datenschutzerklärung.

Scroll to Top