MySQL Backup Und Wiederherstellung Mit mysql-zrm Auf Debian Sarge - Seite 4

6 Überprüfen Sie Ihre Backups

Jetzt wollen wir die Integrität unseres Backup-Sets dailyrun überprüfen. Wir können es so machen:

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

Die Ausgabe sollte so 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, es ist nichts Ernstes.)

Als nächstes wollen wir ein bestimmtes Backup innerhalb unseres Backup-Sets dailyrun überprüfen. Zuerst führen wir 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 sehen kannst, gibt es vier Backups in unserem Backup-Set dailyrun. Wir wollen das letzte überprüfen, das sich im Verzeichnis /var/lib/mysql-zrm/dailyrun/20060926202404 befindet. So können wir es machen:

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

Die Ausgabe sollte so aussehen:

| Use of uninitialized value in concatenation (.) or string at /usr/bin/mysql-zrm line 1305. INFO: mysql-zrm-version INFO: Verification successful |

7 Datenwiederherstellung

Angenommen, unsere Datenbank ist abgestürzt und wir haben Daten verloren. So können wir unsere Daten aus unseren MySQL-Backups wiederherstellen. Zuerst führen wir 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 wollen aus unserem neuesten Backup wiederherstellen, das sich in /var/lib/mysql-zrm/dailyrun/20060926202404 befindet:

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

Die Ausgabe sieht so 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, aber der MySQL-Server wurde heruntergefahren. Daher müssen wir ihn jetzt starten:

/etc/init.d/mysql start

Wenn du deine Backups im logischen Format anstelle des Rohformats erstellt hast, kannst du deine Daten auch so wiederherstellen.

8 Mehrere Backup-Richtlinien

Bis jetzt hatten wir eine globale Konfiguration in /etc/mysql-zrm/mysql-zrm.conf, die für alle unsere Backup-Sets galt. Angenommen, wir haben ein Backup-Set osCommerce für unsere osCommerce-Datenbank, ein weiteres Backup-Set vBulletin für unsere vBulletin-Datenbank usw.

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

Jedes Backup-Set hat sein eigenes Unterverzeichnis im Verzeichnis /etc/mysql-zrm, z.B. hat das Backup-Set osCommerce das Verzeichnis /etc/mysql-zrm/osCommerce. Jedes Mal, wenn mysql-zrm ausgeführt wird, überprüft es zuerst die globale Konfiguration in /etc/mysql-zrm/mysql-zrm.conf und dann das Verzeichnis des aktuellen Backup-Sets nach der Datei mysql-zrm.conf, deren Einstellungen die globalen Einstellungen in /etc/mysql-zrm/mysql-zrm.conf überschreiben. Z.B. wenn das aktuelle Backup-Set osCommerce ist, würde mysql-zrm zuerst die Konfiguration aus /etc/mysql-zrm/mysql-zrm.conf lesen und danach die Konfiguration aus /etc/mysql-zrm/osCommerce/mysql-zrm.conf.

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

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

| databases=osCommerce |

9 Entfernen Alter Backups

Wenn du in deiner mysql-zrm-Konfiguration keine Aufbewahrungsrichtlinie festgelegt hast, werden die MySQL-Backups für immer aufbewahrt, was bedeutet, dass deine Festplatte im Laufe der Zeit voll wird. Du kannst alte Backups einfach entfernen, indem du das Backup-Verzeichnis löschst. Wenn du beispielsweise ein Backup in /var/lib/mysql-zrm/dailyrun/20060926195831 hast und es nicht mehr benötigst, kannst du es so löschen:

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

10 Protokoll

mysql-zrm protokolliert in die Protokolldatei /var/log/mysql-zrm/mysql-zrm.log.