Почему архив и хранение резко увеличивают цену CCTV?

Объём архива считается не по разрешению, а по битрейту и времени. Приложение 2 к Правилам функционирования Национальной системы видеомониторинга (приказ Председателя КНБ РК от 27.10.2020 № 69-қе) задаёт нижнюю границу: разрешение не ниже 1920×1080, 25 кадров в секунду и битрейт не менее 5000 кбит/с. Дальше работает простая арифметика, и она не зависит от бренда камеры.

Ключевой момент, который ломает привычную логику экономии: 5000 кбит/с — это не «рекомендация», а минимум для объектов, подключаемых к НСВМ. Аргумент «пережмём кодеком H.265 и уложимся вдвое» здесь не работает — норма фиксирует нижнюю границу потока, ниже которой опускаться нельзя. Экономить можно на сроке хранения по зонам и на числе камер с максимальной детализацией, но не на битрейте магистральных камер. Требования к самому сроку хранения — отдельный разговор, мы разбирали его в материале о том, сколько дней реально нужно хранить видеоархив.

Полезный объём и объём закупки — разные числа, и разрыв между ними больше, чем ожидает заказчик. На 97,2 ТБ архива уходит около 160 ТБ дисков, то есть на каждый терабайт записи закупается примерно 1,65 ТБ «железа». Разница складывается из трёх слагаемых: чётность RAID, горячий резерв и запас ёмкости под пики битрейта.

Разберём на массиве из дисков по 16 ТБ:

• RAID-6 из 9 дисков. Полезная ёмкость — (9 − 2) × 16 = 112 ТБ. Два диска уходят под контрольные суммы, это плата за возможность пережить отказ двух накопителей одновременно.
• Запас ёмкости. 112 ТБ против потребности 97,2 ТБ — запас 15,2 %. Он не роскошь: битрейт «плавает», и на сцене с движением камера пишет заметно выше среднего.
• Горячий резерв. Ещё один диск, который не хранит ничего, пока не откажет соседний. Итого 10 дисков × 16 ТБ = 160 ТБ закупки.

Сюда же добавляется расхождение единиц: производитель считает терабайты десятичными, операционная система — двоичными. Массив на 112 ТБ отобразится как 101,9 ТиБ. Это не потеря данных и не обман, но около 9 % «недостачи» на экране, из-за которых расчёт без поправки регулярно не сходится с фактом.

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

Видеоархив — самая тяжёлая нагрузка на диск из бытовых сценариев, потому что запись идёт непрерывно, и средняя нагрузка здесь равна пиковой. Посчитаем годовой объём записи на один накопитель массива: 54 ГБ/сутки × 365 = 19,71 ТБ в год с камеры; 60 камер дают 1182,6 ТБ. В RAID-6 из 9 дисков на каждые 7 блоков данных пишется 9 блоков, то есть физически на массив ложится 1182,6 × 9 ÷ 7 = 1520,5 ТБ в год, или 168,9 ТБ на каждый диск.

Теперь сравним с паспортом. Накопители класса surveillance рассчитаны на 180 ТБ записи в год (Seagate, техническая спецификация SkyHawk Surveillance HDD), настольные модели — на 55 ТБ в год (Seagate, техническая спецификация BarraCuda). То есть наш массив работает на 94 % расчётного ресурса surveillance-диска и превышает ресурс настольного втрое. Отсюда практический вывод: подмена дисков «такими же по объёму, но дешевле» — не экономия, а перенос затрат на первый год эксплуатации.

Второй фактор — время восстановления. При отказе диска на 16 ТБ массив перестраивается, продолжая писать. Если принять эффективную скорость восстановления 100 МБ/с (реалистично при параллельной записи), то 16 000 000 МБ ÷ 100 МБ/с ≈ 160 000 с, то есть около 44 часов. Почти двое суток массив живёт с пониженной защитой — именно поэтому мы закладываем RAID-6, а не RAID-5, и держим горячий резерв.

Сеть под видеонаблюдение проектируется не по числу портов, а по постоянному потоку. 60 камер по 5 Мбит/с дают 300 Мбит/с записи — это 30 % гигабитного аплинка, занятые круглосуточно, без единого пользователя на просмотре. Добавьте живой просмотр: при допущении, что оператор держит 8 потоков, это ещё около 40 Мбит/с, и загрузка подходит к 340 Мбит/с.

Отдельно считается выгрузка архива — сценарий, о котором вспоминают только при инциденте. Сутки записи с одной камеры — 54 ГБ. По каналу 100 Мбит/с (12,5 МБ/с) выгрузка займёт 54 000 МБ ÷ 12,5 = 4320 секунд, то есть примерно 1,2 часа на одну камеру за одни сутки. Если следствию нужны трое суток по четырём камерам, счёт идёт на смену работы инженера.

Практические следствия для сметы:

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

Именно на этом узле чаще всего вскрывается разрыв между красивым коммерческим предложением и рабочей системой: камеры в КП есть, а сети и хранения под них — нет. Мы подробно разбирали, из чего складывается реальная цена системы безопасности.

Кроме дисков в бюджете хранения живут ещё четыре строки, и каждая из них масштабируется вместе с числом камер. Сервер записи, лицензии видеоменеджмента, источники бесперебойного питания и сам монтаж серверного узла — это то, что не видно в строке «камера, шт.», но что определяет, доживёт ли архив до момента, когда он понадобится.

Строку по ИБП стоит выделить особо. Автономность не менее 60 минут по Приложению 2 к Правилам НСВМ бессмысленна, если резерв рассчитан только на камеры: при отключении питания камеры продолжат снимать, а писать будет некуда. Сервер, дисковый массив и коммутаторы доступа — это основная часть нагрузки, и именно её обычно недооценивают. Сюда же примыкает выбор между наращиванием существующего узла и его заменой — мы разбирали, когда выгоднее модернизация, а когда полная замена.

Стоимость хранения растёт линейно сроку: удвоили срок — удвоили объём и число дисков. Минимум в 30 суток задан постановлением Правительства РК от 06.05.2021 № 305 и Приложением 2 к Правилам НСВМ, но службы безопасности часто просят больше — и вот как это выглядит в дисках при той же геометрии массива (9 дисков RAID-6 + 1 горячий резерв, 112 ТБ полезных на массив).

Второй множитель — битрейт. Объём зависит от фактического потока камеры, а не от числа мегапикселей напрямую: переход на более высокое разрешение поднимает битрейт, но насколько — видно только в спецификации конкретной модели. Поэтому считать архив «по мегапикселям» некорректно; берите паспортный поток при заданных разрешении, частоте кадров и кодеке. О том, что на практике важнее в самой камере, мы писали в разборе мегапикселей, объектива, света и WDR.

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

Что мы проверяем перед закупкой:

• Зоны разнесены по задачам. Идентификация (250 пикс/м) нужна на входах и кассах, обнаружение (50 пикс/м) — на периметре и складе. Пороги 50 / 150 / 250 пикс/м заданы Приложением 2 к Правилам НСВМ.
• Срок хранения задан по зонам, а не «всем 90 суток». Разница между 30 и 90 сутками в нашем примере — 20 дисков.
• Битрейт взят из паспорта камеры, а не из маркетингового «до». Расчёт по среднему потоку без запаса — самая частая причина, почему архив «не докручивает» до заявленных суток.
• Учтён формат ТиБ/ТБ. Поправка ~9 % между этикеткой диска и показаниями ОС заложена в расчёт.
• Диски — surveillance или enterprise класса, с проверенным паспортным ресурсом записи в ТБ/год под фактическую нагрузку.
• Резервирование посчитано целиком: питание, сеть, сервер, архив. Отказ любого из четырёх узлов означает потерю записи, а не «деградацию качества».
• Второй экземпляр для критичных камер. RAID-6 не заменяет копию — для доказательной записи нужен отдельный носитель.
• Расширение заложено заранее. Свободные отсеки в корзине и запас портов дешевле, чем второй сервер через год.

Ещё один способ не переплатить — не покупать избыточность «на всякий случай»: массив под 90 суток при фактической потребности в 30 замораживает деньги в дисках, которые начнут стареть раньше, чем понадобятся. Мы разбирали этот эффект в материале о том, где заказчик переплачивает за «решение с запасом».

Недооценка хранения проявляется не в момент закупки, а в момент, когда запись понадобилась. Система при этом работает, картинка на мониторе есть, камеры исправны — а нужного фрагмента в архиве нет. По нашему опыту на объектах это происходит по четырём типовым сценариям, и все они закладываются ещё на стадии сметы, когда архив считают «остаточным» узлом.

• Глубина архива меньше заявленной. Расчёт вели по среднему битрейту, фактический поток оказался выше — массив переполняется и затирает старые записи раньше срока. Формально система есть, требование о хранении не менее 30 суток по постановлению Правительства РК № 305 не выполняется.
• Отказ узла, который не резервировали. Массив пережил отказ двух дисков, но встал сервер записи или коммутатор агрегации. Запись прекращается целиком, и отсутствие резерва по одному узлу обнуляет резервирование по трём остальным.
• Пропадание питания. Камеры на ИБП, сервер — нет. При отключении питания архив обрывается на первой же минуте, хотя требование автономности не менее 60 минут по Приложению 2 к Правилам НСВМ формально «закрыто» резервом на камерах.
• Перегруженные диски. Настольные накопители под нагрузкой в 168,9 ТБ в год против паспортных 55 ТБ/год начинают сыпаться в первый же год, причём одновременно — они куплены одной партией и работают в одинаковом режиме.

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