Парсер Хабра: [Из песочницы] Zabbix: Резервное копирование небольшой базы

воскресенье, 20 октября 2013 г.

[Из песочницы] Zabbix: Резервное копирование небольшой базы

Опустим долгое вступление о необходимости резервного копирования данных. Все мы знаем, что бэкапы нужно делать. Те, кто активно использует Zabbix, тоже задумываются о возможности восстановления базы в случае её повреждения либо переноса на новый сервер и т.д. Понятно, что оптимальным вариантом для этого является репликация, но далеко не каждая организация может себе это позволить. Я покажу, каким образом проблема резервного копирования Zabbix решена у нас. Если кому-то интересно, прошу под кат.

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

Когда передо мной встала необходимость резервного копирования базы данных 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. Считайте сами, сколько у вас на это уйдёт времени, но я думаю, намного меньше двух суток.

Всем рабочих бэкапов и стабильной работы всех систем.

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends: