Macroscop Archive Tool

На одном из 22 архивных дисков видеосервера посыпались ошибки SMART. На диске — 760 ГБ записей за полтора месяца, а штатный путь Macroscop «перестань писать и дождись, пока архив устареет» занимает 90 дней. Рассказываю, как мы перенесли архив в виртуальный диск за одно окно обслуживания в несколько минут, как отчёт по архиву помог заодно навести порядок в камерах и почему из этого получилась открытая утилита для администраторов Macroscop.

Исходная ситуация

У нас два сервера Macroscop 4.7 на Windows Server 2019 и около сотни камер. Срок хранения — 90 дней для большинства камер и 14 дней для части офисных.

Однажды у LUN, подключённого как J:, появились ошибки SMART. Диск нужно было убирать, а на нём лежали 760 ГБ записей с 10 августа по 24 сентября.

Штатно Macroscop предлагает два пути:

1. Поставить диску роль «Резервный архив» — новое видео на него не пишется, старое удаляется по сроку хранения. С нашими 90 днями диск опустеет к середине декабря. Всё это время диск с ошибками остаётся единственным местом, где лежит архив этих дней.

2. Скопировать папку MacroscopArchive на новый диск при остановленном сервере и дать ему ту же роль. При скорости чтения сбойного LUN около 12 МБ/с это сутки простоя всей видеосистемы.

Свободного физического диска под замену не было, зато на томе E: (24 ТБ) свободно 16 ТБ. Нужен был третий путь: копировать на ходу и останавливать Macroscop только на переключение.

Как устроен архив Macroscop на диске

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

X:\MacroscopArchive\
├── media\<GUID камеры>\...\       — видео блоками до 64 МБ
├── db\PG_<версия>_...\           — индекс архива (PostgreSQL)
├── ConfigsBackups\<дата время>\  — копии конфигурации сервера
└── ArchiveLogicDrive.xml         — метка «это архивный диск Macroscop»

Несколько наблюдений, которые потом пригодились:

• Папки камер названы по GUID, а не по имени. Имя камеры можно найти в конфигурации сервера или в журнале ServerConfiguration.log, где каждая привязка канала записана как channelId: GUID(Имя).

• Конфигурация хранится в бинарном формате .NET BinaryFormatter. Для чтения сроков хранения, кодеков и ролей дисков я написал небольшой пассивный разборщик. Он только читает и ничего не исполняет.

• Роль диска («Архив», «Резервный архив», «Не используется», база данных) задаётся в Server.SrvConf, там же — минимальный свободный объём и предельный размер архива.

• В ConfigsBackups копии конфигурации копятся годами: Macroscop делает новую при каждом изменении настроек, а старые не удаляет. Второй набор копий лежит на системном диске, в C:\ProgramData\ConfigsBackups: туда Macroscop сам кладёт копию раз в 12 часов. Рабочая же конфигурация, по которой сервер работает сейчас, — в C:\ProgramData\MacroscopServerConfigs; её утилита не трогает никогда.

• После обновления Macroscop в db остаются папки старой версии PostgreSQL вместе с установленной службой и программой.

Главный принцип: не трогать Macroscop

Видеоархив — это доказательная база, а сервер видеонаблюдения должен работать круглосуточно. Поэтому с самого начала я установил для себя ограничения:

1. Никаких изменений в программе, базах и конфигурации Macroscop. Утилита читает его файлы, но не пишет в них. Роли дисков администратор меняет сам, в штатном клиенте.

2. Никакого реверса бинарников и протоколов. Только то, что видно на диске и в журналах.

3. Всё, что меняет диски или файлы, — только после подтверждения и с возможностью отката.

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

Следствие этих правил: утилита не может «заставить» Macroscop увидеть перенесённый архив. Она может только сделать так, чтобы диск с тем же содержимым оказался на прежнем месте. Этого, как выяснилось, достаточно.

Вывод сбойного диска без суток простоя

Идея простая: Macroscop видит архивный диск по букве и по файлу ArchiveLogicDrive.xml в корне. Значит, если создать на свободном томе виртуальный диск VHDX, скопировать туда содержимое старого диска и подключить его под той же буквой, для Macroscop ничего не изменится.

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

На нашем диске на 760 ГБ копирование при ~12 МБ/с шло около 18 часов, но всё это время сервер писал и показывал видео как обычно. Сам Macroscop был остановлен только на время переключения.

Два подвоха всплыли уже на практике:

• VHDX не подключается сам после перезагрузки. Если Macroscop стартует раньше, он не находит диск. Решение: утилита на время вывода переводит службу Macroscop в ручной запуск и создаёт задание Планировщика, которое при загрузке подключает VHDX (с повторами) и только потом запускает службу. При завершении или откате всё возвращается как было.

• Старый диск должен исчезнуть из системы. Иначе после перезагрузки Windows может вернуть ему букву. Поэтому он переводится в состояние «Вне сети», а не просто лишается буквы.

Ещё одна деталь — когда можно начинать. Перед копированием мастер проверяет, что на диск больше не пишут. Он читает роль диска из конфигурации: если стоит «Резервный архив», достаточно часа без новых записей, иначе мастер ждёт сутки — чтобы не принять тихую ночь на камерах с записью по движению за остановку записи. И сразу пишет, с какого времени перенос станет доступен. Это появилось после второго диска: первая версия просто писала «идёт запись» про диск, на который никто не писал уже 16 часов, и это сбивало с толку.

После проверки диск с новой меткой продолжает работать в роли «Резервный архив». Когда сроки хранения истекут и Macroscop сам удалит старые записи, диску можно поставить роль «Не используется» и нажать «Завершить вывод диска».

Что нашлось, когда мы посмотрели на архив целиком

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

Первый же полный отчёт показал вещи, которых в штатном клиенте не видно:

• «Тяжёлые» камеры. Одна камера писала около 25 ГБ в сутки — в разы больше медианной камеры сервера. Часто причина в старом кодеке (MPEG-4 Part 2 вместо H.264/H.265) или в завышенном битрейте, и отчёт показывает кодек рядом с объёмом.

• Потерянные камеры — 17 штук. Камеры, которые числятся в конфигурации, но не пишут, или от которых остался только архив. Им посвящён отдельный раздел ниже.

• Около 21 ГБ копий конфигурации в ConfigsBackups за несколько лет, на каждом диске с ролью базы.

• PostgreSQL 12, оставшийся после обновления Macroscop: служба, программа и папки старой базы.

Из последних двух пунктов выросла «Очистка мусора». Копии конфигурации — и на архивных дисках, и на системном — она прореживает по одному правилу: остаются не меньше 10 самых новых и все моложе 30 дней. Старые журналы и неиспользуемую базу она переносит в карантин, а PostgreSQL 12 удаляет его же деинсталлятором. Карантин — это папка на том же томе, поэтому перенос мгновенный. Любой набор можно вернуть одной кнопкой; через 14 дней утилита предложит удалить его окончательно.

Порядок в камерах

Утилита задумывалась для переноса дисков, но неожиданно пригодилась для другого: навести порядок в самих камерах.

За несколько лет камеры меняют, переносят и снимают, а в Конфигураторе они остаются. Каждая такая камера занимает лицензию, мешает в списке и создаёт впечатление, что «вон там у нас есть видео». Штатный клиент покажет «нет сигнала», если открыть именно эту камеру, но сводного списка «что у нас не пишет и почему» в нём нет.

Отчёт собирает такой список из трёх источников:

• конфигурация Macroscop (свежая копия из ConfigsBackups): какие камеры есть, включены ли они, пишется ли архив, срок хранения;

• журнал ServerConfiguration.log: какая камера к какому серверу привязана;

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

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

Самое полезное поле — «Архив хранится до»: дата последней записи плюс срок хранения камеры. По ней видно, когда камеру можно удалить, не потеряв записи, которые ещё могут понадобиться.

Из 17 камер первого отчёта большая часть оказалась снятыми или заменёнными. Администратор удалил их из Конфигуратора и освободил лицензии. Остальные стали поводом проверить камеры на месте.

Те же типы приходят в Zabbix: отдельные счётчики и триггер на появление новой потерянной камеры с её именем в тексте проблемы. Камера, которая перестала писать, обнаруживается на следующее утро, а не в тот день, когда понадобилась запись с неё.

Одна тонкость всплыла уже при уборке. Macroscop пишет список привязок в ServerConfiguration.log только при запуске службы, а перезапускают её редко. Камеры, которые только что удалили в Конфигураторе, в журнале ещё числятся, и отчёт показывал их как «удалена, остался архив» с нулевым объёмом. Теперь утилита сравнивает время копии конфигурации со временем списка привязок. Если камеру удалили после записи журнала и на дисках от неё ничего нет, в отчёт и в Zabbix она больше не попадает. Если же копия конфигурации старше журнала, по ней нельзя понять, удалили камеру или только что добавили, и камера остаётся в отчёте.

Несколько серверов, расписание и Zabbix

Отчёт по одному серверу полезен, но хотелось видеть оба сразу и не заходить туда руками.

Удалённый запуск без WinRM. Наши серверы в рабочей группе, без домена, и настраивать для утилиты WinRM с TrustedHosts не хотелось. Используется то, что есть на любом Windows Server «из коробки»:

1. Подключение к административной шаре \\сервер\C$ с учётными данными администратора.

2. Копирование туда консольной версии утилиты и настроек.

3. Разовое задание Планировщика от имени SYSTEM через schtasks /S, которое делает скан и кладёт результат в JSON.

4. Забирание результата и уборка за собой.

Пароли серверов хранятся зашифрованными DPAPI, под учётной записью того, кто их ввёл. Тем же путём работает и очистка на удалённом сервере. Результаты всех серверов складываются в один сводный отчёт, а камера, переехавшая с одного сервера на другой, перестаёт считаться потерянной.

Расписание. Утилита сама создаёт задание в Планировщике через его COM-API, чтобы пароль не попадал в командную строку. Для локального скана задание работает от SYSTEM. Для сводного — от имени администратора: у SYSTEM нет доступа к другим машинам в рабочей группе. После каждого скана короткая сводка дописывается в историю, и в отчёте появляется раздел «Динамика» с графиками по дням.

Быстрый повторный скан. На первом сервере отчёт иногда строился 18 минут, хотя утилита не читает видео, а только списки файлов. Время уходило на сотни тысяч папок фрагментов на iSCSI-дисках: пока сведения о них в памяти Windows, скан идёт быстро, а после суток записи они вытеснены и каждую папку приходится читать заново. Решение — свой кэш: закрытый фрагмент старше двух суток уже не меняется, и если время изменения его папки то же, что в прошлый раз, его итоги берутся из кэша без открытия папки. Три самых свежих фрагмента каждой камеры перечитываются всегда, а раз в неделю кэш строится заново. С кэшем из примерно 2,5 тысячи папок каждого диска читается только около 600, и скан всех 21 диска занимает 30–60 секунд вместо 18 минут.

Zabbix. Каждый скан пишет metrics.json в %ProgramData%\MacroscopArchiveTool. Агент Zabbix читает его одним UserParameter, никаких скриптов на стороне агента нет:

UserParameter=macroscop.metrics,type "C:\ProgramData\MacroscopArchiveTool\metrics.json"

Шаблон для Zabbix 7.0 делает один мастер-элемент, зависимые метрики и обнаружение дисков. Триггеры срабатывают, если диск переполняется, появилась потерянная камера или скан давно не запускался. В тексте проблемы сразу видны имена камер. Шаблон и инструкция лежат в папке zabbix/ репозитория.

Итоги и ограничения

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

Что нужно знать, прежде чем пробовать у себя:

• Проверено на Macroscop 4.7 с лицензией LS и Windows Server 2019. В других версиях формат архива и конфигурации может отличаться. Если утилита что-то не распознает, она покажет это в отчёте, а не упадёт.

• Это не официальный инструмент. Разработчики Macroscop его не проверяли, и вывод диска лучше сначала попробовать на некритичном диске.

• Нужно свободное место под целиковую копию выводимого диска на другом томе.

• Исполняемые файлы пока не подписаны, поэтому при первом запуске покажется SmartScreen. Сборка идёт в GitHub Actions из открытого кода, а к каждому релизу приложены контрольные суммы SHA-256.

Проект открыт под лицензией MIT: github.com/D3vil787/MacroscopArchiveTool. Там же готовая сборка, шаблон Zabbix и формы для сообщений об ошибках. Буду рад отзывам от тех, у кого другие версии Macroscop или другая схема дисков. И если вы решали ту же задачу по-другому, расскажите в комментариях.