Большинство систем резервного копирования умеют сообщать, что задание выполнено успешно. Но на практике этого не всегда достаточно: после прерванного копирования вместо готового бэкапа может остаться временный файл, а сама копия — оказаться слишком маленькой, устаревшей или не того формата, который ожидался.
В нашей инфраструктуре около 30 серверов и несколько разных хранилищ для резервных копий. Со временем выяснилось, что контролировать только процесс резервного копирования недостаточно. Рассказываем, почему мы начали проверять сами файлы бэкапов и какую систему контроля для этого построили.
Самое главное:
В инфраструктуре работает около 30 серверов и используется несколько разных хранилищ резервных копий.
Штатные инструменты видят статусы своих заданий, но не контролируют результат в хранилище, а на NAS агент мониторинга установить нельзя.
Нам было важно контролировать не процесс создания бэкапа, а его фактический результат.
Для каждой папки используются собственные критерии проверки: возраст файла, размер и расширение.
Решение построено на PowerShell, Zabbix, FastAPI и MAX.
Продуктивные серверы с резервными копиями не имеют прямого доступа во внешнюю сеть.
Почему успешное резервное копирование еще не гарантирует наличие бэкапа
В нашей инфраструктуре около 30 серверов — 10 физических и 20 виртуальных. Резервные копии складываются примерно в восемь сетевых папок: часть на NAS, часть на файловых серверах, часть на выделенных хранилищах.
На первый взгляд, существующих средств мониторинга резервного копирования должно быть достаточно. Но довольно быстро выяснилось, что нас интересует не только статус задания резервного копирования. Нам важно знать, появился ли сам файл, тот ли это файл и можно ли вообще считать его нормальной резервной копией.
Например, на NAS физически нельзя установить агент мониторинга. Veeam Backup & Replication или Acronis видят собственные задания, а нам нужно контролировать сам факт появления файла в сетевой папке.
Кроме того, проблемы не всегда связаны с самим заданием резервного копирования. На практике мы столкнулись с несколькими типовыми ситуациями:
вместо ожидаемого файла .bak или .vbk после прерванного копирования оставался временный .tmp;
файл резервной копии появлялся, но его размер был в десятки раз меньше обычного;
резервная копия формально существовала, но не обновлялась в ожидаемые сроки;
разные системы создавали бэкапы с разной периодичностью, поэтому единое правило проверки не подходило для всех.
Например, если обычный бэкап занимает около 500 МБ, а новый файл весит 2 МБ, вряд ли стоит считать задачу успешно выполненной.
С периодичностью тоже все оказалось не так просто. Где-то файл должен обновляться ежедневно, а где-то копирование запускается по событию. Поэтому универсальное правило «файл должен быть не старше N часов» не работало.
В итоге стало понятно, что нам нужен контроль не столько процесса резервного копирования, сколько его фактического результата.
После короткого обзора рынка выбор свелся к двум вариантам: покупать тяжелую систему и дописывать под нее плагины или сделать свое небольшое решение под конкретную инфраструктуру. Мы выбрали второй вариант.
Какие параметры резервных копий мы решили контролировать
Список требований сложился не на бумаге, а из реальных ситуаций, с которыми мы сталкивались в инфраструктуре.
В итоге система должна была решать несколько задач одновременно:
работать с NAS и обычными сетевыми папками без установки дополнительного ПО непосредственно на хранилища;
позволять для каждой папки отдельно задавать критерии корректной резервной копии: максимальный возраст файла, минимальный размер и допустимые расширения;
обеспечивать централизованное управление без ручного редактирования конфигурационных файлов на серверах;
поддерживать добавление новых серверов, папок и пользователей из единой точки управления;
отправлять уведомления через MAX;
использовать существующий Zabbix как часть решения, а не создавать еще одну параллельную систему мониторинга;
разграничивать права доступа для разных категорий пользователей.
Последний пункт был для нас не менее важен, чем техническая часть. Одному специалисту достаточно видеть состояние своих серверов, другому — всей инфраструктуры, а кто-то должен только получать уведомления и не иметь возможности что-либо менять.
Настройка резервного копирования — это только часть задачи. Не менее важно контролировать, что резервные копии действительно создаются, обновляются и доступны для восстановления. Специалисты «Бизнес Систем» помогают внедрять системы мониторинга на базе Zabbix, настраивать контроль бэкапов, разграничивать права пользователей и организовывать централизованные уведомления о сбоях. Компания реализует проекты по сопровождению и развитию ИТ-инфраструктуры для коммерческих организаций и государственных учреждений.
Как мы построили систему контроля резервных копий
В результате получилось довольно компактное решение из трех частей: агента на серверах, центрального сервера обработки и интерфейса управления в MAX.
PowerShell-агент на серверах
На Windows-серверах работает легкий PowerShell-агент. Он проверяет указанные папки и собирает фактическую информацию о резервных копиях: когда появился самый свежий файл, сколько он весит, сколько файлов находится в каталоге и нет ли ошибок доступа.
Результат проверки агент передает центральному серверу.
Центральный сервер на базе Zabbix и FastAPI
Там работает связка Zabbix + FastAPI. Центральная часть получает отчеты от всех агентов, сопоставляет фактические показатели с заданными порогами и решает, все ли в порядке или пора сообщить администратору о проблеме.
Здесь же формируется ежедневная сводка по всем контролируемым резервным копиям.
Управление и уведомления через MAX
Третье звено — MAX. Сюда приходят уведомления, и отсюда же администратор может управлять системой: добавлять серверы и папки, менять настройки и назначать наблюдателей.
Таким образом, вся работа с системой выполняется из единой точки, без необходимости подключаться к отдельным серверам или редактировать конфигурации вручную.
Почему серверы с резервными копиями не имеют доступа в интернет
Для нас это было принципиальным моментом. Агент взаимодействует только с сервером Zabbix внутри локальной сети. Уже центральный сервер обращается к MAX по HTTPS. В результате продуктивные серверы, на которых находятся резервные копии, не получают прямого доступа во внешнюю сеть.
Как работает проверка резервных копий
Если сильно упростить всю схему, она выглядит так. На сервере появляется резервная копия. Агент проверяет ее и передает на центральный сервер несколько параметров: где находится файл, когда он появился, сколько весит и доступна ли сама папка.
На этом этапе система получает только факты. Но сами по себе они еще ничего не говорят о состоянии резервной копии.
Например, как понять, что файл размером 100 МБ — это нормальный результат для одной базы данных и подозрительно маленький для другой? Как отличить просто старый файл от действительно пропущенного резервного копирования? Что делать, если перестал отвечать не бэкап, а сам агент? И как показать всю эту информацию администратору так, чтобы ему не приходилось ежедневно проверять несколько разных систем?
Именно эту логику мы вынесли на центральный сервер. Там данные анализируются, сопоставляются с заданными правилами и превращаются в понятный статус для администратора.
Во второй части покажем, как система принимает решения на основе собранных данных: как определяет проблемные резервные копии, отличает реальные сбои от штатных ситуаций и формирует уведомления для ответственных сотрудников. Также расскажем, что именно видит администратор в MAX и как один бот постепенно превратился в единую точку контроля инфраструктуры.
Реклама: ООО «Бизнес Системы», ИНН 5501093076, erid: 2W5zFK1MBvy
