Как работает мониторинг резервных копий на 30 серверах: логика проверок, уведомления и управление через MAX

Система состоит из трех компонентов: PowerShell-агента на серверах, центрального сервера на базе Zabbix и FastAPI и интерфейса управления в MAX. 

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

PowerShell-агент собирает только факты. Одна из ключевых идей архитектуры — не делать агент «умным».

После этого агент:

• проверяет доступность каждого каталога;

• находит самый свежий файл;

• определяет его возраст;

• определяет размер файла;

• фиксирует пустые каталоги;

• регистрирует ошибки доступа.

Собранные данные формируются в JSON и передаются на центральный сервер.

На этом работа агента заканчивается. Он не взаимодействует с MAX, не обращается к API Zabbix и не определяет, является ли резервная копия корректной. Его задача — собрать фактические данные и передать их на обработку. Агент остается простым и занимается только сбором данных, а вся логика проверки работает на центральном сервере. 

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

На центральном сервере FastAPI-бот периодически получает свежие отчеты и сопоставляет их с настройками конкретной папки.

В зависимости от результата проверки резервная копия получает один из статусов:

• old — файл старше допустимого срока хранения;

• small — размер файла меньше установленного порога;

• error — папка недоступна, пуста или указанный путь не найден;

• monitor_offline — агент перестал передавать данные на центральный сервер.

Отдельно контролируется работоспособность самого мониторинга. Если агент перестает передавать данные, система фиксирует это как отдельную проблему. В результате можно избежать ситуации, когда мониторинг перестал работать, но никто об этом не знает.

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

Одних уведомлений об ошибках недостаточно. Иногда важно быстро убедиться, что все работает штатно.

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

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

MAX используется не только для получения уведомлений. Через него можно управлять серверами, каталогами и настройками мониторинга из единой точки. 

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

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

После этого можно добавить новый каталог для контроля:

• указать путь;

• задать понятное название;

• определить максимально допустимый возраст файла;

• установить минимальный размер резервной копии.

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

Через MAX можно:

• изменять параметры существующих каталогов;

• переименовывать серверы и папки;

• временно исключать каталоги из мониторинга;

• назначать наблюдателей;

• изменять время ежедневной сводки.

Таким образом, MAX стал не только каналом уведомлений, но и полноценным интерфейсом управления мониторингом.

Если система обнаруживает проблему, администратор получает уведомление с подробным контекстом.

В сообщении отображаются:

• сервер;

• каталог;

• путь;

• возраст резервной копии;

• размер файла.

Если резервное копирование выполняется корректно, система отправляет короткое подтверждение успешной проверки.

Из сообщения можно сразу перейти к управлению системой через главное меню.

Когда количество серверов измеряется десятками, не всем сотрудникам нужна одинаковая информация.

Например, администратору 1С достаточно видеть резервные копии серверов с тегом 1C, а системному администратору требуется информация по всей инфраструктуре.

Поэтому в системе предусмотрено несколько уровней доступа:

• administrator — полный доступ к системе и пользователям;

• backup_admin — управление резервным копированием без доступа к управлению пользователями;

• backup_observer — получение уведомлений без возможности изменять настройки.

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

Поскольку Zabbix уже был основной системой мониторинга инфраструктуры, возник вопрос: зачем ограничиваться только резервным копированием?

В MAX начали поступать и другие события мониторинга:

• проблемы с серверами;

• события по сайтам;

• уведомления о состоянии инфраструктуры;

• данные о температуре в серверной.

Появилась и обратная связь. Прямо из сообщений можно подтвердить (ack) или закрыть (close) проблему в Zabbix без перехода в веб-интерфейс.

Также через бота доступны:

• список хостов;

• статус сайтов;

• текущая температура в серверной.

Температура контролируется с помощью USB-термометра TEMPer.

После запуска системы под мониторингом оказалось:

• 30 серверов;

• 10 физических серверов;

• 20 виртуальных серверов;

• около восьми каталогов с резервными копиями.

Основные изменения после внедрения:

• контроль резервных копий полностью автоматизирован;

• время обнаружения проблем сократилось до 24 часов, а при необходимости может составлять 15–30 минут;

• добавление нового сервера занимает менее минуты;

• исчезла необходимость вручную редактировать конфигурации;

• агент не создает заметной нагрузки на продуктивные серверы;

• отсутствует зависимость от зарубежных SaaS-сервисов.

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

В итоговой схеме используются:

• MAX для коммуникаций и управления;

• Python, FastAPI и SQLite на серверной стороне;

• PowerShell и WinSCP на Windows-серверах.

Серверную часть можно развернуть на Linux-системах из российского реестра программного обеспечения, включая Alt Linux, Astra Linux, RED OS и Rosa Linux.

Для работы решения не требуются Telegram, Slack, Jira или зарубежные SaaS-платформы мониторинга, что важно для организаций, работающих в рамках политики импортозамещения.

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

В ближайших планах:

• разработка Linux-агента на Bash;

• поддержка S3-совместимых хранилищ;

• экспорт метрик в Prometheus и Grafana;

• расширение возможностей аналитики и отчетности.

Сейчас система отвечает на несколько важных вопросов:

• появился ли файл резервной копии;

• соответствует ли он требованиям по возрасту;

• достаточно ли его размер;

• доступно ли хранилище.

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

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

После запуска система взяла под контроль резервные копии на 30 серверах и позволила отказаться от ручных проверок. Вместо просмотра нескольких систем и сетевых каталогов администраторы получают актуальную информацию о состоянии резервных копий в одном интерфейсе.

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

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

Реклама: ООО «Бизнес Системы», ИНН 5501093076, erid: 2W5zFHmwgdo