Backup oder Datensicherung eines root-Servers / vServers / VPS

28 Juni 2017 Ein Kommentar Autor: Jürgen (jdo)

Mein root-Server bei Contabo ist abgesichert, kann in der Zwischenzeit auch Mails schreiben und meine Website läuft auch schon darauf. Da ich mich bei diesem VPS (Virtual Private Server) selbst um das Backup kümmern muss, braucht es einen Plan. Ich habe mir nun einen zurechtgelegt, der in dieser Form schon läuft und möchte diesen teilen. Einleiten möchte ich mit einem Admin-Sprichwort:

Backup ist was für Feiglinge, aber wohl dem, der eins hat!

Ich habe das Backup bereits sehr früh eingerichtet und es so gut wie möglich automatisiert. Der Grund ist, dass bereits alles gesichert wird, was nachfolgend auf dem Server passiert. Immer wenn neue Dateien oder Verzeichnisse hinzukommen, die gesichert werden sollen, passe ich außerdem gleich die Backup Scripte an. Somit wächst die Datensicherung mit der Einrichtung. Mir ist das lieber, da ich dann weniger wahrscheinlich etwas übersehe.

Ein perfektes Backup gibt es wohl nicht. Aber Du kannst Dich angemessen absichern, um nach einem Crash relativ schnell wieder online zu sein. Ich möchte mit diesem Beitrag lediglich Anregungen geben. Wie Du Dein Backup oder Deine Datensicherung im Endeffekt umsetzt, bleibt Dir überlassen.

Bei mir schiebt der Anwender root die Daten vom Server auf eine Online-Festplatte. Damit habe ich am wenigsten Probleme mit den Berechtigungen.

Dokumentiere, was Du gemacht hast

Zu einer guten Backup-Strategie gehören nicht nur Scripte und Sicherungen von Daten und Datenbanken, sondern auch eine gewisse Dokumentation. Du musst damit keinen Literaturpreis gewinnen, solltest Dich aber selbst auskennen.

Persönlich schreibe ich mir Stichpunkte auf und welche Befehle ich bei diesem Schritt verwendet habe. Sollte es Scripte oder relevante Verzeichnisse geben, sind die dort ebenfalls vermerkt. Für die Einrichtung des Logins sieht das bei mir zum Beispiel so aus:

  • root kein SSH erlauben → /etc/ssh/sshd_config
  • fail2ban installieren

Es muss eben für Dich verständlich oder gerade so viel sein, dass Du die Schritte im Notfall nachvollziehen kannst. Hier geht sicherlich auch jeder anders an die Sache heran. Der Punkt ist, dass sich Dokumentation und Backup beim Thema Disaster Recovery (DR) die Hand geben.

In einer Notsituation bist Du froh, wenn Du Dich fokussieren kannst. Je besser die Dokumentation, desto weniger musst Du nachdenken und Du kannst Dich auf andere Sachen konzentrieren.

Daten und Websites sichern

Ich habe eine kleine Online-Festplatte mit 20 GByte, die ich via rsync und SSH ansprechen kann. Mein root-Server bietet zwar 300 GByte Storage, aber die muss ich nicht komplett sichern. Was ich auf die Online-Festplatte sichern werde, sind die Inhalte aus /var/www (Websistes), Datenbanken und /etc (Konfiguration). Dabei kann ich noch einige Cache-Verzeichnisse ausschließen, wie ich hier beschrieben habe.

Den Ordner /etc/ werde ich komplett sichern. Das ist so klein und es ändert sich so wenig daran, dass ich an dieser Stelle keinen Kopfstand machen will. Allerdings mache ich mir die Mühe, täglich eine Zip-Datei mit einem Zeitstempel oder Timestamp erstellen zu lassen und die lege ich auf dem System ab. Brauche ich sie, habe ich sofort Zugriff darauf und muss sie nicht erst von der Online-Festplatte zurück kopieren. Mit dem externen Speicher werden sie natürlich ebenfalls via rsync abgeglichen. Ich hebe diese Backup-Daten dann jeweils 14 Tage auf. Erstellen wir erst einmal eine Datensicherung von /etc/ und machen eine Zip-Datei mit einem Zeitstempel daraus.

/bin/tar czvf /Pfad/zum/Backup-Verzeichnis/etc-$(date +%Y-%m-%d).tar.gz /etc/

Wie Du siehst landen sie in einem von mir festgelegten Backup-Verzeichnis. Den kompletten Ordner synchronisiere ich nachts via Cronjob auf die Online-Festplatte und der dafür zuständige Befehl sieht so aus:

rsync -avuz -e "ssh" /Pfad/zum/Backup-Verzeichnis/* Anwendername@(IP-)Adresse-Online-Festplatte:/Pfad/zum/Ziel/ --delete

Mit einem weiteren Script lösche ich Dateien, die älter als x*24 Stunden sind. Dafür ist dieser Code zuständig. Pass mit dem Code aber auf, denn er löscht ohne weiteres Nachfragen!

/usr/bin/find /Pfad/zum/Backup-Verzeichnis/* -mtime +14 -exec rm {} \;

Bei rsync hilft der Parameter --delete, dass die alten Dateien auf dem externen Speicher ebenfalls gelöscht werden.

Tipp: Die Crontab kannst Du übrigens auch sichern, indem Du den nachfolgenden Befehl ausführst (es wird immer die Crontab des jeweiligen Anwenders gesichert). Ich mache das immer ganz gerne als Teil meiner Dokumentation:

crontab -l > crontab-anwendername.backup

Bald wird auch noch eine auf dem Server Nextcloud laufen. Für den Anfang reicht mir da die kleine Online-Festplatte ebenfalls. Sobald die Daten wachsen, rüste ich die Online-Festplatte nach oder ich sichere meine Daten nur noch auf einen USB-Wechseldatenträger vom Client aus. Das mache ich bereits und somit sind die Daten sowieso schon abgesichert. Nach einem Crash wäre eine Erstsynchronisation fällig. Das ist lästig, aber es wären keine Daten verloren.

Die Datenbanken sichern

Es gibt Tools wie zum Beispiel AutoMySQLBackup, die ein Backup der Datenbanken übernehmen. Das ist in Ordnung, aber ich hantiere für den Anfang lieber ganz banal mit mysqldump. Ich sehe mit AutoMySQLBackup später mal an, wenn alles eingerichtet ist. Ich sichere nur die relevanten Datenbanken, die ich nach einem Crash wieder brauche. Jede Tagessicherung bekommt einen eigenen Zeitstempel. Mein Befehl für das Backup der Datenbank beispiel sieht so aus:

/usr/bin/mysqldump --lock-tables --databases beispiel | gzip > /Pfad/zum/Backup-Verzeichnis/beispiel-$(date +%Y-%m-%d).sql.gz

Brauchst Du auch Anwendername und Passwort (kommt darauf an, wie Du MySQL eingerichtet hast – ich komme in einem späteren Beitrag darauf zurück), dann sind folgende Parameter noch wissenswert.

--user="Anwendername" --password="Passwort"

An dieser Stelle ist das Spiel äquivalent zur Sicherung von /etc/. Ich lasse ein Script laufen, dass den Backup-Ordner jeden Tag nach Dateien durchsucht, die älter als x*24 Stunden sind. Die werden dann gelöscht.

Damit sind alle meine relevanten Daten gesichert, um nach einem Crash wieder auf die Beine zu kommen. Natürlich ist da etwas Handarbeit notwendig, aber länger als einen halben Tag wird das hoffentlich nicht dauern.

Sicherung auf einen lokalen Rechner oder einen Raspberry Pi

Wer weder der Online-Festplatte noch dem Server traut und eine angemessene Internet-Verbindung hat, der kann sich die Daten auch noch ins Wohnzimmer sichern. Nach einer anfänglichen Synchronisation und wenn der Datenzuwachs überschaubar ist, sollte das recht flott gehen. Eigentlich reicht dafür schon ein Raspberry Pi mit einer ausreichend großen SD-Karte oder eben einem externen Datenträger. Es gibt schnuckelige USB-Sticks mit 64 GByte für 21 Euro oder die Variante mit 128 GByte für 46 Euro.

Die nachfolgende Methode funktioniert mit jedem Linux-System oder mit jedem OS, das rsync und SSH zur Verfügung stellt. Das auf Debian basierende Raspbian bietet natürlich ebenfalls rsync und OpenSSH als Tools an. Zunächst einmal stellen wir sicher, dass Du Dich vom Raspberry Pi ohne Passwort auf dem root-Server anmelden kannst.

Hinweis: Ich würde Dir dringend empfehlen, das Standard-Passwort für den Anwender Pi zu ändern oder gar einen eigenen Benutzer für den Zugriff auf den Server anzulegen. Ansonsten hat jeder einfachen Zugriff auf Deinen Server, der mit dem Pi hantieren darf.

Schlüsselpaar erstellen

Zunächst müssen wir auf dem Raspberry Pi ein Schlüsselpaar erstellen.

ssh-keygen -t rsa -b 4096

Das erzeugt einen Schlüssel mit einer Länge von 4096 Bit. Lässt Du die Option -b 4096 weg, dann wird es per Standard ein Schlüssel mit einer Länge von 2048 Bit.

Der Befehl fragt nach, wohin die Schlüssel gelegt werden sollen. Das ist per Standard /home/<nutzer>/.ssh/id_rsa und das ist so auch in Ordnung.

Auf dem Raspberry Pi für das Backup einen Schlüssel erstellen

Auf dem Raspberry Pi für das Backup einen Schlüssel erstellen (Testschlüssel – wurde wieder gelöscht)

Wirst Du nach einem Passwort gefragt, bleibt das leer. Du drückst also zweimal die Eingabetaste. Wir wollen ja kein Passwort eingeben, wenn wir uns mit dem Server verbinden, da sonst die Automatisierung nicht funktioniert. Im Anschluss kopieren wir den Public Key auf den Server:

ssh-copy-id Anwender-auf-Server@(IP-)Adresse-Server

Du wirst gefragt, ob Du Dich sicher mit dem Server verbinden möchtest und das bejahst Du, indem Du yes eintippst und das mit der Eingabetaste bestätigst. Die Prozedur verlangt nun noch das Passwort des Anwenders auf Deinem Server und danach ist der Schlüssel kopiert. Nun kannst Du Dich mit

ssh Anwender-auf-Server@(IP-)Adresse-Server

anmelden und es sollte kein Passwort verlangt werden. Die Schlüssel landen auf dem Server übrigens in einer Datei: /<Pfad>/<zu>/<User-Home>/.ssh/authorized_keys

Dort kannst Du den Schlüssel wieder rauswerfen, sollte sich der Raspberry Pi oder das entsprechende Gerät nicht mehr mit dem Server verbinden dürfen.

Vom Raspberry Pi auf den Server zugreifen

Vom Raspberry Pi auf den Server zugreifen

Ein kleines Backup-Script

Nun schreiben wir uns ein kleines Script, das uns die Daten aus den Backup-Ordnern holt. An dieser Stelle kann es aber mit den Berechtigungen krachen. Nun gibt es drei Möglichkeiten:

  • Du legst Dir einen geheimen Backup-Anwender an, der sich am System via SSH anmelden darf und Zugriff auf die entsprechenden Dateien hat – das müsste aber so etwas wie ein geheimer root-Anwender sein.
  • Du lässt root die Dateien irgendwo auf den Server sichern und gibst dem Backup-Anwender Zugriff darauf. Wenn genug Platz ist, kann das sogar gar nicht schaden, eine Kopie der wichtigen Dateien lokal zu haben.
  • Eine andere Möglichkeit wäre noch, dass Du Dir die Daten einfach von der Online-Festplatte holst.

Ein Raspberry Pi braucht nicht viel Strom und auch das Script könntest Du im Cronjob des Pis nachts laufen lassen und immer eine lokale Kopie haben. Das ist aber für den absoluten Notfall, denn vom Heimnetzwerk nach dem Crash wiederherstellen, kann sich bei langsamen Internet-Verbindungen schon sehr ziehen.

Ich lege nun zum Beispiel eine Datei an, die sich rsync-server.sh nennt und schreibt so einen ähnlichen Code rein, wenn ich in den Ordner /home/pi/backup sichern möchte:

#!/bin/bash
/usr/bin/rsync -avuz anwendername@(IP-)Adresse-Server:/Pfad/zur/Quelle/ /home/pi/backup/ --delete

Das speichere ich ab und mache die Datei noch ausführbar:

chmod +x ./rsync-server.sh

Nun kann ich das Backup manuell laufen lassen:

./rsync-server.sh

und die gewünschten Daten landen in /home/pi/backup. Soll das Backup automatisch ausgeführt werden, dann kannst Du das Script entweder nach /etc/cron.daily/ kopieren oder wenn es zu einer bestimmten Zeit sein soll, legst Du einen neuen Cronjob an:

crontab -e

und dort kommt so eine Zeile rein:

15 3 * * * /Pfad/zum/Scripts/rsync-server.sh >> /dev/null 2>&1

Nun wird jede Nacht um 3:15 Uhr gesichert und keine Log-Datei zugemüllt (>> /dev/null 2>&1)

Endlose Möglichkeiten

Wie Du sicher schon gemerkt hast, sind Deiner Fantasie kaum Grenzen gesetzt, wenn es um das Thema Backup oder Datensicherung geht. Du musst Dir überlegen, wie wichtig welche Daten sind und wie viele Kopien Du haben möchtest.

Ebenso ist wichtig, wo sich die Daten befinden, um sie nach einem Crash so schnell wie möglich wieder auf den Server zu bekommen.

Ein lokales Backup in den eigenen vier Wänden ist sicherlich nicht verkehrt. So etwas mit einem Raspberry Pi aufsetzen kostet nicht die Welt und für den absoluten Notfall ist es bestimmt OK. Auf jeden Fall beruhigt es das Gewissen.

Ich möchte abschließend noch einmal auf die Dokumentation hinweisen, die Dir im Ernstfall viel Zeit spart. Wenn es scheppert, bist Du im Stress und was schriftlich vor Dir liegt, darüber musst Du schon nicht nachdenken.

Nette Pi-Konstellation

Du kannst gerne Deinen Senf zu diesem Beitrag geben: Hier geht es zu den Kommentaren




Schreiben macht durstig! Eine kleine Erfrischung kann daher nie schaden. Wem dieser freie Artikel gefallen hat, der darf mir gerne einen frisch gezapften Hopfen-Tee ausgeben (Paypal - der Spenden-Knopf
)
oder

Bitcoin-Adresse: 1NacVNwcLLePUVv8uSafu5Ykdwh8QyDfgK

Ethereum-Adresse: 0x9cc684575721dc07b629ad5d81b43ab4b992e76e

Verge-Adresse: DJaJtZeW494xhnRJJt19Lnt2R5pz7zRp5A

Ich freue mich über jede noch so kleine Spende. Vielen Dank und Prost!

 
 Alle Kommentare als Feed abonnieren

Ein Kommentar zu “Backup oder Datensicherung eines root-Servers / vServers / VPS”

  1. […] durch den Artikel „Backup oder Datensicherung eines root-Servers / vServers / VPS„von Bitblokes habe ich mir Gedanken gemacht, wie ich meine MySQL-Datenbanken vernünftig und […]

Antworten