VServer Backup für Webanwendungen und Datenbanken

(Last Updated On: 16. November 2015)

Backup von Daten und Datenbanktabellen

Auch wenn Sie in regelmäßigen Abständen ein Komplettbackup des System hmachen, ersetzt dies nicht ein Backup der Datenbestände und der Datenbanken, die Sie für Ihre WEbsites verwenden. Ich zeige Ihnen, wie Sie mit Hilfe von cron zu einer bestimmten Tageszeit ein Backup davon durchführen.

Mit dem Daemon crond ist es möglich, zeitgesteuert zu regelmäßigen Abständen wiederkehrende Shell-Skripte auszuführen. Dabei können Sie gurndsätzlich mehrere Skripte ineinander verschachteln. Als erstes werden wir die Skripte schreiben, mit denen der Server solche Backups durchführt

 

Erzeugen eines SQL Dumps

das folgende Beispiel zeigt einen Dump aus einer MySQL-Datenbank. Backup-Techniken für andere Datenbankmangaementsysteme zeige ich Ihnen in diesem Post.

Als erstes müssen Sie die Daten aus der Datenbank des mysqld als Textdatei speichern. Diese Textdatei kann anschließend bie einem Widereinspielen des Backups vom mysqld eingelesen werden. Die TExtdatei enthält dabei nichts anderes als bloße SQL Befehle zum Erstellen und Füllen von Tabellen, so dass sämtliche Daten neu eingespielt werden, wenn Sie das Backup zurückspielen.

Als erstes müssen Sie den Standort der mysqldump-Binary auf Ihrem Linux-System finden. das geht über das Kommando

which mysqldump
/usr/bin/mysqldump

Mit dieser binary können wir jetzt eine Befehlszeile im Folgendne Format schreiben, um einen Dump zu erzeugen

<Pfad zur mysql> -u<root-Benuztername (meist root)> -p<Passwort des root> --all-databases > <Pfad der neuen Textdatei>
#Beispiel
/usr/bin/mysqldump -uroot -pmypass --all-databases > /root/Backups/databasedump.sql

Sie sollten zusätzlich zu einem all-databases backup noch ein Backup jeder einzlenen Datenbank machen. Denn wenn sie später auf mehreren Servern unterschiedliche Datenbanken einspielen wollen, ist es so leichter, die backups voneiandner zu trennen. Sie sollten aber dennoch nicht auf ein all-databases-Backup verzichten, damit Sie hier immer in einem einzigen File ein GEsamtbakcup haben.

Um eine bestimmte Datenbank zu sichern, geben Sie den Befehl wie im folgenden Beispiel ein

/usr/bin/mysqldump -uroot -pmypass --databases db1 > /root/Backups/dump.sql

In diesem Beispiel sichern wir die datenbank mit dem Namen db1 in die Datei dump.sql.

Diese Argumente zum Sichern der Datenbanken schreiben Sie jetzt in eine Textdatei mit der Endung .sh am Ende. Erzeugne Sie beispeilswiese im /root-Verzeichnis eine Datei Backup.sh und schreiben dort die von Ihnen benötigten mysql-Backup-Zeilen hinein.

Jetzt müssen wir sicherstellen, dass dieses Backup regelmäßig durchgeführt wird.

Dazu editieren wir die Datei /etc/crontab und erstellen dort eine Zeile im Foramt

* <Tagesstunde zu der das Backup durchgeführt werden soll> * * * root /root/Backup.sh
# Beispiel: wir wollen, dass jeden Tag um 2 Uhr nachts, wenn am wenigsten Besucher da sind, ein Backup durchgeführt wird
* 2 * * * root /root/Backup.sh

jetzt wird jeden Tag um 2 Uhr ein Backup unserer mySQL-Datenbanken durchgeführt. Aber wir haben noch ein Problem: Jedesmal wird das Backup des vorherigen Tages überschrieben. Das wollen wir natürlch nicht unbedingt, weil es durchaus sinn macht, den Datenbestand über mehrere Tage hinweg zu behalten. Deswegen lassen wir das Skript bei jedem durchlauf an den Dateinamen das aktuelle Datum anhängen, so dass wir für jeden Tag eine extra Datei haben. Dazu fügen wir im Dateinamen databasedump.sql unseres Backups einen kleinen platzhalter ein. Wir ändern den Dateinamen zu databasdump_$(date +%ym%d).sql. Jetzt wird an databasedump nach einem Unterstrich das Datum angefügt.

Dadurch eröffnet sich uns jedoch ein neues Problem. Nach etwa drei Monaten haben Sie beispielsweise 90 verschiedene Backups – für jeden Tag eines. Es empfiehlt sich grundsätzlich Backups ab einem bestimmten Alter zu löschen. Mit folgender Kommandozeile beispielsweise ist es sehr einfach möglich, alle Backup zu löschen die älter als 10 Tage sind

find /path/to/files* -mtime +10 -exec rm { } \;

hierbei ist das Leerzeichen zwichen den gechweiften Klammern wichtig!

Speichern der Daten auf dem Webspace

Nun müssen wir noch die Daten der WEbsite selbst, also die statischen Seiten, Bilder, Videos, Skripte usw. sichern. Das erledigen wir ebenfalls zunächst intern auf unserem Server. Wir editieren die Datei Backup.sh und fügen folgendes an:

mkdir /root/Backups/Websitedaten_$(date +%y%m%d)
cp -rpf <Ordner zur Website (meist /var/www) oder /var/www/vhosts>/* /root/Backups/Websitedaten_$(date +%y%m%d)/

In diesem Skript erstellen wir erst einen Ordner Websitedaten_<aktuelles Datum> und kopieren dann die Daten aus dem Ordner unserer Website in diesen neu erstellten Ordner. Mit dem * und dem Parameter -r stellen wir sicher, dass alle Dateien unterhalb dieses Ordners kopiert werden. Mit -p stellen wir sicher, dass auch die Dateiattribute mitübernommen werden und mit -f würden wir gegebenenfalls vorhandene Dateien ohne Nachfrage überschreiben, was verhindert, dass das skript stecken bleibt.

Diese Zeilen müssen wir gegebenenfalls wiederholen, wenn wir auf dem SErver mehrere Websiten haben.

Anders sieht die Situation aus, wenn sie nicht direkt zugriff auf den webserver haben, sondern sich die Dateien von einem FTP-Zugang holen müssen. Hierbei müssen Sie das Skript auf einem anderen System, wo das Backup landen soll, ausführen. Die Files holen Sie sich dann über wget

wget -m ftp://username:password@ip.of.host

Speichern der E-Mails

Natürlich haben wir auf unserer Webanwendung oft auch einen E-Mail-Verkehr eingerichtet. Oft ist es notwendig, auch die E-Mails mitzusichern. Meist wird hierzu die Lösung postfix verwendet. dieser speichert die E-Mails meistens in den Ordnern /var/mail/<username> oder /var/spool/mail/<username> oder auch /var/spool/postfix. Wenn Ihr das Parallels Plesk Panel installiert habt, werden die Daten unter /var/qmail/mailnames gespeichert. Diese Dateien können wir ebenfalls wie beim Speichern der Daten in einen neuen Ordner packen und mit cp -rpf kopieren

Packen der ganzen Daten

Nun haben wir sowohl von der Datenbank, den Websitedaten und von den E-Mails Backups erzeugt. Aber wir sind noch nicht über dem Berg – denn die Daten liegen immer noch auf dem Server. wir haben uns zwar jetzt durch einen Datenverlust durch beispielsweise versehentliches löschen in der Administrationsoberfläche des Servers geschützt, da die Administrationsoberfläche oft nur die originaldaten in den entsprechenden Ordnern löscht. aber wenn der V-Server an sich abraucht, gehackt wird oder was auch immer, sind die Daten trotzdem futsch. Wir müssen die Daten also auf einen anderen Rechner übertragen – dazu kommen wir später. Jetzt wollen wir erstmal sicherstellen, dass die Daten möglichst klein sind, damit sie schneller übertragen werden können. Aus diesem Grund erstellen wir ein .tar.gz-Archiv. Das geht mit folgendem Befehl

tar -czf /root/Backups/Backup_$(date +%y%m%d).tar.gz /root/Backups/databasedump_$(date +%y%m%d).sql /root/Backups/Websitedaten_$(date +%y%m%d)/ /root/Backups/Mailverkehr_$(date +%y%m%d)/

Mit diesem Befehl archivieren und komprimieren wir den MySQL-Dump, die Webistedaten und den Mailverkehr in eine einzige Datei.

Da wir nun eine .tar.gz mit den Inhalten haben, können wir die ungepackten Daten löschen

rm /root/Backups/databasedump_$(date +%y%m%d).sql
rm -rf /root/Backups/Websitedaten_$(date +%y%m%d)/
rm -rf /root/Backups/Mailverkehr_$(date +$y%m%d)/

Übertragen der Daten

wir sollten die Daten danach natürlich übertragen. Es bietet sich dazu an, ein System zu verwenden, welches garantiert zur selben Zeit ebenfalls online ist – beispielsweise etwa ein anderer VSErver oder ein Network Attached Storage Gehäuse bei euch zu Hause, welches über DynDNS erreichbar ist.

Von diesem entfernten System brauchen wir einen SSH-Zugang mit Username und Passwort. Danach können wir die Datne mit Hilfe von SCP übertragen.

scp /root/backups/Backups_$(date +%y%m%d).tar.gz <username dessen SSH Zugang wir haben>@<DNS / FQDN des entfernten Rechners>:<Pfad auf dem anderen Rechner wo wir das Backup hin haben wollen>/Backups_$(date +%y%m%d).tar.gz 
#Beispiel
scp /root/backups/Backups_$(date +%y%m%d).tar.gz root@dafrk-backup.no-ip.org:/root/Backups/Backups_$(date +%y%m%d).tar.gz

Automatisches Autorisieren am entfernten server innerhalb des Skripts

Einen Haken hat die Sache aber noch: es ist nicht möglich, dem Tool SCP bereits im Voraus ein Passwort mitzuteilen. Das Skript würde in diesem punkt hängen bleiben, da es nun nach einem Passowrt für den User gefragt wird. Dieses Problem müssen wir mit Hifle von Public Key Authentication umgehen. Damit das funktioniert, muss auf dem entfernten Rechner ein Public Key von unserem V-Server eingetragen  und der private key im ssh-agent unseres V-Servers geladen sein. In diesem Post beschreibe ich, wie beides funktioniert. Wenn wir das konfiguriert haben, können wir scp in unserem aktuellen Login ohne Passworteingabe nutzen. Ein Problem haben wir aber noch: das Skript läuft nicht in unserem aktuellen Login ab, sondern in einer extra shell, die durch den crond bei Skriptaufruf gestartet wird. Wir müssen also sicherstellen, dass der private key zum entfernten System bei jedem Bashaufruf automatisch in der dort benutzten shell aufgerufen wird. Das geht mit dem Tool expect

Variante 1: Expect

Als erste smüssen wir feststellen, ob expect bereits auf unserem System vorhanden ist

which expect

wenn nichts kommt, installieren wir expect nach

apt-get install expect

geht das nicht, müssen wir die Repositories von apt-get erst updaten über

apt-get update

dann müsste die installation gehen.

Jetzt löschen wir in der backup.sh alles unterhalb des tar befehls und geben darunte rein

file=Backup_$(date +%y%m%d).tar.gz
export file
./spawn.sh

Jetzt erstellen wir im selben ordner eine Datei spawn.sh mit chmod +x und folgendem inhalt:

#!/usr/bin/expect -f
spawn scp /root/Backups/$env(file) <user>@<hostname>:/<Pfad wo das backup hinkopiert werden soll>/
expect "Enter passphrase for /root/.ssh/id_rsa:"
send "<Passphrase>\n";
interact

Zur Erklärung: wir nutzen das Tool expect, um mit der Passwortabfrage zu interagieren, in einem extra skript, das wir im Skript Backup.sh afurufen, nachdem die .tar.gz-Datei erstellt wurde. Da wir auf die Variable $date nicht innerhalb von spawn.sh zugreifen können, wenden wir ein paar variablentricks an, damit wir trotzdem auf den dateinamen der .tar.gz-datei kommen. Jetzt funktioniert alles normalerweise alles.

Variante 2: keychain

Wenn diese Methode für Sie nicht funktioniert, gibt es eine andere Methode. Dazu müssne Sie ein Tool namens keychain installieren. Damit können Sie aber nicht das erstamlige Hinzufü+gen des PÜrivate Keys nach einem Server-Reboot automatisieren. Stattdessen müssen Sie bei jedem Server-Reboot sich erst einmalig manuell mit ssh-agent und ssh-add darum kümmern, dass der private kye hinzugefügt wurde. Danach kümmert sich keychain darum, dass der private Key in allen darauf folgenden neu aufgebauten SSh-Sitzungen neu geladen wird – auch, wenn Sie ein Skript ausführen. Das heißt nach einmaligem eingeben der Passphrase wird ihr skript solange durchlaufen, bis Sie den Server irgendwann mal wieder neu starten müssne. Damit diese Methode funktioniert, muss wie gesagt keychain installiert sien und Sie müssen folgendes in Ihre ~/.bash_profile eintragen:

eval 'keychain --eval id_rsa'

sie können dann testen, ob keychain funktioniert, indem Sie sich erstmal mittels ssh-agent/ssh-add den key laden, sich dann abmelden und eine neue SSH-Sitzung aufbauen. Sie sollten dann beim Login eine farbig markierte Meldung von keychain erhalten, die _Ihnen mittetilt, dass der private Schlüssel auch in dieser neuen Sitzung erhalten geblieben ist.

Variante 3: Private Key ohne Passwort und Backup-User

Als weitere Alternative zu expect oder keychain können Sie auch auf der NAS einen User erstellen, dessen privater Schlüssel kein Passwort bekommt, und diesem User allre Rechte nehmen bis auf das Lesen und Schreiben in dem Verzeichnis, in welchem die Backups reinkommen. Sie erstellen dann auf dem SErver einen privaten Schlüssel ohne Kennwort und geben den öffentlichen Schlüsel davon in die authorized_keys des Backup-Users auf der NAS. Sie können sich dann üpber das Kommando scp mit diesem User einloggen und müssen im Skript dann kein Passwort eingeben – deshalb läuft das Skript dann auch sauber durch. Sollte jemand den privaten Schlüssel des Backup-Users stehlen, kann er nichts an Ihrem System kaputt machen, außer vielleicht die bestehenden Backups löschen und lesen. Wenn Sie auch dieses Risiko eliminieren wollen, müssen Sie den umgekehrten Weg gehen: sie erstellen einen Backup-User auf dem zu sichernden Server und erstellen auf der NAS einen privaten Schlüssel ohne Passwort und laden dessen öffentlichen Schlüssel auf den Server hoch. Sie erzeugen das Backup auf dem VServer und speichern es beispeilsweise im Home_Verzeichnis des Backup-Users, holen es sich aber über ein Skript auf der NAS ab. Da das Backup auf der NAs liegt, man sich aber auf dem NAS nicht ohne Kennwort einloggen kann, sondern nur auf dem Server, ist das Backup sicher vor fremdzugriff – und auf dem VServer wiederum kann ein angreifer als Backup-User nichts anfangen, weil er für nichts anderes Rechte hat. Löscht der eindringling die  zwischengelagerten Backups afu dem VServer, bleibt Ihnen noch das eigentliche Backup auf der NAS.

Wenn Sie diese Methode verwenden, müssen Sie sicherstellen, dass bei jedem Start der privat ssh-key in der NAS geladen wird. Fügen Sie daher in der Datei .bash_profile, .bashrc oder .profile folgendes hinzu:

if [ -z "$SSH_AUTH_SOCK" ] ; then
  eval `ssh-agent -s`
  ssh-add
fi

Nun wird bei jedem öffnen der  bash der key geladen. Wenn ihre NAS eine andere Konsole als die bash öffnet, funktioniert nur ein eintrag in der .profile-Datei

Hinweis:  Das tool scp muss nicht nur auf dem zu sichernden Server, sondern auch auf dem entfernt stehenden Server / dem NAS stehen, auf den das Backup übertragen wird, und zwar im selben Pfad! Das bewerkstelligen Sie mittels einem symbolischen Link, also einer Art Verknüpfung, die das Tool scp auf den selben Pfad verknüpft, in dem es auf Ihrem zu sichernden VServer ist.

Mit den folgenden Befehlen berwerkstelligen Sie das für eine Synology Diskstation mit installiertem IPKG

#download des openssh Paketes in das Home-Verzeichnis
ipkg install zutils
wget http://ipkg.nslu2-linux.org/feeds/optware/syno-x07/cross/unstable/openssh_5.5p1-1_arm.ipk
#entpacken der datei data.tar.gz aus dem openssh paket tar -xvzf openssh_5.5p1-1_arm.ipk ./data.tar.gz #Entpacken der SCP Binary aus dem Paket data.tar.gz in dessen Ordner /opt/bin
 tar -xvzf data.tar.gz ./opt/bin/openssh-scp #Umbenennen des Paketes und verschieben in den Ordner /opt/bin: mv openssh-scp /opt/binscp #Erstellen des Links zum Pfad auf dem VServer (usr/bin/scp): ln -s /opt/bin/scp /usr/bin/scp

Nun können sie von Ihrem VServer auf eine Synology Diskstation kopieren, sofern die Datei Backup.sh mit chmod ausführbar gemacht wurde.

 

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

DaFRK

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

Das könnte Dich auch interessieren...

1 Antwort

  1. 20. April 2015

    […] ich in diesem Post bereits […]

Kommentar verfassen

This site uses Akismet to reduce spam. Learn how your comment data is processed.