Мало просто настраивать мониторинг бэкапов и оповещения. Я регулярно вручную проверяю все бэкапы. Да, это очень хлопотно, но другого выхода я не вижу. Если я этого не делаю, то перестаю спокойно спать.

Вот свежий пример, когда большая продуктовая база бэкапилась, но бэкап не проверялся. Автору повезло, что потерял только несколько записей. А мог и всю таблицу. Там, где можно, я автоматизирую разворачивание на запасном сервере с помощью простых bash скриптов. У меня бывали всякие ситуации, когда бэкапы по каким-то причинам переставали делаться. Если они физически отсутствуют, я получаю уведомление от zabbix. Но этого мало.

Особенно важно проверять дампы баз. Физическое наличие файла с дампом не означает, что вы без проблем его развернете. Надо проверять данные, заливая дамп в базу. Это единственный способ убедиться, что данные реально есть и они актуальны.

Backup должен быть в другом дата центре у другого юр. лица

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

Вас могут банально заблокировать за неуплату, из-за ошибки. Хостер может разорвать отношения в одностороннем порядке. Все это я видел и встречал подобные истории от других. Вот пример из одного чата.

С самого сервера с данными не должно быть доступа к бэкапам

Очень важное правило — бэкап сервер сам подключается к целевым машинам и забирает информацию. Это добавляет сложности к сервисам, с помощью которых вы будете делать бэкап. Не получится просто купить где-то место в s3, nfs, smb и класть туда бэкапы с серверов. Нужен активный агент, который будет ходить по целевым серверам и собирать данные сам. Зачем такие сложности?

Представьте ситуацию, что на целевой сервер попадает злоумышленник или вирус. Он шифрует не только ваши данные, но и бэкапы, к которым есть доступ с машины. Иногда я делаю 2 разных бэкапа — в первое хранилище целевой сервер кладет данные самостоятельно. А с этого хранилища второй бэкап-сервер сам забирает данные. К нему нет доступа ни у кого. Для большей безопасности можно затирать в логах следы подключения, чтобы нельзя было получить информацию не только о местоположении второго сервера, но и в целом информации о том, что он существует.

Для подобного рода бэкапов хорошо подходят бюджетные vps с большими дисками. Такая услуга, к примеру, есть у ruvds. В списке услуг выбирайте большой диск. Доступен не на всех тарифах и датацентрах.

Бэкапы должны быть максимально полные и подробные

Что я имею ввиду? Зачастую бэкапы делаются с расчетом на то, что что-то изменится на проде и нам надо будет развернуть бэкап и посмотреть на него. Бэкапятся, к примеру, исходники сайта и база к нему. Когда все в порядке и ты просто проверяешь бэкап, сложностей не возникает, потому что если ты даже что-то забыл, то залез на prod и посмотрел.

Например, у сайта может быть сложный и насыщенный конфиг nginx с кучей location и редиректов. В процессе эксплуатации вы могли тюнить и вносить много изменений в настройки mysql сервера. Если конфиги не забэкапить вместе с сайтом, то разворачивать и запускать его в работу может быть очень трудозатратно и хлопотно, особенно если оптимизация и настройки выполнялись давно и все уже забыто.

Отсюда правило — бэкапьте не только данные, но и все окружение из расчета на то, что вы разом можете потерять prod навсегда. Я много раз об это спотыкался и по второму разу настраивал все то, что у же было настроено ранее. Сейчас все конфиги проектов храню в своем gitlab. Из того, что часто забывают — ssl/tls сертификаты. А потом их приходится торопливо искать.

Backup виртуальных машин

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

Если нужно делать бэкап виртуальной машины, то я делаю небольшой системный диск (30-50 Гб) и бэкаплю только его. Данные кладу на отдельный виртуальный диск и забираю их в сыром в виде с помощью rsync или аналогов. С его помощью легко и быстро делать инкрементные бэкапы, а потом их разворачивать. Нет проблем с докачкой и битыми файлами. Даже если что-то и повреждено, то 1 файл из десятков тысяч погоды не сделает. Можно пережить.

Проверяйте скорость восстановления данных

В завершение своего списка еще одна рекомендация — проверяйте скорость доступа к бэкапам. У меня были ситуации, когда надо срочно восстанавливать данные. Ты начинаешь их загружать с сервера бэкапа и понимаешь, что скорость катастрофически низкая.

В обычное время, во время проверок, этого можно не заметить, потому что спешить некуда. А вот если случилась авария и нужно как можно быстрее восстановить данные, скорость доступа становится очень критична.

Есть дешевые хранилища, где явно не указано, что скорость доступа будет низкой. Но нужно это понимать, если цена за хранение действительно ниже, чем в среднем по рынку. Многие хостеры на хранилищах с безлимитным трафиком на самом деле этот лимит имеют и включат вам его после того, как вы превысите определенный порог в скачанных данных. Вам просто сделают не 100 мегабит полосу, а 5-10.

У меня были ситуации, когда сервер с бэкапами живет на гигабитном порту с «безлимитным трафиком». А когда ты скачаешь 10-15 гигабайт, включается ограничение полосы до 100 мегабит. Возможно будет и дальнейшее урезание. С такими лимитами нет смысла платить за гигабит. Это просто маркетинговая уловка.

В общем, не доверяйте данным из описания тарифа, проверяйте их сами, чтобы потом не было сюрприза.

Сообщение Как правильно делать бэкапы и следить за ними появились сначала на Clip-Clap.

Самый простой способ сделать бэкап всех базы с помощью mysqldump следующий:

# /usr/bin/mysqldump -uroot -hlocalhost -p'password' --all-databases | /usr/bin/gzip -c > /backup/mysql/`date "+%Y-%m-%d"`.gz

На выходе будет один сжатый файл с именем вида 2018-09-27.gz, в котором будет дамп всех mysql баз сервера, в том числе служебных таблиц. Работать с таким файлом потом очень неудобно. Это подходит только для случая, когда вы на таком же сервере будете восстанавливать все базы данных.

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

# mysql -u root -p --one-database destdbname < alldatabases.sql

У меня она не заработала. Консольная mysql выдавала ошибку. Я не стал подробно разбираться. Затем попробовал с помощью sed выдернуть информацию только о нужной базе, но сходу не получилось, так как дамп был большой. Просто просмотреть его была проблема, а тренироваться на тестовых дампах — тратить лишнее время. Проще было пойти на исходный сервер и вытащить только нужную базу данных.

Заодно заменил скрипт бэкапа на следующий:

for i in `mysql -uroot -p'password' -e'show databases;' | grep -v information_schema | grep -v Database`; 
    do 
	/usr/bin/mysqldump -uroot -p'password' $i | /usr/bin/gzip -c > /backup/mysql/`date +%Y-%m-%d`-$i.sql.gz;
    done

Сначала кладем в массив список всех баз данных, а потом делаем отдельный дамп каждой из них и сжимаем.

Был бы рад, если бы кто-то подсказал простой и рабочий способ загрузить на сторонний сервер одну базу данных из общего дампа. Очень часто приходится видеть такие бэкапы от всяких панелей управления или самодельных скриптов.

Сообщение Бэкап всех баз mysql в отдельные файлы появились сначала на Clip-Clap.

Введение

Если у вас еще нет своего сервера для мониторинга, то рекомендую материалы на эту тему. Для тех, кто предпочитает систему CentOS:

1. Установка CentOS.
2. Настройка CentOS.
3. Установка и настройка zabbix сервера.

Бэкапы в виде сырых данных в директории (1-й способ)

У меня много где настроена самодельная система бэкапа, похожая на то, что описано в статье по настройке бэкапа с помощью rsync. Не буду подробно останавливаться на том, почему бэкаплю именно так. Во многих случаях это удобно, так как всегда имеешь под рукой свежую версию данных в исходном виде. В случае повреждения источника, просто меняешь точку монтирования и получаешь практически сразу все данные, без простоя рабочего процесса.

На всякий случай хочется следить за тем, что бэкапы у тебя актуальны и в случае чего ты можешь на них рассчитывать. Делать мы это будет по очень простой схеме. На сервере источнике будет раз в сутки создаваться файл. Во время бэкапа этот файл будет улетать на сервер с резервными данными. Этот сервер подключен к системе мониторинга zabbix с помощью агента. Этот агент будет периодически проверять дату последнего изменения файла. Если эта дата больше заданного интервала, то мы будем получать оповещение о том, что бэкапы не выполняются.

Для настройки описанной схемы нам понадобится выполнить несколько шагов:

1. На серверах источниках настроить скрипт, который будет создавать файл и поместить его в планировщик.
2. На сервере заббикс настроить на хосте с бэкапами item и trigger для слежения и оповещения о дате файла.

Бэкапы в виде запакованных архивов (2-й способ)

Если у вас бэкапится, к примеру, какая-то база в дамп или есть просто отдельный файл, то имеет смысл его архивировать и хранить в виде одиночного архива. Для таких бэкапов тоже нужен мониторинг. Чтобы следить за актуальностью бэкапа, я предлагаю мониторить 2 параметра:

1. Размер файла. Если он равен нулю, то срабатывает триггер.
2. Дата создания бэкапа. Если он старше какого-то срока, в моем примере будут 24 часа, то шлем оповещение.

Мониторинг бэкапов будет настроен из расчета, что у вас все бэкапы лежат в одной директории на сервере. В этой директории резервные копии хранятся для каждого объекта в отдельной папке. Будет настроено автообнаружение папок в директории с бэкапами.

1-й способ

Скрипт создания проверочного файла

Я использую описанную выше схему для бэкапа как windows так и linux серверов. Поэтому скрипта будет 2, для каждой системы. Вот пример такого скрипта для linux:

# mcedit create-timestamp.sh

#!/bin/sh
echo `date +"%Y-%m-%d_%H-%M"` > /shares/docs/timestamp

Скрипт просто создает файл и записывает в него текущую дату. Нам этого достаточно. Писать туда можно все, что угодно, так как проверять мы будем не содержимое, а дату последнего изменения.

Добавляем этот скрипт в cron:

# mcedit /etc/crontab

#Create timestamp for backup monitoring
 1 15 * * * root /root/bin/create-timestamp.sh

Раз в день в 15:01 скрипт будет создавать файл, перезаписывая предыдущий.

Делаем то же самое на windows. Создаем файл create-timestamp.bat следующего содержания:

echo %date:~-10% > D:\documents\timestamp

И добавляем его в планировщик windows. Не забудьте указать, чтобы скрипт запускался вне зависимости от регистрации пользователя, то есть чтобы он работал, даже если в системе никто не залогинен.

Запустите оба скрипта, чтобы проверить, что все в порядке, и необходимые файлы создаются.

Запустите стандартные скрипты бэкапа, чтобы созданные файлы переместились на резервные сервера. После этого можно приступать к настройке мониторинга за изменением файлов в zabbix.

Настраиваем мониторинг бэкапов через проверку даты изменения файлов

Дальше привычное дело по созданию итемов и триггеров. Идем в панель управления zabbix, открываем раздел Configuration -> Hosts, выбираем сервер, на котором у нас хранятся бэкапы и создаем там итем со следующими параметрами:

На скриншот не влезла вся строка параметра Key, поэтому привожу ее здесь:

vfs.file.time[/mnt/data/BackUp/xb-share/documents/timestamp,modify]

Не очень понимаю, чем отличается время изменения, от времени последнего изменения. Эта информация из документации zabbix. Для того, чтобы у вас корректно собирались данные, необходимо, чтобы у пользователя zabbix были права на чтение указанного файла. Обязательно проверьте это. Я не сделал это, через одну из папок агент не мог пройти из-за недостатка прав. В итоге получил ошибку:

17177:20160321:002008.008 item "xb-share-documents:vfs.file.time[/mnt/data/BackUp/xb-share/documents/timestamp]" became not supported: Not supported by Zabbix Agent

Из текста не понятно, в чем проблема. Про права я догадался. Обновление итема установил раз в 10 минут (параметр update interval), чаще не вижу смысла, можно вообще поставить пару раз в сутки, в зависимости от вашего плана архивации данных.

Теперь создадим триггер для этого элемента данных:

Разберем, что у нас в выражении написано:

{xm-backup:vfs.file.time[/mnt/data/BackUp/xb-share/documents/timestamp,modify].now(0)}-{xm-backup:vfs.file.time[/mnt/data/BackUp/xb-share/documents/timestamp,modify].last(0)}>172800

xm-backup — сервер, на котором хранятся бэкапы. Мы берем текущее время, вычитаем из него время последнего изменения файла. Если оно больше 172800 секунд (2 суток), то срабатывает триггер.  Вы можете сами выбрать подходящий вам интервал времени сравнения в зависимости от плана бэкапа.

Для тестирования работы оповещений отключите в один из дней скрипты на источниках, создающие проверочный файл. Как только он просрочится, сработает триггер.

На этом все. Мы настроили простейший мониторинг бэкапов с помощью zabbix. Если по какой-то причине файлы перестанут синхронизироваться с сервером резервных копий, вы узнаете об этом и сможете вовремя обнаружить проблему.

2-й способ

Скрипты сбора информации о бэкапах

Во втором случае у нас есть директория с бэкапами /mnt/backup, где каждая отдельная папка содержит набор однотипных архивов за разные даты.

Внутри следующее содержимое. Каждый час делает резервная копия базы данных.

Дальнейшее описание способа мониторинга бэкапов будет актуально только для точно такой же структуры бэкапов. У вас есть общая директория, в ней папки, где внутри сжатые архивы формата .gz. Если расширение файлов другое, то можно подредактировать скрипты, которые я покажу дальше.Обращаю внимание, что приведенная дальше информация требует осмысленного повторения. Не нужно слепо копировать и пробовать. Нужно понять, что я делаю и изменить скрипты и другие настройки под свои нужды. Я просто даю направление, подсказываю способ.

Нам пригодятся несколько скриптов. Первый из них — backup-info.sh. Он будет формировать текстовый файл backup_info.txt, где будет в одну строку указано имя папки с архивом, размер последнего архива, дата создания архива, время создания архива.

#!/bin/bash

BK_DIR=/mnt/backup # директория с бэкапами
SRV_NAME=`ls $BK_DIR` # формируем список папок с архивами
LOG_FILE=/etc/zabbix/scripts/backup_info.txt # выходной файл с информацией

# удаляем предыдущий файл с информацией
rm $LOG_FILE

for a in $SRV_NAME
    # определяем размер последнего бэкапа
    do  bsize=`ls -lt $BK_DIR/$a | grep .gz | awk 'NR == 1{print$5}'`
	if [[ "$bsize" = "" ]]
	    then
	    bsize=0
	fi
	# определяем имя последнего бэкапа
	bfile=`ls -lt $BK_DIR/$a | grep .gz | awk 'NR == 1{print$9}'`
	# определяем дату создания последнего бэкапа
	btime=`stat $BK_DIR/$a/$bfile | grep Modify | awk '{print $2,$3}' | cut -f1-1 -d"."`
	# записываем информацию в файл
    echo $a $bsize $btime >> $LOG_FILE
    done

В текстовом файле будет следующее:

dedic-nodes-BCH-01 496211 2018-08-01 17:54:58
dedic-nodes-BTC-01 702496 2018-08-01 17:12:46
dedic-nodes-DASH-01 244488 2018-08-01 17:40:51
dedic-nodes-LTC-01 491030 2018-08-01 17:20:23
vps-14 858433 2018-08-01 18:01:02
vps-15 235689258 2018-08-01 18:02:51
vps-16 235977137 2018-08-01 18:05:54
vps-17 23983868 2018-08-01 17:09:59

Я рекомендую разобрать каждую проверку и вручную ее выполнить в консоли, чтобы убедиться, что она работает как и должна и получает правильное значение. В разных дистрибутивах могут быть разные ключи и выводы команд. Например, команда ls может разделять значения одним пробелом, а может несколькими. Так же вывод и порядок столбцов в разных дистрибутивах может быть разный. Я все проверил только в Ubuntu 16. Данные скрипты писались и отлаживались в ней.

Следующий скрипт — backup-time.sh. Он берет значения из текстового файла, который формирует предыдущий скрипт, вычисляет разницу в часах между текущей датой и временем создания последнего бэкапа. Полученную информацию записывает в файл backup_time.txt.

#!/bin/bash

BK_DIR=/mnt/backup # директория с бэкапами
SRV_NAME=`ls $BK_DIR` # формируем список папок с архивами
LOG_FILE=/etc/zabbix/scripts/backup_time.txt # выходной файл с информацией
INFO_FILE=/etc/zabbix/scripts/backup_info.txt # входной файл для парсинга

# удаляем предыдущий файл с информацией
rm $LOG_FILE

for a in $SRV_NAME
    # получаем дату создания архива
    do btime=`cat $INFO_FILE | grep $a | awk '{print $3,$4}'`
    # переводим дату создания архива в unix формат
    stime=`date --date="$btime" +"%s"`
    # получаем текущую дату в unix формате
    ctime=`date +"%s"`
    # сравниваем 2 даты и переводим в часы
    difftime=$[ ($ctime - $stime) / 60 ]
    # записываем полученный результат в файл
    echo $a $difftime >> $LOG_FILE
    done

Тестовый файл будет следующего содержания.

dedic-nodes-BCH-01 21
dedic-nodes-BTC-01 63
dedic-nodes-DASH-01 35
dedic-nodes-LTC-01 55
vps-14 14
vps-15 13
vps-16 10
vps-17 66

Рисуем скрипт backup-discovery.sh, который будет выполнять автообнаружение папок с архивами и передавать данные в json формате на zabbix сервер.

#!/bin/bash

JSON=$(for i in `ls -l /mnt/backup | sed '1d' | awk '{print $9}'`; do printf "{\"{#BACKUP}\":\"$i\"},"; done | sed 's/^\(.*\).$/\1/')
printf "{\"data\":["
printf "$JSON"
printf "]}"

Запустите файл и проверьте, что он корректно формирует вывод. Должно быть примерно следующее.

{"data":[{"{#BACKUP}":"dedic-nodes-BCH-01"},{"{#BACKUP}":"dedic-nodes-BTC-01"},{"{#BACKUP}":"dedic-nodes-DASH-01"},{"{#BACKUP}":"dedic-nodes-LTC-01"},{"{#BACKUP}":"vps-14"},{"{#BACKUP}":"vps-15"},{"{#BACKUP}":"vps-16"},{"{#BACKUP}":"vps-17"}]}

И еще 2 скрипта, которые будут непосредственно отдавать информацию заббикс серверу. Первый — analize-size.sh. Он будет передавать серверу информацию о размере архива.

#!/bin/bash

cat /etc/zabbix/scripts/backup_info.txt | grep $1 | awk '{print $2}'

И второй — analize-time.sh. Он передает информацию о времени создания бэкапа относительно текущего.

#!/bin/bash

cat /etc/zabbix/scripts/backup_time.txt | grep $1 | awk '{print $2}'

В завершении делаем пользователя zabbix владельцем всех скриптов и текстовых файлов. Если забыть это сделать, то потом получите ошибку и неактивный итем на сервере.

# chown -R zabbix. /etc/zabbix/scripts

Добавляем в zabbix-agent информацию о бэкапах

Теперь нам нужно добавить новые итемы в агент заббикса через UserParameter.Создаем файл /etc/zabbix/zabbix_agentd.d/backup_info.conf следующего содержания.

UserParameter=backup.discovery[*],/etc/zabbix/scripts/backup-discovery.sh
UserParameter=backup.size[*],/etc/zabbix/scripts/analize-size.sh $1
UserParameter=backup.time[*],/etc/zabbix/scripts/analize-time.sh $1

Перезапускаем агента и проверяем. Для начала автообнаружение папок.

# zabbix_agentd -t backup.discovery

Вы должны увидеть список папок в json формате, как при ручном запуске скрипта. Дальше проверим вывод информации о самих бэкапах.

# zabbix_agentd -t backup.size[dedic-nodes-BCH-01]
backup.size[dedic-nodes-BCH-01] [t|496211]

# zabbix_agentd -t backup.time[dedic-nodes-BCH-01]
backup.time[dedic-nodes-BCH-01] [t|81]

Если получаете актуальную информацию, значит все в порядке. Можно переходить на zabbix-server.

Добавляем шаблон с мониторингом бэкапов на сервер

Здесь вам ничего руками делать не надо будет, так как шаблон я уже сделал и экспортировал в файл — zabbix-backup-info.xml. Экспорт выполнен с версии 3.4. Заработает ли на предыдущих версиях — не знаю, не проверял.

В шаблоне создано одно правило автообнаружения с двумя прототипами итемов и триггеров. Итемы имеют такие настройки:

Триггеры такие:

Триггер срабатывает, если архив имеет нулевой размер и если он старше 25 часов. Время переведено в минуты. Можете изменить значение по своему усмотрению. Прикрепляйте шаблон к хосту, где настроили zabbix-agent и ждите поступления данных. Обновляются они раз в час. Получите примерно такую картинку.

Заключение

Данный функционал можно использовать не только для мониторинга бэкапов, но и других актуальных данных. Например, какая-то программа должна выгружать данные с определенной периодичностью. Мы можем следить за тем, как она это делает. В данной статье мы рассмотрели несколько параметров, по которым заббикс может анализировать файлы и каталоги. Но таких возможностей много. Он может, к примеру, проверять конкретный размер файла и предупреждать, если он сильно меньше или больше предыдущей версии. Настраивается это примерно так же, как здесь.

Сообщение Мониторинг бэкапов с помощью zabbix появились сначала на Clip-Clap.