Einführung

Dass Backups (vor allem im geschäftlichen Umfeld) elementar wichtig sind, ist sicherlich unumstritten. Wer ESX Server in sein Unternehmen einführt, sollte seine bisherige Backupstrategie jedoch neu überdenken. Für den ESX Server von VMware existieren derzeit drei Backupvarianten, die in den folgenden Abschnitten beleuchtet werden und ihre eigenen Vor- und Nachteile mit sich bringen.

Klassisches Backup

Vor allem viele kleinere Unternehmen setzen bei der Sicherung ihrer virtuellen Maschinen noch auf die Backupstrategie, die bei klassischen (physikalischen) Servern zum Einsatz kommt.

So wird auf jeder virtuellen Maschine ein Agent installiert, über den ein zentraler Backupserver Zugriff auf die Maschine bekommt und Daten sichern kann. Der Vorteil besteht darin, dass diese Methode ausgereift ist und sich Administratoren mit dieser Technik auskennen. Zudem können einzelne Dateien oder auch nur Bestandteile einer Datei (z.B. eine einzelne E-Mail oder ein einzelner Datensatz aus einer Datenbank) problemlos wiederhergestellt werden.

Der Nachteil dieser Variante besteht jedoch darin, dass die virtuellen Maschinen selbst nicht gesichert werden können. So ist im Fall einer fehlerhaften virtuellen Maschine der entsprechende Server neu aufzusetzen und einzurichten. Erst dann können die gesicherten Daten wieder zurückgespielt werden – ein zeitaufwändiges Verfahren. Hinzu kommt, dass die Last auf dem ESX Server bei mehreren gleichzeitigen Backups drastisch ansteigen und somit die Leistungsfähigkeit aller Systeme auf dem jeweiligen ESX Server beeinträchtigen kann.

VMware Consolidated Backup

Einen Schritt weiter geht das VMware Consolidated Backup. Es handelt sich dabei nicht um eine eigenständige Backuplösung, sondern um eine Sammlung aus Kommandozeilentools. VMware Consolidated Backup kann dabei wahlweise auf einem physikalischen Server oder als virtuelle Maschine genutzt werden. Die Sicherung erfolgt in den folgenden Schritten:

• VMware Consolidated Backup erstellt einen Snapshot der virtuellen Maschine.
• Dieser Snapshot wird eingebunden und für die eigentliche Sicherungssoftware bereitgestellt.
• Die Sicherungssoftware kann nun den Snapshot der virtuellen Maschine und/oder einzelne Daten der virtuellen Maschine sichern.
• VMware Consolidated Backup hängt den Snapshot aus und löscht ihn.

Damit VMware Consolidated Backup konsistente Snapshots erstellen kann, wird die jeweilige virtuelle Maschine entweder kurz angehalten oder es wird der Volume Shadow Copy Service bei Windows Servern genutzt.

Der Einsatz des VMware Consolidated Backup hat folgende Vorteile:

• es muss nur ein Backupagent installiert werden,
• es können komplette virtuelle Maschinen und/oder nur einzelne Daten gesichert werden und
• virtuelle Maschinen können im Notfall komplett wiederhergestellt werden.

Das Verfahren hat jedoch auch ein paar Nachteile:

• Die Wiederherstellung ist umständlich, da man sich manuell um das Einspielen der virtuellen Maschinen oder Dateien kümmern muss.
• Es ist ein Zugriff auf die ESX Service-Konsole erforderlich.
• Es wird ein hohe Daten- und eventuell auch Netzwerklast erzeugt (unperformant).

Derzeit ist VMware Consolidated Backup noch Teil von vSphere. In der kommenden Version soll das Produkt jedoch aufgegeben werden, da inzwischen weitaus bessere Lösungen für die Sicherung der virtuellen Maschinen existieren. Diese Lösungen greifen auf das vStorage API zurück und erhalten neben Zugriff auf die virtuellen Maschinen auch zahlreiche Informationen über die virtuellen Maschinen selbst.

Backup über das vStorage API

Neben den beiden bereits vorgestellten Sicherungsvarianten existieren noch Backuplösungen, die auf das bereits angesprochene vStorage API zugreifen. Die einfachste Variante hierbei ist, den ESX Server zunächst einen Snapshot der virtuellen Maschinen erstellen zu lassen und diesen Snapshot danach zu sichern (Vollbackup). Allerdings hat diese Variante gegenüber der Sicherung über das VMware Consolidated Backup nur den Vorteil, dass fehlerhafte Server einfach zurückgespielt werden können.

Lohnenswert wird die Verwendung der vStorage API erst dann, wenn die Backuplösung das so genannte Change Block Tracking verwendet. Hierbei werden nur Datenblöcke gesichert, die sich seit einem bestimmten Zeitpunkt verändert haben.
Dadurch können inkrementelle und differentielle Datensicherungen realisiert, der Datenverkehr verringert und die Performance erhöht werden.

Das Change Block Tracking ist zudem Grundlage für Backuplösungen, die Near Continous Data Protection umsetzen. Hierbei werden veränderte Daten in kurzen Abständen gesichert. Im Vergleich zu Echtzeit-Backuplösungen hat diese Technik eine höhere Performance. Im schlimmsten Fall hat man jedoch auch eine etwas niedrigere Aktualität der Daten.

Die Vorteile der auf Change Block Tracking basierenden Sicherungen sind folgende:

• Die Sicherung ist effizient.
• Es wird nur ein geringerer Datenverkehr erzeugt.
• Komplette virtuelle Maschinen werden gesichert.
• Die Wiederherstellung kompletter Maschinen ist einfach.

Allerdings ergibt sich bei dieser Backupvariante folgendes Problem: häufig müssen nur einzelne Dateien wiederhergestellt werden. Die Backuplösung muss also auf die Dateien in der Sicherung zugreifen und diese in das jeweilige Zielsystem übertragen können. Hierzu wird die entsprechende virtuelle Maschine meist in einem isolierten Netzwerksegment gestartet und die Daten werden dann von der Backuplösung auf das Zielsystem übertragen. Diese Vorgehensweise beherrschen jedoch alle gängigen Backuplösungen.

Schwieriger gestaltet es sich, wenn nur einzelne Bestandteile einer Datei (wie z.B. eine einzelne E-Mail oder ein Datensatz einer Datenbank) wiederhergestellt werden müssen. Hier ist es noch erforderlich, die entsprechende Sicherung manuell
einzubinden, die Daten selber ausfindig zu machen und auf das Zielsystem zu übertragen.

Für bestimmte Systeme könnte also durchaus der kombinierte Einsatz einer klassischen Backuplösung (die entsprechende Möglichkeiten für z.B. den E-Mail- oder Datenbank-Server bereitstellt) mit einer auf der vStorage API basierenden Backuplösung sinnvoll sein (sofern letztere nicht das angesprochene Problem löst).

Backup Lösungen

Für klassische Backups existieren verschiedenste Backup-Lösungen. Bekannt sind hier zum Beispiel CA ARCserve Backup, Symantec Backup Exec oder Acronis ABR. Zudem gibt es viele kostenlose Tools, wie z.B. Microsofts Robocopy für Windows oder rsnapshot für Linux. Im Windows-Bereich werden diese kostenlosen Tools allerdings selten eingesetzt, während z.B. rsnapshot in Linux-Umgebungen recht häufig zum Einsatz kommt.

Beim Einsatz des VMware Consolidated Backup können die meisten dieser klassischen Backup-Lösungen weiterhin eingesetzt werden.

Sobald es an die Sicherung der virtuellen Maschinen über das vStorage API geht, setzen Unternehmen bevorzugt auf eine der von VMware unterstützte Backuplösungen.

Quellen

• VMware – VMware vStorage-APIs: Zentrale Backups virtueller Maschinen
• VMware – VMware: Automatisierung von Daten-Backup und -Recovery für Hochverfügbarkeit
• WindowsPro – Vergleich: Backup-Strategien für VMware ESX

MySQL-Datenbank sichern

MySQL-Datenbanken sichert man am Besten mit dem Kommandozeilen-Tool mysqldump, welches standardmäßig mit dem MySQL-Server mitinstalliert wird. Die Syntax zur Sicherung einer Datenbank lautet wie folgt:

mysqldump -u<Benutzername> -p<Passwort> <Datenbank> > <SQL-Datei>

Beispiel:

mysqldump –uroot –pgeheim techspread > /backup/techspread.sql

Natürlich bietet der mysqldump Befehl noch etliche weitere Parameter, in den meisten Fällen ist diese Variante jedoch vollkommen ausreichend.

MySQL-Datenbank wiederherstellen

Die Syntax zum Wiederherstellen der Datenbank lautet wie folgt:

mysql -u<Benutzername> –p<Passwort> <Datenbank> < <SQL-Datei>

Beispiel:

mysql –uroot –pgeheim techspread < /backup/techspread.sql

MySQL-Datenbank via Netzwerk sichern

Wer noch einen Schritt weiter gehen möchte, kann auch MySQL-Server per Netzwerk/Internet sichern. Dazu muss dem mysqldump-Befehl lediglich ein weiterer Parameter mit auf den Weg gegeben werden. Der angegebene Benutzer muss natürlich auch Zugriff via Netzwerk erhalten (was in der Standardeinstellung nicht der Fall ist):

mysqldump -h <Server> -u<Benutzername> -p<Passwort> <Datenbank> > <SQL-Datei>

Beispiel:

mysqldump -h techspread.de -uroot -pgeheim techspread > /backup/techspread.sql

MySQL-Backup-Script

Damit man sich nicht manuell um die Sicherung jeder einzelnen Datenbank kümmern muss, habe ich folgendes Script geschrieben:

#! /bin/bash

BACKUPDIR=<Sicherungsordner>
USERNAME=<Benutzername>
PASSWORD=<Passwort>

if [ -d $BACKUPDIR ];
then
	rm -r $BACKUPDIR
fi

mkdir $BACKUPDIR
cd $BACKUPDIR

DATABASES=`mysql -u$USERNAME -p$PASSWORD -Bse 'show databases'`
for DATABASE in $DATABASES;
do
	if [ "$DATABASE" != "information_schema" ];
	then
		mysqldump -u$USERNAME -p$PASSWORD $DATABASE > ${DATABASE}.sql
	fi
done

Schlussbemerkung

Auf Basis der vorgestellten Befehle und dem Script kann man sich noch weitaus mächtigere Scripte schreiben. So habe ich das Script auf Arbeit so eingerichtet, dass man über Parameter an das Script das Sicherungsverzeichnis, den Server, den Benutzernamen und das Passwort übergibt. Dadurch kann man komfortabel eine zentrale Sicherung für mehrere MySQL-Server einrichten.

http://www.youtube.com/watch?v=0NooomvpIQs]

Die perfekte Backup-Lösung muss ich mir wohl noch zusammenstellen, aber rsnapshot und rdiff-backup gehen schon sehr in die richtige Richtung.

Denn nach der Neuinstallation war immernoch mein Sicherungsordner /backup vorhanden. Verwundert habe ich den Support angerufen und gefragt was Sache ist. Der gute Herr Wachert (den habe ich immer am Telefon ) hat mir dann erzählt, dass es ein undokumentiertes Feature ist, dass der Ordner /backup bei einer Neuinstallation vorhanden bleibt.

Es war also reiner Zufall, dass ich mir für meine Sicherung mal den Ordner /backup eingerichtet habe, denn dieser Ordner ist standardmäßig nicht vorhanden. Nach der Neuinstallation konnte ich mir es so also sparen, mehrere hundert MB über meine DSL-Leitung wieder auf den Server zu schaufeln.

Dennoch würde ich immer eine lokale Sicherung durchführen. Sicher ist sicher

Zunächst einmal musst du phpMyAdmin aufrufen. Auf der linken Seite wählst du dann die entsprechende Datenbank aus. Oben findest du dann den Menüpunkt Exportieren. Die Voreinstellungen für die Datensicherung sind eigentlich immer vollkommen in Ordnung, sodass man unten rechts einfach auf OK klicken muss, um die SQL-Datei dann abspeichern zu können.

Das Backup kann man auch ehr einfach wieder einspielen. Dazu wählst du die Datenbank aus und löschst zunächst alle Tabellen aus dieser. Danach gehst du oben auf Importieren, wählst die zuvor gespeicherte SQL-Datei aus und klickst unten rechts auf OK. Nach kurzer Zeit solltest du eine Bestätigung über den erfolgreichen Import erhalten. Das Löschen aller Tabellen ist deshalb nötig, da du sonst ggf. alle Datensätze doppelt in der Datenbank haben würdest, was ja unerwünscht ist.

Falls du noch Fragen zu der Datensicherung haben solltest, frag lieber dreimal nach, statt am Ende deine Daten in das Datennirvana zu schicken!

P.S.: Wer seine Datenbanken lieber über die Kommandozeile sichert, sollte sich meinen Artikel MySQL-Datensicherung “Best Practice” anschauen.

Nach einer kurzen Installation von Gbridge gelangt man zur Anmeldemaske, bei der ihr einen GoogleMail- oder Google Apps-Account eintragen müsst:

Wenn ihr euch eingeloggt habt, kommt ihr zum Hauptfenster der Anwendung. Hier könnt ihr Freunde hinzufügen, mit ihnen chatten, Dateifreigaben, Backups und Synchronisationen einrichten sowie VNC-Sessions starten.

Ich habe mir lediglich einen kurzen GoogleMail-Account zum Antesten der Oberfläche erstellt, aber es gibt ja genug Google-Fanboys da draußen, die bestimmt auf so ein Programm scharf sind Wer mehr über das Programm erfahren will, sollte sich die oben verlinkte hak5-Folge einziehen. Ab Minute 9 zeigt euch Shannon, wie ihr das Programm installiert und was ihr damit wie machen können.

Installation von rsnapshot

Auf dem Backup-Server muss zunächst das Paket rsnapshot installiert werden. Bei apt-basierten Linux-Distributionen kann man es wie folgt installieren:

aptitude install rsnapshot

Sofern man auch entfernte Server via Netzwerk sichern möchte, müssen auf diesen SSH und rsync installiert werden:

aptitude install ssh rsync

Einrichtung der entfernten Server

Wenn ihr Server über das Netzwerk sichern möchtet, müsst ihr zunächst eine schlüsselbasierte Authentifizierung einrichten. Hierzu sollte der Benutzer root verwendet werden, da für den Zugriff auf viele Daten root-Rechte erforderlich sind.

Einrichtung von rsnapshot

rsnapshot wird über die Textdatei /etc/rsnapshot.conf konfiguriert. Zunächst passt man den Ordner an, in den die Backups geschrieben werden sollen:

snapshot_root /backup/

Danach definiert man beliebige Backup-Intervalle. Die Syntax hierfür lautet:

interval <Bezeichnung> <Anzahl aufzuhebender Backups>

So kann man z.B. den Backup-Intervall longterm anlegen, bei dem 30 Sicherungen aufbewahrt werden sollen:

interval longterm 30

Später beim Ausführen von rsnapshot muss der Bezeichner eines solchen Intervals als Parameter übergeben werden.

Am Ende der Konfigurationsdatei richtet man die zu sichernden Verzeichnisse ein. Um zum Beispiel das Verzeichnis /home des lokalen Servers zu sichern, fügt man folgende Zeile hinzu:

backup /home/ localhost/

Weitaus interessanter ist aber die Sicherung via Netzwerk. Hierzu trägt man zum Beispiel folgendes ein, um den Ordner /etc des Linux-Rechners somehost zu sichern:

backup root@somehost:/etc/ somehost/

Zum Schluss muss noch mindestens ein Cronjob für die Ausführung der Sicherung angelegt werden. Diesen definiert man in der Datei /etc/crontab. Soll z.B. der Backup-Intervall longterm immer um 00:00 Uhr durchgeführt werden, muss man folgende Zeile hinzufügen:

0 0 * * * root rsnapshot longterm

Bei der Einrichtung eines cronjobs hilft dir diese ausführliche Anleitung zum Erstellen von cronjobs.

Konfiguration und Backup testen

Um die Konfigurationsdatei auf Fehler hin zu überprüfen, gibst du den Befehl

rsnapshot configtest

ein. Etwaige Fehler wird dir das Programm sofort anzeigen. Danach solltest du ein ersten Backup starten und überprüfen, ob die Sicherung richtig funktioniert. Für den oben genannten Backup-Intervall longterm gibst du z.B. folgendes ein:

rsnapshot longterm

Schlussbemerkung

Ich habe in diesem Kapitel nur die wichtigsten Konfigurationen beschrieben. Die Konfigurationsdatei bietet viele weitere Einstellungen, die sehr gut dokumentiert sind.