MySQL Backup und Wiederherstellung mit mysql-zrm auf Debian Linux - Seite 2

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

0 Kommentar(e)

Zum Posten von Kommentaren bitte