Резервное копирование и восстановление MySQL с помощью mysql-zrm на Debian Sarge - Страница 4

6 Проверьте ваши резервные копии

Теперь мы хотим проверить целостность нашего набора резервных копий dailyrun. Мы можем сделать это так:

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

Вывод должен выглядеть так:

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

(Вы можете игнорировать предупреждение в первой строке, это не серьезно.)

Далее мы хотим проверить конкретную резервную копию в нашем наборе резервных копий dailyrun. Сначала мы запускаем

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

чтобы узнать, какие резервные копии доступны:

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

Как вы можете видеть, в нашем наборе резервных копий dailyrun четыре резервные копии. Мы хотим проверить последнюю, которая находится в каталоге /var/lib/mysql-zrm/dailyrun/20060926202404. Вот как мы можем это сделать:

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

Вывод должен выглядеть так:

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

7 Восстановление данных

Предположим, что наша база данных вышла из строя, и мы потеряли данные. Вот как мы можем восстановить наши данные из резервных копий MySQL. Сначала мы запускаем

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

чтобы узнать, какие резервные копии доступны:

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

Мы хотим восстановить из нашей последней резервной копии, которая находится в /var/lib/mysql-zrm/dailyrun/20060926202404:

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

Вывод выглядит так:

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

Данные были восстановлены, но сервер MySQL был выключен. Поэтому мы должны запустить его сейчас:

/etc/init.d/mysql start

Если вы сделали резервные копии в логическом формате вместо сырого формата, вы также можете восстановить свои данные вот так.

8 Несколько политик резервного копирования

До сих пор у нас была одна глобальная конфигурация в /etc/mysql-zrm/mysql-zrm.conf, которая применялась ко всем нашим наборам резервных копий. Теперь предположим, что у нас есть набор резервных копий osCommerce для нашей базы данных osCommerce, другой набор резервных копий vBulletin для нашей базы данных vBulletin и т.д.

Не имеет смысла резервировать все наши базы данных MySQL в наборе резервных копий osCommerce, потому что эта резервная копия должна содержать только базу данных osCommerce, и то же самое относится к нашему набору резервных копий vBulletin. Вот как мы можем решить эту проблему:

Каждый набор резервных копий имеет свой собственный подпапку в каталоге /etc/mysql-zrm, например, набор резервных копий osCommerce имеет каталог /etc/mysql-zrm/osCommerce. Теперь, когда mysql-zrm запускается, он сначала проверяет глобальную конфигурацию в /etc/mysql-zrm/mysql-zrm.conf, а затем проверяет каталог текущего набора резервных копий на наличие файла mysql-zrm.conf, настройки которого переопределяют глобальные настройки в /etc/mysql-zrm/mysql-zrm.conf. Например, если текущий набор резервных копий osCommerce, mysql-zrm сначала прочитает конфигурацию из /etc/mysql-zrm/mysql-zrm.conf, а затем конфигурацию из /etc/mysql-zrm/osCommerce/mysql-zrm.conf.

Если мы просто хотим сделать резервную копию базы данных MySQL osCommerce в наборе резервных копий osCommerce, мы помещаем следующее в /etc/mysql-zrm/osCommerce/mysql-zrm.conf:

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

| databases=osCommerce |

9 Удаление старых резервных копий

Если вы не установили политику хранения в вашей конфигурации mysql-zrm, резервные копии MySQL хранятся навсегда, что означает, что ваш жесткий диск со временем заполнится. Вы можете удалить старые резервные копии, просто удалив каталог резервной копии. Например, если у вас есть резервная копия в /var/lib/mysql-zrm/dailyrun/20060926195831 и она вам больше не нужна, вы можете удалить ее так:

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

10 Журнал

mysql-zrm записывает в файл журнала /var/log/mysql-zrm/mysql-zrm.log.