Sauvegarde et Récupération MySQL Avec mysql-zrm Sur Debian Sarge - Page 4

6 Vérifiez Vos Sauvegardes

Maintenant, nous voulons vérifier l’intégrité de notre ensemble de sauvegarde dailyrun. Nous pouvons le faire comme ceci :

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

La sortie devrait ressembler à ceci :

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

(Vous pouvez ignorer l’avertissement de la première ligne, ce n’est rien de sérieux.)

Ensuite, nous voulons vérifier une sauvegarde spécifique dans notre ensemble de sauvegarde dailyrun. D’abord, nous exécutons

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

pour découvrir quelles sauvegardes sont disponibles :

| 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 |

Comme vous pouvez le voir, il y a quatre sauvegardes dans notre ensemble de sauvegarde dailyrun. Nous voulons vérifier la dernière qui se trouve dans le répertoire /var/lib/mysql-zrm/dailyrun/20060926202404. Voici comment nous pouvons le faire :

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

La sortie devrait ressembler à ceci :

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

7 Récupération de Données

Supposons que notre base de données ait planté et que nous ayons perdu des données. Voici comment nous pouvons restaurer nos données à partir de nos sauvegardes MySQL. D’abord, nous exécutons

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

pour découvrir quelles sauvegardes sont disponibles :

| 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 |

Nous voulons restaurer à partir de notre dernière sauvegarde qui se trouve dans /var/lib/mysql-zrm/dailyrun/20060926202404 :

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

La sortie ressemble à ceci :

| 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. |

Les données ont été restaurées, mais le serveur MySQL a été arrêté. Par conséquent, nous devons le démarrer maintenant :

/etc/init.d/mysql start

Si vous avez effectué vos sauvegardes au format logique au lieu du format brut, vous pouvez également récupérer vos données comme ceci.

8 Politiques de Sauvegarde Multiples

Jusqu’à présent, nous avions une configuration globale dans /etc/mysql-zrm/mysql-zrm.conf qui s’appliquait à tous nos ensembles de sauvegarde. Maintenant, supposons que nous ayons un ensemble de sauvegarde osCommerce pour notre base de données osCommerce, un autre ensemble de sauvegarde vBulletin pour notre base de données vBulletin, etc.

Il n’est pas logique de sauvegarder toutes nos bases de données MySQL dans l’ensemble de sauvegarde osCommerce car cette sauvegarde ne devrait contenir que la base de données osCommerce, et il en va de même pour notre ensemble de sauvegarde vBulletin. Voici comment nous pouvons résoudre ce problème :

Chaque ensemble de sauvegarde a son propre sous-répertoire dans le répertoire /etc/mysql-zrm, par exemple, l’ensemble de sauvegarde osCommerce a le répertoire /etc/mysql-zrm/osCommerce. Maintenant, chaque fois que mysql-zrm est exécuté, il vérifie d’abord la configuration globale dans /etc/mysql-zrm/mysql-zrm.conf, puis il vérifie le répertoire de l’ensemble de sauvegarde actuel pour le fichier mysql-zrm.conf dont les paramètres remplacent les paramètres globaux dans /etc/mysql-zrm/mysql-zrm.conf. Par exemple, si l’ensemble de sauvegarde actuel est osCommerce, mysql-zrm lirait d’abord la configuration de /etc/mysql-zrm/mysql-zrm.conf puis la configuration de /etc/mysql-zrm/osCommerce/mysql-zrm.conf.

Si nous voulons simplement sauvegarder la base de données MySQL osCommerce dans l’ensemble de sauvegarde osCommerce, nous mettons ce qui suit dans /etc/mysql-zrm/osCommerce/mysql-zrm.conf :

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

| databases=osCommerce |

9 Suppression des Anciennes Sauvegardes

Si vous n’avez pas défini de politique de conservation dans votre configuration mysql-zrm, les sauvegardes MySQL sont conservées indéfiniment, ce qui signifie que votre disque dur se remplira avec le temps. Vous pouvez supprimer les anciennes sauvegardes simplement en supprimant le répertoire de sauvegarde. Par exemple, si vous avez une sauvegarde dans /var/lib/mysql-zrm/dailyrun/20060926195831 et que vous n’en avez plus besoin, vous pouvez la supprimer comme ceci :

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

10 Journal

mysql-zrm journalise dans le fichier journal /var/log/mysql-zrm/mysql-zrm.log.