Предупреждение: я не считаю представленную ниже схему идеальной, поэтому статья написана не в качестве образца, а с целью получения конструктивной критики и полезных советов по улучшению.
Когда передо мной встала необходимость резервного копирования базы данных Zabbix, я не пошёл далеко и решил использовать проверенное средство: mysqldump. Он хорошо зарекомендовал себя при использовании с базами других веб-сервисов, таких как redmine, glpi, drupal и других, но в случае с Zabbix оказался абсолютно непригодным. Резервные копии делались, ошибок не возникало, но однажды настал чёрный день, когда бэкап потребовалось восстановить. На выгрузку базы из дампа сравнительно небольшой базы ушло около двух суток. Учитывая, что база данных на тот момент была, можно сказать, в зачаточном состоянии, время простоя в будущем увеличилось бы в разы. Это было абсолютно неприемлемо. Тогда-то мой взгляд и упал на Percona XtraBackup.
Percona Xtrabackup — программный продукт с открытым исходным кодом, позволяющий делать резервные копии баз данных MySQL без блокировки. Open Query, mozilla.org и Facebook используют данную программу, что позволяет сделать вывод, что это не сырое красноглазое поделие. Замечу, что в моём случае не получилось использовать Percona совместно с zabbix-сервером из-за низкой производительности дисковой подсистемы. Иногда возникали ошибки, связанные с тем, что Percona не успевала считать данные, которые Zabbix активно записывал. Было решено останавливать zabbix-сервер на время создания резервной копии. На сегодняшний день это занимает около 6 минут в сутки. Учитывая, что все особо критичные триггеры завязаны на SNMP-трапы, которые после запуска zabbix-server всё равно не останутся неучтёнными, для меня это время вполне допустимо. Возможно, в вашем случае не придётся останавливать демон Zabbix’а, и простоя не будет совсем.
Дальше я подумал, каким должен быть идеальный бэкап для меня. И понял, что лучший бэкап — это тот, о котором не беспокоишься, но знаешь что он выполняется. Мне удалось добиться такого результата: я не беспокоюсь о резервных копиях. Я не захожу каждое утро на сервер, скрестив пальцы, и не проверяю лог, размер файла и оставшееся место на разделе. Но я знаю, что бэкапы делаются, потому что всю необходимую информацию получаю по электронной почте. В этом мне помогает довольно простой скрипт, который я и хочу вынести на суд общественности. Возможно, с ним есть какие-то проблемы, о которых я не подозреваю?
В Zabbix у нас настроены уведомления по e-mail. Для этого используется ssmtp. Инструкций в интернете достаточно, к тому же тема рассматривается совсем иная, так что не буду на этом останавливаться. Кроме Percona и ssmtp ничего специфического не используется: tar, gzip, sed и find есть в каждом дистрибутиве. Для надёжности файлы резервных копий дублируются на удалённый сервер по NFS.
Система, на которой это используется:
#!/bin/bash DAY=`date +%Y%m%d` LOGFILE=/var/log/zabbix_backup.log # E-mail, на который производится отправка EMAIL=admin@host.com # Отдельно используются logfile и mailfile: лог не перезатирается каждый день и периодически сжимается или удаляется с помощью logrotate MAILFILE=/tmp/mailfile.tmp # Каталог с бэкапами BK_GLOBAL=/home/zabbix/backups # Каталог для текущего бэкапа BK_DIR=$BK_GLOBAL/Zabbix_$DAY # #Процедура set_date для записи даты и времени в лог set_date () { DT=`date "+%y%m%d %H:%M:%S"` } # mkdir $BK_DIR set_date echo -e "$DT Начало резервного копирования базы ZABBIX" > $MAILFILE service zabbix-server stop 2>>$MAILFILE innobackupex --user=root --password=qwerty --no-timestamp $BK_DIR/xtra 2>&1 | tee /var/log/innobackupex.log | egrep "ERROR|innobackupex: completed OK" >>$MAILFILE innobackupex --apply-log --use-memory=1000M $BK_DIR/xtra 2>&1 | tee /var/log/innobackupex.log | egrep "ERROR|innobackupex: completed OK" >>$MAILFILE # У Percona Xtrabackup есть неприятная особенность: выводить много лишней информации. Здесь отсекается всё лишнее, с помощью tee и egrep. service zabbix-server start 2>>$MAILFILE set_date echo -e "$DT Резервное копирование базы данных завершено" >> $MAILFILE set_date echo -e "$DT Начало архивирования" >> $MAILFILE cd $BK_DIR tar -cf $BK_DIR/zabbix_db_$DAY.tar ./xtra 2>>$MAILFILE rm -rf $BK_DIR/xtra cd /usr/share tar -cf $BK_DIR/zabbix_files_$DAY.tar ./zabbix 2>>$MAILFILE cd /etc tar -cf $BK_DIR/zabbix_etc_$DAY.tar ./zabbix 2>>$MAILFILE cd / gzip $BK_DIR/zabbix_db_$DAY.tar 2>>$MAILFILE gzip $BK_DIR/zabbix_files_$DAY.tar 2>>$MAILFILE gzip $BK_DIR/zabbix_etc_$DAY.tar 2>>$MAILFILE set_date echo -e "$DT Архивирование завершено" >> $MAILFILE rm -f zabbix_db_$DAY.tar rm -f zabbix_files_$DAY.tar rm -f zabbix_etc_$DAY.tar set_date echo -e "$DT Монтирование NFS-каталога" >> $MAILFILE mount 192.168.1.30:/home/backups /mnt/nfs 2>>$MAILFILE set_date echo -e "$DT Копирование файлов по сети начато" >> $MAILFILE mkdir /mnt/nfs/Zabbix_$DAY cp $BK_DIR/zabbix_db_$DAY.tar.gz /mnt/nfs/Zabbix_$DAY 2>>$MAILFILE cp $BK_DIR/zabbix_files_$DAY.tar.gz /mnt/nfs/Zabbix_$DAY 2>>$MAILFILE cp $BK_DIR/zabbix_etc_$DAY.tar.gz /mnt/nfs/Zabbix_$DAY 2>>$MAILFILE set_date echo -e "$DT Копирование файлов по сети завершено" >> $MAILFILE echo -e "$DT Удаление старых архивов" >> $MAILFILE find $BK_GLOBAL/* -type f -ctime +30 -exec rm -rf {} \; 2>>$MAILFILE find /mnt/nfs/* -type f -ctime +30 -exec rm -rf {} \; 2>>$MAILFILE find $BK_GLOBAL/* -type d -name "*" -empty -delete 2>>$MAILFILE find /mnt/nfs/* -type d -name "*" -empty -delete 2>>$MAILFILE set_date echo -e "$DT Старые архивы удалены" >> $MAILFILE echo -e "$DT Размонтирование NFS-каталога\n" >> $MAILFILE umount /mnt/nfs 2>>$MAILFILE cat $MAILFILE >> $LOGFILE sed -i -e "1 s/^/Subject: Zabbix backup log $DAY\n\n/;" $MAILFILE 2>>$LOGFILE sed -i -e "1 s/^/From: zabbixsender@host.com\n/;" $MAILFILE 2>>$LOGFILE sed -i -e "1 s/^/To: $EMAIL\n/;" $MAILFILE 2>>$LOGFILE echo -e "\nСодержимое каталога $BK_DIR:\n" >> $MAILFILE ls -lh $BK_DIR >> $MAILFILE echo -e "\nИспользование жёсткого диска:\n" >> $MAILFILE df -h >> $MAILFILE cat $MAILFILE | mail -t 2>>$LOGFILE
Файлы из каталогов /etc/zabbix и /usr/share/zabbix копируются с целью сохранения настроек и дополнительных скриптов, используемых в Zabbix.
Для восстановления базы из полученной копии достаточно остановить mysqld, заменить каталог на извлечённый из архива и вновь запустить демон MySQL. Считайте сами, сколько у вас на это уйдёт времени, но я думаю, намного меньше двух суток.
Всем рабочих бэкапов и стабильной работы всех систем.
ссылка на оригинал статьи http://habrahabr.ru/post/198276/