MySQL Backup und Wiederherstellung mit mysql-zrm auf Debian Linux

Version 1.0
Author: Falko Timme


Diese Anleitung veranschaulicht, wie Du Deine MySQL Datenbank mit mysql-zrm auf einem Debian Sarge System sichern und wiederherstellen kannst. mysql-zrm steht für Zmanda Recovery Manager für MySQL und ist ein neues Tool, das Dich vollständige Logical oder Raw Backups Deiner Datenbank erstellen lässt (ungeachtet Deines Storage Engines und Deiner MySQL Konfiguration). Weiterhin erstellt es Berichte über Backups, prüft die Vollständigkeit der Backups und stellt Deine Datenbank wieder her. Es sendet Meldungen über den Backup Status via E-Mail und Du kannst mehrere Bauckup Policies (basierend auf Deinen Anwendungen und Zeit-basiert (z.B. täglich, wöchentlich, etc.)) implementieren.

Ich möchte an dieser Stelle darauf hinweisen, dass dies nicht der einzige Weg ist, ein solches System einzurichten. Es gibt viele Möglichkeiten dieses Ziel zu erreichen - dies ist der Weg, den ich gewählt habe. Ich übernehme keine Garantie, dass dies auch bei Dir funktioniert!

1 Vorbemerkung

mysql-zrm funktioniert mit MySQL 4.1 und späteren Versionen. Ich gehe also davon aus, dass Du einen MySQL Server auf Deinem Debian Sarge System bereits installiert hast, z.B. wie folgt:

apt-get install mysql-client-4.1 mysql-common-4.1 mysql-server-4.1

Damit wird außerdem das Paket libdbd-mysql-perl installiert, das mysql-zrm benötigt, da mysql-zrm in Perl geschrieben ist.

2 Installation

Zmanda hat ein rpm Paket von mysql-zrm für rpm-basierte Distributionen wie Fedora, RedHat, SuSE, CentOS, etc. auf den Markt gebracht, jedoch kein Paket für Debian Sarge. Also müssen wir das mysql-zrm Quell-Paket von http://www.zmanda.com/downloads.html runter laden. Wähle die Stable Version aus (als diese Anleitung verfasst wurde, war es Version 1.0.3) und lade sie in Dein /tmp Verzeichnis:

cd /tmp
wget http://www.zmanda.com/downloads/community/ZRM-MySQL/1.0.3/Source/MySQL-zrm-1.0.3.tar.gz

Als Nächstes entpacken wir die Quellen und gehen in das Quell-Verzeichnis:

tar xvfz MySQL-zrm-1.0.3.tar.gz
cd MySQL-zrm-1.0.3

Leider besagen die Installationsinstruktionen in der INSTALL Datei lediglich, dass Du das mysql-zrm rpm Paket installieren kannst, wenn Du mit einer rpm-basierten Distribution arbeitest und nicht mehr. Auch auf der Zmanda Webseite ist ein Installationsskript und Installationsinstruktionen für das Quell-Paket nicht zu finden, also musste ich selbst herausfinden, wie ich mysql-zrm auf meinem Debian Sarge System installieren kann. Folgendes habe ich unternommen:

chown root:root *
mv mysql-zrm /usr/bin
mv mysql-zrm-reporter /usr/bin
mv mysql-zrm-scheduler /usr/bin
gzip mysql-zrm.1
mv mysql-zrm.1.gz /usr/share/man/man1
gzip mysql-zrm.conf.5
mv mysql-zrm.conf.5.gz /usr/share/man/man5
gzip mysql-zrm-reporter.1
mv mysql-zrm-reporter.1.gz /usr/share/man/man1
gzip mysql-zrm-reporter.conf.5
mv mysql-zrm-reporter.conf.5.gz /usr/share/man/man5
gzip mysql-zrm-scheduler.1
mv mysql-zrm-scheduler.1.gz /usr/share/man/man1
mkdir /etc/mysql-zrm
mv *.conf /etc/mysql-zrm
mkdir -p /usr/lib/mysql-zrm/Data/Report/Plugin
mv Report.pm /usr/lib/mysql-zrm/Data
mv Base.pm /usr/lib/mysql-zrm/Data/Report
mv *.pm /usr/lib/mysql-zrm/Data/Report/Plugin
mkdir /var/log/mysql-zrm
gzip AUTHORS
gzip COPYING
gzip INSTALL
gzip README
mkdir /usr/share/doc/MySQL-zrm
mv * /usr/share/doc/MySQL-zrm
mkdir /var/lib/mysql-zrm
touch /etc/mysql-zrm/mysql-zrm-release

Das war's. Die ausführbaren Dateien wurden nach /usr/bin verschoben, die Konfigurationsdateien befinden sich in /etc/mysql-zrm und wir haben sogar Man Pages für unsere ausführbare Dateien (mysql-zrm, mysql-zrm-reporter und mysql-zrm-scheduler). Wenn Du Dir über den Gebrauch der ausführbaren Dateien nicht im Klaren bist, kannst Du dies ausführen

man mysql-zrm

man mysql-zrm-reporter

man mysql-zrm-scheduler


3 Basis-Konfiguration

Die Haupt-Konfigurationsdatei ist etc/mysql-zrm/mysql-zrm.conf. In dieser Datei müssen wir zumindest den MySQL-Backup Benutzer (ein MySQL Benutzer mit allen Privilegien, wie Root) und sein Passwort festlegen:

vi /etc/mysql-zrm/mysql-zrm.conf


user="root"
password="yourrootsqlpassword"
Wenn nichts anderes angegeben ist, übernimmt mysql-zrm Standardwerte für alle anderen Einstellungen. Mit dieser Konfiguration würde mysql-zrm Backups von allen Datenbanken, in einem Raw Format, vornehmen; diese Konfiguration würde die Backups für immer aufbewahren und keine E-Mail-Benachrichtigungen senden.

Raw Format bedeutet, dass die Datenbank als Binärdateien gesichert werden, die im Falle von Datenverlusten zurück in die Datenbank kopiert werden können. Es können jedoch Probleme auftauchen, wenn Du diese Dateien zwischen verschiedenen MySQL Versionen hin und her kopierst.
Das Pendant zum Raw Format ist das Logical Format, das Textdateien mit einem einfachen SQL Dump Deiner Datenbanken erstellt. Dieses SQL Dumps können in fast allen MySQL Versionen wieder hergestellt werden. Du könntest dies sogar manuell vornehmen, wie hier gezeigt wird: http://www.howtoforge.com/faq/6_4_en.html
Wenn Benachrichtigunen an Deine E-Mail Adresse example@example.com geschickt werden sollen, füge dies /etc/mysql-zrm/mysql-zrm.conf hinzu:

vi /etc/mysql-zrm/mysql-zrm.conf


mailto="example@example.com"
Wenn Du Backups im Logical Format vornehmen Backups sieben Tage lang aufbewahren möchtest (anstatt für immer), füge diese Zeilen /etc/mysql-zrm/mysql-zrm.conf hinzu:

vi /etc/mysql-zrm/mysql-zrm.conf


# allowed values for backup-mode are "raw" and "logical"
backup-mode=logical retention-policy=7D
Wenn Du ein Backup eines MySQL Replication Slaves erstellen möchtest, füge diese Zeile /etc/mysql-zrm/mysql-zrm.conf hinzu:

vi /etc/mysql-zrm/mysql-zrm.conf


replication=1
Damit werden Dateien gesichert, die für einen MySQL Replication Slave wichtig sind.

Wenn Du nur die Datenbanken exampledb und anotherexampledb anstelle aller Datenbanken sichern möchtest füge dies /etc/mysql-zrm/mysql-zrm.conf hinzu:

vi /etc/mysql-zrm/mysql-zrm.conf


databases=exampledb anotherexampledb
Wenn Du nur Backups der Tabellen text, user und page aus der exampledb Datenbank benötigst, füge dies /etc/mysql-zrm/mysql-zrm.conf hinzu:

vi /etc/mysql-zrm/mysql-zrm.conf


tables=text user page
database="exampledb"
Bitte beachte: Die Einstellungen all-databases, databases und tables/database sind schließen sich gegenseiteig aus!

In der Standarddatei /etc/mysql-zrm/mysql-zrm.conf sind viele Kommentare enthalten, die alle Konfigurationsoptionen erklären. Ich verwende diese Einstellungen fürs Erste:

vi /etc/mysql-zrm/mysql-zrm.conf


user="root"
password="yourrootsqlpassword" mailto="example@example.com" backup-mode=logical retention-policy=7D # all-databases=1 is optional, as it is the default setting all-databases=1

4 Beispiel-Backup

Mit mysql-zrm kannst Du mehrere Backups, namens backup sets, aufrechterhalten, z.B. ein tägliches Backup, ein wöchentliches Backup, ein Backup für Deine osCommerce Datenbank, ein Backup für Deine vBulletin Datenbank, etc.

Lass uns nun unser erstes Backup im Backup Set dailyrun erstellen:

mysql-zrm-scheduler --now --backup-set dailyrun --backup-level 0

Damit werden automatisch alle Datenbanken im /var/lib/mysql-zrm/dailyrun Verzeichnis gesichert und das Verzeichnis /etc/mysql-zrm/dailyrun wird erstellt. --backup-level 0 bedeutet: ein vollständiges Backup vornehmen (man kan auch inkrementelle Backups vornehmen (--backup-level 1), aber das werde ich später noch einmal aufgreifen - fürs Erste nehmen wir nur vollständige Backups vor).

Wenn Du E-Mail Benachrichtigunen aktiviert hast, solltest Du jetzt eine E-Mail erhalten haben, in der der Status des Backups angezeigt wird. Du kannst aber auch einen Bericht über den Backup Status in der Kommandozeile erzeugen, nämlich wie folgt:

mysql-zrm-reporter --where backup-set=dailyrun --show backup-status-info

Die Ausgabe wird wie folgt aussehen:
          backup_set  backup_date                             backup_level  backup_status         comment
---------------------------------------------------------------------------------------------------------------------- dailyrun Tue 26 Sep 2006 07:57:47 PM CEST 0 Backup succeeded ----
Du kannst noche ein paar andere Berichte mit folgenden Befehlen generieren:

mysql-zrm-reporter --where backup-set=dailyrun --show backup-method-info
mysql-zrm-reporter --where backup-set=dailyrun --show backup-retention-info
mysql-zrm-reporter --where backup-set=dailyrun --show backup-performance-info
mysql-zrm-reporter --where backup-set=dailyrun --show restore-full-info
mysql-zrm-reporter --where backup-set=dailyrun --show restore-incr-info
mysql-zrm-reporter --where backup-set=dailyrun --show replication-info

Probiere jeden aus um herauszufinden, welche Informationen sie liefern.

Nun möchten wir ein tägliches und wöchentliches Backup erstellen, das vom System automatisch ausgeführt werden soll (d.h. ohne Interaktion von unserer Seite). So können wir diese Backups einrichten:

mysql-zrm-scheduler --add --interval daily --backup-set dailyrun --backup-level 0
mysql-zrm-scheduler --add --interval weekly --backup-set weeklyrun --backup-level 0

(Mit dem zweiten Befehl haben wir ein neues Backup Set namens weeklyrun erstellt.)

Lass uns nun unsere geplanten Backups überprüfen:

mysql-zrm-scheduler --query

Die Ausgabe sieht wie folgt aus:
Logging to /var/log/mysql-zrm/mysql-zrm-scheduler.log
0 3 * * * /usr/bin/mysql-zrm --action backup --destination /var/lib/mysql-zrm --backup-set dailyrun --backup-level 0 0 4 * * * /usr/bin/mysql-zrm --action purge --destination /var/lib/mysql-zrm 0 2 * * 0 /usr/bin/mysql-zrm --action backup --destination /var/lib/mysql-zrm --backup-set weeklyrun --backup-level 0
Wie Du siehst wird das tägliche Backup jeden Tag um 03:00 Uhr und das wöchentliche Backup jeden Sonntag um 02:00 Uhr ausgeführt.

(Übrigens, anstelle von

mysql-zrm-scheduler --query

kannst Du auch dies ausführen

crontab -l

um die gleiche Information zu erhalten.)

Wenn das tägliche Backup zu einer anderen Zeit gestartet werden soll, z.B. 13:35 Uhr, kannst Du Folgendes ausführen:

mysql-zrm-scheduler --add --interval daily --backup-set dailyrun --start 13:35 --backup-level 0

Um ein geplantes Backup aus cron zu entfernen, tust Du Folgendes:

mysql-zrm-scheduler --delete --interval weekly

Damit würde das wöchentliche Backup aus dem cron entfernt werden. Wenn Du das tägliche Backup, das für 13:35 Uhr angelegt ist, entfernen möchtest, führst Du dies aus:

mysql-zrm-scheduler --delete --interval daily --start 13:35

Du kannst aber auch dies ausführen

crontab -e

um Deine cron Jobs zu bearbeiten, was manchmal einfacher ist als die Handhabung von mysql-zrm-scheduler.

5 Benutzerdefinierte Berichte, HTML Berichte

In Kapitel 4 habe ich bereits erwähnt, welche Berichte verfügbar sind. Du kannst aber auch benutzerdefinierte Berichte erstellen, d.h. Du kannst festlegen, welche Spalten/Informationen Du sehen möchtest. Zum Beispiel erzeugt

mysql-zrm-reporter --fields backup-set,backup-date,backup-level,backup-status --where backup-set=dailyrun

einen Bericht für das Backup Set dailyrun, der die Spalten backup-set, backup-date, backup-level und backup-status anzeigt:
          backup_set  backup_date                             backup_level  backup_status
------------------------------------------------------------------------------------------------ dailyrun Tue 26 Sep 2006 07:57:47 PM CEST 0 Backup succeeded dailyrun Tue 26 Sep 2006 07:58:08 PM CEST 0 Backup succeeded dailyrun Tue 26 Sep 2006 07:58:31 PM CEST 0 Backup succeeded dailyrun Tue 26 Sep 2006 08:24:04 PM CEST 0 Backup succeeded
Eine Liste aller Spalten ist hier verfügbar: http://mysqlbackup.zmanda.com/index.php/What_information_can_be_obtained_from_a_backup_report%3F.

mysql-zrm lässt Dich auch HTML Berichte erstellen. Gehen wir mal davon aus, Du hast einen Web Server (z.B. Apache) auf Deinem System mit dem Dokumenten-Root /var/www installiert. Führe nun dies aus

mysql-zrm-reporter --show backup-status-info --where backup-set=dailyrun --type html --output /var/www/backup-status-dailyrun.html

Damit wird die HTML Datei backup-status-dailyrun.html in Deinem /var/www Verzeichnis erstellt, auf das Du nun in Deinem Browser (z.B. http://server1.example.com/backup-status-dailyrun.html) zugreifen kannst:


6 Deine Backups prüfen

Nun möchten wir die Vollständigkeit unseres Backup Sets dailyrun überprüfen. Dies führen wir wie folgt aus:

mysql-zrm --action verify-backup --backup-set dailyrun

Die Ausgabe sollte wie folgt aussehen:
Use of uninitialized value in concatenation (.) or string at /usr/bin/mysql-zrm line 1305.
INFO: mysql-zrm-version INFO: Verification successful
(Du kannst die Warnung in der ersten Zeile ignorieren, das ist nichts Ernstes.)

Als Nächstes möchten wir ein bestimmtes Backup in unserem Backup Set dailyrun überprüfen. Zuerst führen wir dies aus

mysql-zrm-reporter -show restore-full-info --where backup-set=dailyrun

um herauszufinden, welche Backups verfügbar sind:
          backup_set  backup_date                             backup_level  backup_directory
---------------------------------------------------------------------------------------------------------- dailyrun Tue 26 Sep 2006 07:57:47 PM CEST 0 /var/lib/mysql-zrm/dailyrun/20 060926195747 dailyrun Tue 26 Sep 2006 07:58:08 PM CEST 0 /var/lib/mysql-zrm/dailyrun/20 060926195808 dailyrun Tue 26 Sep 2006 07:58:31 PM CEST 0 /var/lib/mysql-zrm/dailyrun/20 060926195831 dailyrun Tue 26 Sep 2006 08:24:04 PM CEST 0 /var/lib/mysql-zrm/dailyrun/20 060926202404
Wie Du siehst, haben wir vier Backups in unserem Backup Set dailyrun. Wir möchten das letzte überprüfen, das sich im  Verzeichnis /var/lib/mysql-zrm/dailyrun/20060926202404 befindet. Dies führen wir wie folgt aus:

mysql-zrm --action verify-backup --backup-set dailyrun --no-quiet --source-directory /var/lib/mysql-zrm/dailyrun/20060926202404

Die Ausgabe sollte wie folgt aussehen:
Use of uninitialized value in concatenation (.) or string at /usr/bin/mysql-zrm line 1305.
INFO: mysql-zrm-version INFO: Verification successful

7 Daten-Wiederherstellung

Gehen wir davon aus, dass unsere Datenbank abgestürzt ist und Daten verloren gegangen sind. So können wir unsere Daten aus unseren MySQL Backups wiederherstellen. Zuerst führen wir dies aus

mysql-zrm-reporter -show restore-full-info --where backup-set=dailyrun

um herauszufinden, welche Backups verfügbar sind:
          backup_set  backup_date                             backup_level  backup_directory
---------------------------------------------------------------------------------------------------------- dailyrun Tue 26 Sep 2006 07:57:47 PM CEST 0 /var/lib/mysql-zrm/dailyrun/20 060926195747 dailyrun Tue 26 Sep 2006 07:58:08 PM CEST 0 /var/lib/mysql-zrm/dailyrun/20 060926195808 dailyrun Tue 26 Sep 2006 07:58:31 PM CEST 0 /var/lib/mysql-zrm/dailyrun/20 060926195831 dailyrun Tue 26 Sep 2006 08:24:04 PM CEST 0 /var/lib/mysql-zrm/dailyrun/20 060926202404
Wir möchten sie von unserem neusten Backup, das sich in /var/lib/mysql-zrm/dailyrun/20060926202404 befindet, wiederherstellen:

mysql-zrm --action restore --backup-set dailyrun --source-directory /var/lib/mysql-zrm/dailyrun/20060926202404

Die Ausgabe sieht wie folgt aus:
Use of uninitialized value in concatenation (.) or string at /usr/bin/mysql-zrm line 1305.
INFO: mysql-zrm-version INFO: Restored database from raw backup: egroupware INFO: Restored database from raw backup: mysql INFO: Restore done in 14 seconds. MySQL server has been shutdown. Please restart after verification.
Die Daten wurden wiederhergestellt, jedoch wurde der MySQL Server runter gefahren. Daher müssen wir ihn nun starten:

/etc/init.d/mysql start

Wenn Du Deine Backups im Logical Format anstelle des Raw Formates erstellt hast, kannst Du Deine Daten auch so wiederherstellen

8 Mehrere Backup Policies

Bis jetzt hatten wir eine globlae Konfiguration in /etc/mysql-zrm/mysql-zrm.conf, die für alle unsere Backup Sets gilt. Lass uns nun davon ausgehen, dass wir ein Backup Set osCommerce für unsere osCommerce Datenbank, ein anderes Backup Set vBulletin für unsere vBulletin Datenank etc. haben.

Es macht keinen Sinn alle unsere MySQL Datenbanken im Backup Set osCommerce zu sichern, da dieses Backup nur die osCommerce Datenbank enthalten sollte, das Gleiche gilt für unseres vBulletin Backup Set. So können wir dieses Problem lösen:

Jedes Backup Set hat sein eigenes Unterverzeichnis im /etc/mysql-zrm Verzeichnis, z.B. hat das Backup Set osCommerce das Verzeichnis /etc/mysql-zrm/osCommerce. Wenn mysql-zrm nun ausgeführt wird, überprüft es zuerst die globale Konfiguration in /etc/mysql-zrm/mysql-zrm.conf und dann das Verzeichnis des derzeitigen Backup Sets für die Datei mysql-zrm.conf, dessen Einstellungen die globalen Einstellungen in /etc/mysql-zrm/mysql-zrm.conf überschreiben. Wenn z.B. das derzeitige Backup Set osCommerce ist, würde mysql-zrm zuerst die Konfiguration von /etc/mysql-zrm/mysql-zrm.conf und danach die Konfiguration von/etc/mysql-zrm/osCommerce/mysql-zrm.conf lesen.

Wenn wir nur die MySQL Datenbank osCommerce im Backup Set osCommerce sichern möchten, fügen wir Folgendes in c/mysql-zrm/osCommerce/mysql-zrm.conf ein:

vi /etc/mysql-zrm/osCommerce/mysql-zrm.conf


databases=osCommerce

9 Entfernen von alten Backups

Wenn Du in Deiner mysql-zrm Konfiguration nicht retention-policy eingestellt hast, werden die MySQL Backups für alle Zeit aufbewahrt, was bedeutet, dass Deine Festplatte ziemlich beladen sein wird. Du kannst alte Backups einfach entfernen, indem Du das Backup Verzeichnis löschst. Wenn Du zum Beispiel ein Backup in /var/lib/mysql-zrm/dailyrun/20060926195831 hast und es nicht mehr brauchst, kannst Du es wie folgt löschen:

rm -fr /var/lib/mysql-zrm/dailyrun/20060926195831


10 Log

mysql-zrm loggt auf die Log-Datei /var/log/mysql-zrm/mysql-zrm.log.


11 Inkrementelle Backups

mysql-zrm kann auch inkrementelle Backups erstellen, jedoch hatte ich damit einige Probleme. Zunächst musste ich MySQL so konfigurieren, dass es seine bin-logs auf /var/lib/mysql schreibt (indem ich /etc/mysql/my.cnf bearbeitet habe), da dies der Ort ist, an dem mysql-zrm sie erwartet. Danach schien

mysql-zrm-scheduler --now --backup-set dailyrun --backup-level 1

zu funktionieren, aber

mysql-zrm --action parse-binlogs --source-directory=/var/lib/mysql --backup-set dailyrun

gab eine Fehlermeldung an:
Use of uninitialized value in concatenation (.) or string at /usr/bin/mysql-zrm line 1305.
INFO: mysql-zrm-version ERROR: cannot open index file /var/lib/mysql/index No such file or directory
Daher denke ich, ist es besser fürs Erste vollständige Backups vorzunehmen anstelle von inkrementellen Backups.

12 Entfernte Backups

Mit mysql-zrm kannst Du auch Backups von entfernten MySQL Servers via Netzwerk erstellen. Das hat allerdings auch einige Probleme verursacht.

12.1 Erster Versuch

Bei meinem ersten Versuch wollte ich ein Backup (im Raw Format) eines MySQL Servers auf einem entfernten SuSE 10.0 System erstellen. Ich habe /etc/mysql-zrm/mysql-zrm.conf bearbeitet und den entfernten Benutzer, das Passwort und den Hostnamen eingefügt, dann habe ich dies ausgeführt

mysql-zrm-scheduler --now --backup-set dailyrun --backup-level 0

Das war das Ergebnis:

Logging to /var/log/mysql-zrm/mysql-zrm-scheduler.log
Use of uninitialized value in concatenation (.) or string at /usr/bin/mysql-zrm line 1305.
INFO: mysql-zrm-version
WARNING: Binary logging is off. Incremental and logical backup will not work.
INFO: backup-set=dailyrun
INFO: backup-date=20060927095528
INFO: backup-date-epoch=1159343728
INFO: mysql-version=4.1.13
INFO: backup-directory=/var/lib/mysql-zrm/dailyrun/20060927095528
INFO: backup-level=0
WARNING: Database test is empty and hence will not be backedup
WARNING: Database tmp is empty and hence will not be backedup
ERROR: Output of command: 'mysqlhotcopy' is
DBI connect(';host=192.168.0.163;mysql_read_default_group=mysqlhotcopy','root',...) failed: Client does not support authentication protocol requested by server; consider upgrading MySQL client at /usr/bin/mysqlhotcopy line 182
ERROR: mysqlhotcopy command did not succeed.
Command used is mysqlhotcopy --quiet --user=root --password=***** --host=192.168.0.163 db_ispconfig mysql "/var/lib/mysql-zrm/dailyrun/20060927095528" > /tmp/4Z75iIAeo5 2>&1
Return value is 65280
INFO: backup-status=Backup failed
INFO: Backup failed
ERROR: /usr/bin/mysql-zrm did not finish successfully

Ich vermute das ist wegen verschiedener MySQL Versionen auf beiden Systemen passiert.

12.2 Zweite Versuch

Beim zweiten Versuch wollte ich ein Backup (wieder im Raw Format) einer MySQL Datenbank auf einem entfernten Debian Sarge Server erstellen. Sowohl das lokale als auch das entfernte System hatten die gleiche MySQL Version. Ich habe dies ausgeführt

mysql-zrm-scheduler --now --backup-set dailyrun --backup-level 0

und erhielt folgende Fehlermeldungen:

Logging to /var/log/mysql-zrm/mysql-zrm-scheduler.log
Use of uninitialized value in concatenation (.) or string at /usr/bin/mysql-zrm line 1305.
INFO: mysql-zrm-version
INFO: backup-set=dailyrun
INFO: backup-date=20060927100653
INFO: backup-date-epoch=1159344413
INFO: mysql-version=4.1.11-Debian_4sarge7-log
INFO: backup-directory=/var/lib/mysql-zrm/dailyrun/20060927100653
INFO: backup-level=0
WARNING: Database test is empty and hence will not be backedup
ERROR: Output of command: 'mysqlhotcopy' is
Cannot open dir '/var/lib/mysql/web34_db1': No such file or directory at /usr/bin/mysqlhotcopy line 293.
ERROR: mysqlhotcopy command did not succeed.
Command used is mysqlhotcopy --quiet --user=root --password=***** --host=192.168.0.110 mysql web34_db1 "/var/lib/mysql-zrm/dailyrun/20060927100653" > /tmp/yxFsViAlbm 2>&1
Return value is 512
INFO: backup-status=Backup failed
INFO: Backup failed
ERROR: /usr/bin/mysql-zrm did not finish successfully

Es schien als würde das Verzeichnis /var/lib/mysql/web34_db1 (web34_db1 ist eine der Datenbanken auf dem entfernten System) auf dem lokalen System fehlen! Also habe ich es angelegt:

mkdir /var/lib/mysql/web34_db1

und habe dies erneut ausgeführt

mysql-zrm-scheduler --now --backup-set dailyrun --backup-level 0

und dieses Mal hat es funktioniert. Allerdings bezweifle ich, dass dies der richtige Weg ist...

12.3 Dritter Versuch

Dieses Mal versuchte ich ein Backup des gleichen entfernten Debian Sarge Systems wie zuvor zu erstellen, allerdings im Logical anstelle des Raw Formates. Ich führte dies aus

mysql-zrm-scheduler --now --backup-set dailyrun --backup-level 0

und erhielt folgende Fehlermeldung:

Logging to /var/log/mysql-zrm/mysql-zrm-scheduler.log
Use of uninitialized value in concatenation (.) or string at /usr/bin/mysql-zrm line 1305.
INFO: mysql-zrm-version
WARNING: Binary logging is off. Incremental and logical backup will not work.
INFO: backup-set=dailyrun
INFO: backup-date=20060927095501
INFO: backup-date-epoch=1159343701
INFO: mysql-version=4.1.13
INFO: backup-directory=/var/lib/mysql-zrm/dailyrun/20060927095501
INFO: backup-level=0
ERROR: Binary logging is off. Logical backup cannot be done
INFO: backup-status=Backup failed
INFO: Backup failed
ERROR: /usr/bin/mysql-zrm did not finish successfully

Jedoch ist das dieses Mal das normale Verhalten, da MySQL für entfernte Logical Backups mit SSL konfiguriert werden muss, wie hier beschrieben wird: http://mysqlbackup.zmanda.com/index.php/Do_I_need_to_make_changes_to_MySQL_database_configuration%3F. Leider haben die Debian Sarge MySQL Pakete keine SSL Unterstützung:

mysqld --ssl --help

060927 12:26:09 [ERROR] mysqld: unknown option '--ssl'

Ich habe mich in die MySQL Kommandozeile eingeloggt:

mysql -u root -p

und dies ausgeführt

SHOW VARIABLES LIKE 'have_openssl';

und das gleiche Ergebnis erhalten:
+---------------+-------+
| Variable_name | Value | +---------------+-------+ | have_openssl | NO | +---------------+-------+ 1 row in set (0.01 sec)
Keine SSL Unterstützung...

13 Links