Калькулятор хранения CCTV: математика ретенции

Коротко

Хранение видеонаблюдения – это одно умножение: поток данных каждой камеры, умноженный на число камер, на часы записи в сутки и на число дней, которые вы храните запись. Из этих четырёх чисел именно срок хранения – ретенция – обычно решает итоговый счёт, потому что это прямой множитель, а остальные три ограничены физикой. Сырые терабайты из формулы – это не те диски, которые вы покупаете: избыточность, накладные расходы файловой системы и запас свободного места добавляют примерно 40–60% сверху, прежде чем систему можно безопасно запускать. Эта статья показывает арифметику вслух, называет рычаги, которые реально двигают цифру, и разделяет объём, который вы обязаны хранить (минимумы по делу и закону), и объём, который вам разрешено хранить (максимум по закону о приватности).

Зачем это нужно

Хранение – это то, куда тихо уходят бюджеты на видеонаблюдение, и это единственный расчёт, который почти каждый первый проект делает неправильно. Недооцените его – система перезапишет запись прежде, чем кто-то её посмотрит, или диски заполнятся и запись молча остановится. Переоцените – потратите десятки тысяч долларов на терабайты, которые никогда не наполнятся полезным. Это руководство – для системного интегратора, менеджера продукта или руководителя эксплуатации, которому нужно рассчитать систему, согласовать смету или поговорить с инженером о том, почему строка «хранение» такая большая, и который хочет понимать цифру, а не доверять чужому калькулятору. Технических знаний не требуется: каждая формула разобрана в простых числах.

Одна формула, на которой держится вся система

Всё, что связано с хранением видеонаблюдения, сводится к одному уравнению. Программа, которая принимает и записывает потоки многих камер – система управления видео (Video Management System, или VMS) – по сути своей машина, превращающая непрерывный поток данных в гору файлов. Поэтому начинать надо с этого потока.

Камера отправляет не «картинки». Она отправляет сжатый видеопоток, измеряемый в битрейте – числе бит данных в секунду, в мегабитах в секунду (Mbps). Камера на 4 Mbps выдаёт четыре миллиона бит видео каждую секунду, весь день, смотрит на неё кто-нибудь или нет. Это число, умноженное на время, и есть ваш объём хранения.

Вот пересчёт, который делает всю работу. Один мегабит в секунду, записываемый непрерывно сутки, даёт вполне предсказуемый объём:

1 Mbps  ×  (1 байт / 8 бит)  ×  86 400 секунд/сутки  =  10 800 мегабайт/сутки  =  10,8 ГБ/сутки

Эта константа – 10,8 гигабайта в сутки на каждый 1 Mbps непрерывного видео – самое полезное число в хранении видеонаблюдения. Запомните его, и любую систему можно прикинуть в уме. Камера на 4 Mbps круглосуточно даёт около 4 × 10,8 ≈ 43 ГБ в сутки. Полная формула системы – это то же самое, только в масштабе:

Объём (ГБ) = битрейт (Mbps) × 10,8 × камеры × дни хранения × коэф. записи

Коэффициент записи – это доля суток, когда камера реально пишет на диск: 1,0 при постоянной записи, ниже – если писать только по движению (об этом ниже). Разделите результат на 1 000, чтобы получить терабайты (ТБ). Вся статья, в сущности, – это обход этих пяти входов и ответ на вопрос, какой из них тянуть, когда цифра слишком велика.

Нажмите, чтобы увеличить

Что задаёт битрейт: разрешение, частота кадров и кодек

Битрейт – не свободный выбор: его в основном задают три вещи, и понимание их показывает, откуда на самом деле берутся данные.

Разрешение – сколько пикселей в каждом кадре. Камера 1080p (она же 2 мегапикселя, 2 MP) имеет около двух миллионов пикселей в кадре; 4 MP – вдвое больше; 4K (8 MP) – вчетверо. Больше пикселей – больше данных для сжатия, поэтому разрешение поднимает битрейт примерно пропорционально.

Частота кадров в кадрах в секунду (FPS) – сколько изображений в секунду снимает камера. Видеонаблюдению редко нужны 30 FPS вещательного видео; 12–15 FPS – обычная и читаемая величина, а переход с 30 на 15 FPS примерно вдвое снижает битрейт. Лицо у двери или номер на въезде прекрасно фиксируются и при 15 FPS.

Кодек – это метод сжатия, алгоритм, который ужимает видео перед передачей. Это рычаг, который большинство упускает. Старый стандарт H.264 годами был умолчанием в видеонаблюдении. Новый H.265 (он же HEVC) сжимает ту же картинку примерно вдвое меньше при том же качестве – вендоры обычно называют снижение битрейта на 30–50%. Мы не будем здесь заново разбирать устройство кодеков; это разобрано в разделе про видеокодирование. Для планирования хранения правило простое: перевод системы с H.264 на H.265 может почти вдвое срезать счёт за хранение – бесплатно.

Вот реалистичные диапазоны битрейта при постоянной записи по разрешению и кодеку, актуальные для камер 2026 года при типичной для видеонаблюдения частоте (15–30 FPS). Сложность сцены и движение их сдвигают – оживлённая улица идёт у верхней границы, тихий коридор – у нижней.

Последний столбец читайте как предупреждение: одна непрерывно пишущая 4K-камера может съедать 100 ГБ в сутки. Разрешение и кодек – два рычага, которые задают величину расхода на одну камеру до того, как ретенция умножит её на всю систему.

Нажмите, чтобы увеличить

Разбор примера: 40 камер по шагам

Цифры делают это наглядным. Возьмём средний объект: 40 камер, по 4 MP, постоянная запись в H.265 при типичных 2 Mbps. Рассчитаем в три шага, вслух.

Шаг 1 – суточный объём на одну камеру. Умножаем битрейт на нашу константу:

2 Mbps × 10,8 = 21,6 ГБ на камеру в сутки

Шаг 2 – сырой объём для всей системы при выбранном сроке. Умножаем на камеры и на дни хранения. Пусть объект хранит 30 дней:

21,6 ГБ × 40 камер × 30 дней = 25 920 ГБ ≈ 26 ТБ (сырых)

То есть 40 камер, месяц непрерывной записи – это около 26 терабайт сырого видео. Это та цифра, которую вам выдаёт любой онлайн-калькулятор, – и это не та, что вы покупаете. Запомните это до раздела про запас.

Шаг 3 – увидеть рычаг ретенции. Оставим те же 40 камер и поменяем только срок хранения:

 7 дней  →  21,6 × 40 ×  7   ≈   6 ТБ
30 дней  →  21,6 × 40 × 30   ≈  26 ТБ
90 дней  →  21,6 × 40 × 90   ≈  78 ТБ
365 дней →  21,6 × 40 × 365  ≈ 315 ТБ

Те же камеры, то же качество, всё то же – а объём прыгает с 6 ТБ до 315 ТБ исключительно из-за того, как долго вы храните запись. В этом весь смысл следующего раздела.

Почему срок хранения – главный драйвер стоимости

Посмотрите снова на четыре входа формулы. Три из них ограничены. Разрешение упирается в то, что поддерживает камера, и в то, что вам реально нужно видеть. Частота кадров имеет разумный потолок – после 15–20 FPS для видеонаблюдения толку мало. Число камер задано зданием. Срок хранения – единственный вход без естественного потолка: ничто физически не мешает хранить год или три, и каждый лишний день добавляет тот же кусок объёма, что и предыдущий.

Это делает ретенцию линейным множителем: удвойте дни – удвоите объём и эту часть счёта. Переход с 30 на 90 дней утраивает хранение. Переход на полный год умножает его примерно в двенадцать раз. В облаке, где хранилище арендуют помесячно, эффект тот же – месячная плата растёт прямо со сроком, поэтому политика «хранить год» стоит примерно в двенадцать раз дороже политики «хранить месяц» – всегда.

Нажмите, чтобы увеличить

Поэтому первый вопрос в любой оценке хранения – не «сколько камер?», а «сколько дней и почему именно столько?». Большинство команд берут срок по привычке – «пусть будет 30 дней» – не проверяя, не равен ли реальный минимум 7 или 90 дням. Именно это решение двигает счёт за хранение сильнее любого выбора железа.

Режим записи: самый большой рычаг под вашим контролем

Коэффициент записи в формуле – доля суток, когда камера пишет на диск, – это место, где прячется самая значимая экономия, и оно полностью в ваших руках.

Постоянная запись пишет каждый кадр весь день, коэффициент = 1,0. Это безопасное умолчание и единственный режим, который гарантирует, что вы ничего не пропустите. Он же самый дорогой, и для многих камер избыточен: камера на разгрузочной рампе, где активность два часа в сутки, пишет 22 часа пустоты.

Запись по движению пишет только при изменении в кадре. Запись по событию или аналитике пишет только при срабатывании правила – пересечена линия, вошли в зону, обнаружен автомобиль. Оба режима могут срезать объём на 50–80% на камерах со статичными сценами, потому что коэффициент записи падает до доли суток, когда что-то реально происходит. Камера, пишущая 4 активных часа вместо 24, имеет коэффициент около 0,17 – примерно шестую часть стоимости постоянной записи.

Загвоздка в том, чем вы за это платите. Запись по движению может упустить секунды до момента обнаружения (хорошие системы держат буфер в несколько секунд до события, чтобы это исправить) и может ошибаться как в большую сторону (дождь, фары, качающиеся ветки), так и в меньшую (медленный, малоконтрастный нарушитель). Большинство реальных систем смешивают режимы: постоянная запись на входах и кассах, что важнее всего, движение или событие – по периметру и в подсобках. Полный разбор компромиссов – в нашей статье про стратегии записи; здесь же важно, что коэффициент записи – реальный и большой рычаг, часто больший единичный выигрыш, чем кодек.

От сырых терабайтов к дискам, которые вы покупаете

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

Избыточность (RAID). Хранение видеонаблюдения почти всегда строят на RAID – избыточном массиве независимых дисков, который распределяет данные по нескольким дискам, чтобы система пережила отказ диска без потери записи. Избыточность – не свободное место; это место, за которое вы платите и в которое нельзя писать видео. Два частых уровня для видеонаблюдения:

• RAID 5 жертвует на чётность эквивалент одного целого диска. В массиве из пяти дисков вы теряете около 20% сырой ёмкости и переживаете отказ одного диска.
• RAID 6 жертвует эквивалент двух дисков, переживая два одновременных отказа – более безопасный выбор для крупных массивов, где второй диск часто отказывает во время напряжённой перестройки после первого. На малом массиве это большой процент; на крупном – умеренная страховка.

Массивы с чётностью несут и небольшой штраф на запись (примерно на 5–10% медленнее), потому что чётность пересчитывается при каждой записи, – а это важнее, чем кажется, как мы увидим.

Накладные файловой системы и форматирования. Отформатированный диск никогда не отдаёт под файлы всю номинальную ёмкость – несколько процентов уходит самой файловой системе.

Запас свободного места. Записывающий массив не гоняют до 100% заполнения. Системы видеонаблюдения пишут непрерывно, и им нужно место для работы; стандартная практика – рассчитывать так, чтобы массив был заполнен не более чем на 80%, оставляя запас для индексации, всплесков и того дня, когда вы добавите камеры. Запись на файловую систему «под завязку» провоцирует повреждения и потерю кадров.

Сложите это, и появляется практическое правило: закладывайте примерно 1,4–1,6× от вашей цифры сырого видео в закупаемой ёмкости (точный множитель зависит от уровня RAID и размера массива). Наш пример в 26 ТБ сырых превращается примерно в 39 ТБ с запасом при множителе 1,5 – и это до всякого запаса на рост. Арифметика, вслух:

26 ТБ сырых  ÷  эффективность RAID 6 (~0,75 на массиве из 8 дисков)  ≈  35 ТБ
35 ТБ        ×  ~1,1 (файловая система + запас)                       ≈  39 ТБ с запасом

Нажмите, чтобы увеличить

«Частая ошибка: размер под ёмкость, а не под устойчивую запись. Видеонаблюдение – необычная нагрузка для хранилища. Большинство IT-хранилищ читают много и всплесками; записывающий массив делает наоборот – пишет 40 потоков на диск каждую секунду каждых суток вечно, а читает лишь когда кто-то смотрит запись. Диск, рассчитанный на то, чтобы вместить данные, может всё равно не успевать их записывать, молча теряя кадры. Всегда рассчитывайте на устойчивую скорость записи, а не только на ёмкость, используйте диски, рассчитанные на круглосуточную запись для видеонаблюдения, и помните, что перестройка RAID после отказа диска нагружает массив ровно тогда, когда запись может понадобиться по инциденту. Ёмкость – это заголовок; устойчивая запись – то, что сохраняет запись.»

Сколько хранить? Два предела

Ретенция – главный драйвер стоимости, поэтому «сколько дней?» заслуживает настоящего ответа, а не привычки. Честная рамка такова: у ретенции два разных предела, тянущих в противоположные стороны, и ваша политика живёт в окне между ними. (Это инженерное руководство, а не юридический совет – уточняйте конкретные требования для вашей отрасли и региона у квалифицированного юриста.)

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

Это распространённая практика, а не всеобщий закон – точное требование зависит от вашей юрисдикции и отрасли, и для части регулируемых записей (некоторые банковские и гейминговые) сроки куда больше. Урок для расчёта хранения: зафиксируйте реальный минимум до расчёта, потому что разница между 30 и 90 днями утраивает диски.

Верхний предел – сколько вам разрешено хранить. В регионах с законами о приватности закон задаёт максимум, а не только минимум. По европейскому Общему регламенту о защите данных (GDPR, Регламент (ЕС) 2016/679) узнаваемое видео людей – это персональные данные, а статья 5(1)(e), принцип «ограничения хранения», требует хранить их не дольше, чем необходимо для цели. Руководящие принципы Европейского совета по защите данных EDPB Guidelines 3/2019 о обработке персональных данных через видеоустройства делают это конкретным: запись «в большинстве случаев следует удалять, в идеале автоматически, через несколько дней», и «чем дольше установленный срок хранения (особенно сверх 72 часов), тем больше обоснования законности цели и необходимости хранения требуется привести». Их пример: небольшому магазину, который заметил бы вандализм в тот же день, достаточно срока хранения в 24 часа.

То есть в ЕС небрежное «храним всё год» не просто дорого – это может быть незаконно, если вы не можете обосновать необходимость. Максимум по приватности и минимум по делу могут даже столкнуться, и тогда закон ограничивает политику. Детали законного хранения и удаления – в наших статьях про политику хранения и GDPR для видеонаблюдения; для планирования хранения вывод такой: кратчайший законный и операционно достаточный срок обычно и есть самый дешёвый дизайн, а закон о приватности часто тянет эту цифру вниз.

Нажмите, чтобы увеличить

Где тут стандарты: ONVIF Profile G и IEC 62676

Хранение – это в основном арифметика, но два стандарта определяют, как записанное видео управляется и извлекается, и их упоминание спасает систему от вендорской привязки.

ONVIF Profile G – открытый стандарт записи и извлечения. ONVIF – это общий язык, на котором камеры и записывающее ПО разных производителей понимают друг друга; профили делят этот язык по задачам. Profile G отвечает именно за запись видео на устройство и за его поиск и воспроизведение – поэтому VMS и регистратор с поддержкой Profile G могут хранить и доставать запись без проприетарной привязки. Помните, однако, правило видеонаблюдения: ONVIF гарантирует базовый уровень, на котором сходятся оба устройства, а не полный паритет функций – продвинутый поиск или извлечение по тегам аналитики может всё равно требовать ПО вендора. Систему профилей мы подробно разбираем в ONVIF для инженеров, а коммерческий обзор – в гайде Фора Софт про профили ONVIF в системах безопасности.

IEC 62676 – международный стандарт на системы видеонаблюдения для приложений безопасности. Его части охватывают системные требования (62676-1), передачу видео (62676-2) и рекомендации по применению (62676-4, актуальная редакция 2025 года) – рамка, по которой серьёзная система специфицирует и проверяет хранение и запись, а не просто покупает диски. Сам стандарт вы будете читать редко, но смета со ссылкой на него – это смета, построенная надолго.

Где здесь Фора Софт

Расчёт хранения – это место, где продукт видеонаблюдения либо выдерживает реальную нагрузку, либо тихо проваливается, и это прямо наша работа. Фора Софт строит видеостриминг, real-time-видео и системы компьютерного зрения с 2005 года – более 250 выпущенных проектов – а видеонаблюдение лежит на пересечении всех трёх. Когда мы строим или дорабатываем VMS, мы рассчитываем хранение под устойчивую запись при постоянной нагрузке, а не только под номинальную ёмкость, и зашиваем политику хранения в систему так, чтобы максимум по приватности и минимум по делу соблюдались автоматически, а не оставались в таблице. Привычка «точность против нагрузки» применима и здесь: дизайн хранения, выглядящий хорошо на бумаге, но теряющий кадры во время перестройки RAID, – это не дизайн, и мы тестируем плохой день, а не день из брошюры.

Ключевые выводы

• Объём = битрейт (Mbps) × 10,8 × камеры × дни хранения × коэф. записи; 10,8 ГБ/сутки на 1 Mbps – число, которое стоит запомнить.
• Срок хранения – главный драйвер стоимости: линейный множитель без потолка; год требует ~12× месяца тех же камер.
• H.265 примерно вдвое снижает битрейт H.264 при равном качестве – часто бесплатный способ срезать счёт вдвое.
• Запись по движению/событию режет объём на 50–80% на статичных сценах, снижая коэффициент записи.
• Сырые терабайты – не покупаемая ёмкость: добавьте ~40–60% на RAID, форматирование и запас под правило 80%.
• У ретенции два предела: минимум по делу/закону и максимум по приватности (GDPR ст. 5(1)(e); норма EDPB ~72 часа).

Что почитать дальше

• Стратегии записи: постоянная, по движению, по событию и по расписанию
• Локальная архитектура хранения: NVR, SAN, NAS и RAID
• Модель стоимости видеонаблюдения: во что обходится система