Архив видеонаблюдения на NAS: сначала проверяем, сможет ли хранилище нормально записывать и отдавать видео

Поэтому начинать с вопроса «какой NAS купить?» рано. Сначала определяем роль NAS: он будет самостоятельным сервером записи с VMS-пакетом, удалённым хранилищем для другой системы или дополнительной копией архива. Это три разные архитектуры и у них разные требования к совместимости, сети и восстановлению.

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

1. Кто именно записывает видео

В одном проекте камеры добавляются непосредственно в VMS, работающую на NAS. В другом запись ведёт NVR или сервер, а NAS используется как отдельное хранилище или место для второй копии. Фраза «писать камеры на NAS» сама по себе не описывает схему.

Перед расчётом фиксируем:

• точные модели камер и их кодеки;

• каким ПО будет управляться запись;

• поддерживается ли конкретная камера выбранной VMS и какие функции доступны;

• сколько основных и дополнительных потоков реально потребуется;

• кто отвечает за расписание записи, события, ротацию архива и экспорт.

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

2. Какой поток NAS должен принять и отдать

Ёмкость дисков — только одна часть расчёта. NAS одновременно принимает видеопотоки, пишет их на диски, обслуживает поиск и воспроизведение, иногда экспортирует фрагменты и выполняет другие задачи.

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

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

3. Что произойдёт при отказе

RAID не заменяет резервную копию и сам по себе не отвечает на вопрос, что произойдёт с видеозаписью при отказе NAS, сети, питания, диска или приложения записи.

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

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

Но NAS не является автоматически лучшей заменой NVR. Для небольшой системы специализированный регистратор может оказаться проще в эксплуатации. Для большой или нагруженной системы может потребоваться серверная архитектура. Решение принимаем после сравнения не названий устройств, а четырёх вещей: совместимость, нагрузка, восстановление и ежедневная работа с архивом.

Если хранилище уже установлено, начинаем с инвентаризации.

Нужны:

• производитель и точная модель NAS;

• версия операционной системы и приложения видеонаблюдения;

• процессор и объём памяти;

• число и тип сетевых интерфейсов;

• состав дисков и текущая дисковая группа;

• свободная и полезная ёмкость;

• точные модели камер;

• текущие разрешение, FPS, кодек и битрейт;

• глубина архива, которая нужна заказчику;

• другие сервисы, работающие на NAS.

После этого не «угадываем по характеристикам», а собираем контрольный контур. Подключаем одну или несколько типовых камер, проверяем непрерывную запись, события, поиск, воспроизведение и экспорт. Если схема проходит пилот, масштабируем расчёт на весь объект.

Для предварительной оценки можно считать объём от суммарного битрейта и времени записи. Но проектное значение уточняем по реальным настройкам камер и режиму записи.

На результат влияют:

• битрейт и его изменение в реальной сцене;

• непрерывная или событийная запись;

• число потоков;

• срок хранения;

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

• резерв свободного пространства и требования конкретной VMS.

Поэтому обещание «этого NAS хватит на N дней» без исходных потоков и режима записи не принимаем как расчёт.

Если задача только в определении глубины архива и ёмкости, основной материал — /uslugi/arhiv-videonablyudeniya. При выборе NAS отдельно проверяем: может ли NAS быть рабочим узлом записи или хранения и как это проверить.

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

Уровень RAID выбирают не по принципу «чем больше номер, тем лучше». Нужны требования к полезной ёмкости, допустимому отказу дисков, времени восстановления и производительности конкретной платформы.

Подробная инженерная задача дисковой отказоустойчивости вынесена в /uslugi/videonablyudenie-raid. Здесь RAID рассматривается только как часть NAS-архитектуры.

У NAS есть минимум два разных сетевых сценария: постоянный входящий поток от камер и чтение архива пользователями. На объекте к ним могут добавиться резервное копирование и другие сервисы.

Проверяем:

• где проходят видеопотоки;

• нет ли узкого места на аплинке;

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

• что происходит во время экспорта;

• не конкурирует ли видеозапись с тяжёлой файловой или резервной нагрузкой;

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

Обозначение «1G» или «10G» в характеристиках порта само по себе не является доказательством достаточной производительности всей системы. Нужен расчёт конкретных потоков и проверка выбранного NAS.

Для NAS с собственной системой видеонаблюдения проверяем не только факт добавления камеры. Нужны функции, которые реально используются на объекте: основной поток, дополнительный поток, звук, события, PTZ, запись на самой камере или другие возможности — только если они нужны и поддерживаются конкретной связкой.

Например, Synology публикует отдельный список совместимости камер и указывает, какие интегрированные функции доступны для конкретных моделей. QNAP также публикует требования и совместимость своих QVR-решений. Поэтому в проекте не пишем «любая ONVIF-камера будет работать полностью».

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

Система считается принятой только после проверки пользовательского сценария.

Берём контрольное событие и:

1. убеждаемся, что нужная камера действительно записывалась;

2. находим фрагмент по времени;

3. воспроизводим его без повреждения;

4. проверяем синхронность времени, если событие нужно сопоставлять между несколькими камерами;

5. экспортируем фрагмент;

6. открываем экспортированный файл на отдельном клиенте;

7. проверяем права пользователя, которому архив нужен в работе.

Отдельно выполняем согласованный отказный тест. Его состав зависит от архитектуры: например, перезапуск сервиса или NAS, кратковременное отключение сетевого пути, проверка восстановления записи и контроль состояния дисковой группы. Разрушительные тесты без согласования не проводятся.

После работы у владельца системы должна быть не только доступная папка с видео.

Фиксируем:

• роль NAS в архитектуре;

• список камер и способ их подключения;

• параметры записи;

• расчёт требуемой ёмкости;

• схему дисковой группы;

• сетевой путь записи;

• правила доступа;

• понятный способ поиска и экспорта;

• известные ограничения;

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

Так следующий специалист сможет понять систему без перебора настроек вслепую.

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

В таком случае сравниваем альтернативы: NVR, отдельный видеосервер, другой NAS/VMS или комбинированную схему. Цель — не продать конкретный класс оборудования, а получить архив, которым можно воспользоваться после реального события.

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

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

Стоимость формируется после выбора роли NAS, количества потоков, объёма хранения, дисковой схемы, сетевой части, лицензий выбранного ПО — если они требуются — и объёма настройки. До проверки конкретной платформы стоимость лицензий и оборудования не фиксируем.