Облачное и гибридное хранение видеонаблюдения

Коротко

Вынос записи видеонаблюдения в облако решают две вещи, которых не видно в цене за гигабайт: канал отдачи (upload), нужный чтобы вытолкнуть непрерывное видео из здания, и плата за egress и извлечение, которую вы отдаёте, чтобы вернуть эту запись, когда её потребует расследование. Писать каждую камеру прямо в облако упирается в жёсткую стену, потому что скромный объект на 40 камер требует около 80 Mbps устойчивой отдачи круглые сутки, чего большинство бизнес-каналов дать не могут. Поэтому почти любой серьёзный «облачный» продукт видеонаблюдения на деле гибридный: локальное устройство держит свежую запись и нагрузку записи на площадке, а наверх идут лишь события, клипы и прореженный бэкап – и отдача падает с десятков мегабит до нескольких. Облако оправдывает себя для резервной копии вне площадки, управления многими объектами и эластичного перелива, но байты, которые системе могут срочно понадобиться, остаются рядом, а где видео физически приземляется – это решение о приватности не меньше, чем о деньгах.

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

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

Одна мысль: ценник – это хранение; счёт – это полоса

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

Поэтому честно думать про облачное хранение видеонаблюдения так: сначала забыть про цену за гигабайт и задать два других вопроса. Сможет ли объект физически вытолкнуть столько видео наверх – весь день, каждый день? – это стена отдачи. Во что обойдётся вернуть видео, когда оно понадобится, и как быстро? – это ловушка egress и извлечения. Цена за гигабайт реальна, но обычно она наименьшая из трёх чисел, а два больных – те, что на витрине прайса идут последними. Дальше статья проходит все три, затем показывает гибридный паттерн, которым почти любая реальная система из-под них выбирается.

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

Три способа вынести видеонаблюдение в облако

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

Только облако (cloud-only), часто продаваемое как видеонаблюдение по подписке – Video Surveillance as a Service (VSaaS, запись и управление как услуга вместо коробки в собственности), – шлёт потоки камер прямо в облако провайдера, где они пишутся и управляются. Локального сервера записи почти нет; камеры, канал связи и браузер – вот вся система. Это самая простая в развёртывании модель и та, что бьётся о стену отдачи сильнее всех, потому что каждая записанная секунда должна покинуть здание в реальном времени. Наша статья о моделях развёртывания разбирает бизнес-модель VSaaS целиком; здесь нам важно, что она делает с полосой и стоимостью.

Облачный бэкап держит основную запись на локальном сервере – на локальном NVR или хранилище VMS, которое мы считали ранее, – и копирует часть или всё в облако как вторую, внешнюю копию. Локальные диски несут нагрузку записи и быстрое воспроизведение; облачная копия переживает пожар, кражу самого сервера или стёртый массив. Она защищает от отказа, от которого локальное хранилище само по себе защитить не может: от потери здания.

Гибрид edge + облако – середина, которую и поставляет большинство продуктов. Локальное устройство – сервер записи, «мост» (bridge) или облачно-управляемый рекордер – пишет непрерывно на площадке и выгружает выборочно: наверх идут события, короткие клипы, низкого разрешения превью и метаданные, а полноразмерная непрерывная запись остаётся локально, пока не устареет или её специально не запросят. Облако берёт управление, поиск, обмен и перелив; здание берёт пожарный шланг. К этому паттерну статья и ведёт, потому что именно он переживает математику полосы и стоимости.

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

Стена отдачи: почему нельзя просто писать всё в облако

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

Возьмём типичную современную камеру: разрешение 1080p, запись в H.265 (нынешний эффективный кодек видеонаблюдения – почему он примерно вдвое режет битрейт против старого H.264, см. в разделе о кодировании видео). Такая камера выдаёт около 2 Mbps. Теперь масштабируем до небольшого-среднего объекта в 40 таких камер, все пишут в облако непрерывно:

40 камер × 2 Mbps = 80 Mbps видео, выдаётся непрерывно
80 Mbps устойчивой отдачи, 24 часа в сутки, 7 дней в неделю

Восемьдесят мегабит в секунду не кажутся многим рядом с гигабитным офисным каналом – пока не заметишь слово отдача. Большинство бизнес- и ритейл-каналов асимметричны: скорость загрузки большая, а скорость отдачи, которая и нужна видеонаблюдению, – её доля. Канал, заявленный как «500 вниз / 50 вверх», вообще не вынесет 80 Mbps отдачи, а даже тот, что вынесет, не оставит ничего на остальное и не даст запаса под всплески битрейта на активной сцене. Перейдите на 4K-камеры (около 4–6 Mbps каждая на H.265) или на 200 камер – и требуемая отдача уходит в сотни мегабит: выделенный симметричный бизнес-канал по соответствующей цене.

«Частая ошибка: заложить облачное хранение, но не канал отдачи. Команды считают цену за гигабайт, подписываются, а потом обнаруживают, что интернет-канал объекта не может вытолкнуть видео наверх. Запись, не влезшая в трубу, просто теряется – камера не пишет ничего, или облачный сервис тихо роняет разрешение и частоту кадров, чтобы влезть, так что «записанное» видео хуже того, что камера видит. Канал отдачи, а не подписка на хранение, – первое, что нужно считать для облачной записи, и на многих объектах он из этих двух дороже.»

Эта одна стена объясняет приметный паттерн рынка: вендоры, рекламирующие «облачное» видеонаблюдение, на деле не стримят каждый сырой кадр в датацентр. Камеры Verkada анализируют на устройстве и держат запись локально, отправляя в облако лишь превью и метаданные – порядка 20–50 Kbps на камеру в покое, в тысячи раз меньше сырого потока, – и подтягивают полное видео только по запросу. Eagle Eye Networks ставит на каждом объекте локальное устройство-«мост» (Bridge), которое пишет локально, буферизует день-два видео и выгружает с умом по мере доступности полосы, переживая обрывы и перегрузку сети. Оба – гибридные системы под маркой «облака» именно по той причине, что только что показала математика.

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

Сколько на деле стоит облачное хранение: три счётчика, и один из них больно бьёт

Допустим, канал отдачи есть. Стоимость хранения записи видеонаблюдения в облаке крутят три отдельных счётчика, и опасность в том, что покупатель читает лишь первый. Это зеркалит вид «трёх счётчиков» из нашей статьи о стоимости облачной аналитики для вычислений; для хранения счётчики – это хранение, egress и извлечение.

Счётчик первый – хранение, за гигабайт в месяц. Это цена с витрины, и она дёшева. На крупном облаке горячее, мгновенно читаемое объектное хранилище стоит около $0,023 за гигабайт в месяц в 2026 году – примерно $23 за терабайт в месяц. Более холодные, медленные классы стоят куда меньше, вплоть до архивных уровней около $1 за терабайт в месяц – этот разброс целиком разбирает наша статья об уровнях хранения. Читая один счётчик хранения, облако выглядит выгодной сделкой.

Счётчик второй – egress, за гигабайт, вынесенный с платформы. Облачные провайдеры пускают данные внутрь бесплатно, но берут плату за вынос. Egress в интернет начинается примерно с $0,09 за гигабайт – около $90 за терабайт – и эта плата срабатывает каждый раз, когда вы тянете запись назад, чтобы посмотреть, выгрузить или перенести её. Для большинства нагрузок egress эпизодичен. Для видеонаблюдения весь смысл архива в том, что однажды вы вытянете его кусок назад – ради инцидента, расследования или юридического запроса, – так что счётчик egress не крайний случай, а основной сценарий.

Счётчик третий – извлечение, цена и ожидание разморозки холодных данных. Дешёвые архивные уровни, на которых облачное хранение и выглядит почти бесплатным, не читаются мгновенно. Чтобы прочитать данные из глубоко-архивного класса, вы сперва платите за гигабайт извлечения и ждёте – минуты-часы для одних классов, до 12 часов, а для самого глубокого уровня до 48 часов при пакетном извлечении. Эта задержка нормальна для комплаенс-копий, которые надеешься не трогать. Для видео, которое охраннику нужно увидеть сейчас, она неработоспособна.

Сложим счётчики на объекте из 40 камер. При 2 Mbps непрерывно каждая камера пишет около 21,6 ГБ в день; 40 камер пишут примерно 864 ГБ в день, так что скользящий 30-дневный архив держит около 26 ТБ (та же величина, что выводит наша статья о ретенции). Теперь прочитаем каждый счётчик:

Хранение (горячий класс):  26 000 ГБ × $0,023/ГБ-мес  ≈ $600 / мес, лишь чтобы держать 30 дней
Вернуть один день:            864 ГБ × $0,09/ГБ        ≈ $78  за выгруженный день
Вернуть все 26 ТБ:         26 000 ГБ × $0,09/ГБ         ≈ $2 340 чтобы вытащить месяц
Те же 26 ТБ в глуб. архиве: 26 000 ГБ × $0,001/ГБ       ≈ $26 / мес — но 12–48 ч на чтение

Счётчик хранения говорит $600 в месяц – по карману. Счётчик egress говорит, что одно серьёзное расследование, выгружающее неделю записи с нескольких камер, может стоить от сотен до тысяч долларов только за передачу. А счётчик извлечения говорит, что соблазнительный уровень за $26 в месяц не может держать живую запись видеонаблюдения, потому что никто не будет ждать 12 часов, чтобы пересмотреть взлом. Облако дёшево наполнять и дорого опустошать – ровно противоположно тому, как используется запись видеонаблюдения.

«Частая ошибка: класть живую запись в глубоко-холодный уровень ради экономии. Цена за гигабайт глубоко-архивного класса так заманчива, что команда направляет туда всю запись. Потом случается инцидент, кто-то запрашивает клип, и системе нужны 12–48 часов и плата за извлечение, чтобы его выдать. Глубоко-архивные уровни – для записи, которую вы обязаны хранить по закону, но реально не смотрите; всё, что может понадобиться быстро, должно лежать в мгновенно читаемом классе по его более высокой месячной цене. Сопоставляйте класс хранения со скоростью, с которой запись может понадобиться, а не с самым низким ценником.»

Ставки – характерные цифры 2026 г. крупного облачного провайдера; точные числа зависят от провайдера, региона и контракта – сверяйтесь с актуальным прайсом. Важен паттерн, а не точный цент.

Гибридный паттерн: держите шланг дома, отдайте облаку то, в чём оно хорошо

И стена полосы, и ловушка egress указывают на один ответ – тот, к которому приходит большинство боевых систем: держать тяжёлую, чувствительную ко времени работу на площадке, а облако использовать для того, в чём оно действительно лучше. Это гибридный паттерн edge-плюс-облако, и его стоит нарисовать, потому что экономия велика и конкретна.

Локальное устройство – местный сервер записи, «мост» или облачно-управляемый рекордер – делает три работы, которые облако не может выполнить экономно. Оно поглощает непрерывную нагрузку записи на локальные диски, так что шланг в 80 Mbps вообще не касается интернета. Оно отдаёт мгновенное воспроизведение свежей записи любому на площадке – без платы за egress и без задержки. И оно работает буфером, переживающим обрывы интернета, держа день-два видео, чтобы упавший канал никогда не означал упавшую запись. Локальная архитектура хранения, которую мы разобрали ранее, – ровно этот локальный слой.

Облако тогда получает лишь тонкие, ценные потоки. Клипы событий и метаданные, делающие запись искомой, идут наверх постоянно, но в полосе стоят почти ничего. Низкого разрешения превью каждой камеры поддерживает удалённый просмотр, не отправляя полный поток. А выборочный бэкап – важнейшие камеры или помеченная аналитикой запись – копируется наверх для защиты вне площадки. Итог разителен: тот же объект на 40 камер, которому требовалось 80 Mbps постоянной отдачи для чисто облачной записи, теперь требует лишь несколько мегабит, потому что шлёт события и превью, а не каждый кадр. Verkada с её 20–50 Kbps на камеру и Eagle Eye с её мостом «буфер-и-вперёд» – два коммерческих выражения этого же паттерна.

Гибридная модель и стоимость перекраивает. Локальный рекордер – разовая покупка железа, несущая основной объём хранения; рекордер и его диски обычно стоят от нескольких сотен до пары тысяч долларов и служат три-пять лет, апгрейды хранения – отдельные несколько тысяч. Облачная подписка тогда покрывает лишь резервную копию, плоскость управления и перелив – куда меньший месячный счёт, чем держать каждый терабайт в облаке, и без большей части риска egress, потому что рутинное воспроизведение обслуживается локально. Отраслевые интеграторы ставят полную стоимость владения гибрида примерно на треть-половину ниже чисто облачной схемы для много-объектного развёртывания – поэтому он и доминирует в реальных инсталляциях.

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

Когда облако выгоднее своих дисков – и когда нет

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

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

Локальное хранение остаётся сильнее, когда много камер пишут непрерывно на одном объекте, потому что стена отдачи и плата за egress делают удержание этого шланга в облаке и физически трудным, и дорогим. Оно выигрывает, где частое быстрое воспроизведение – рутина, ведь локальные чтения мгновенны и бесплатны, а облачные – ни то ни другое. И оно выигрывает, где регуляторика или политика требуют держать запись на объекте или в стране, чем займётся следующий раздел. Для большинства систем выше нескольких камер ответ – не облако или локально, а гибридное разделение: локально под шланг и быстрые чтения, облако под бэкап, управление и охват, – выбранное по вопросам ниже.

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

Где живёт запись – тоже решение о приватности

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

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

Второе ограничение – где данные пересекают границу. Отправка записи из ЕС в облачный регион – или провайдеру – за пределы Европейской экономической зоны есть международная передача, регулируемая Главой V GDPR, которая требует правового основания: решения об адекватности (adequacy), стандартных договорных условий (SCCs) или обязательных корпоративных правил (BCRs). Тонкость подводит многих: выбор датацентра в регионе сам по себе вопрос не закрывает. Рекомендации EDPB по передачам (Guidelines 05/2021) считают раскрытие импортёру в третьей стране передачей независимо от того, где лежат байты, а облачный провайдер, чья материнская компания подчинена закону другой страны, может столкнуться с юридическими требованиями выдать данные даже из площадки в регионе. Трансатлантический механизм, на который опирается большинство провайдеров США, – EU–US Data Privacy Framework – был поддержан Общим судом ЕС в сентябре 2025 года, но остаётся под апелляцией в Суде ЕС (дело C-703/25 P, слушание не назначено на середину 2026 года) – живое напоминание, что трансграничные схемы могут сдвигаться. Безопасный инженерный дефолт для чувствительной записи видеонаблюдения, особенно биометрической, – держать узнаваемое видео в регионе и считать юридическую экспозицию облачного адресата частью проекта.

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

Где место стандартов: ONVIF Profile G всё равно, где живут байты

При всей разнице между диском в стойке и бакетом в датацентре, ПО видеонаблюдения добирается до записи одинаково в обоих случаях, и именно это делает выбор «облако против локально» свободным архитектурным решением, а не переписыванием. ONVIF – общий язык, позволяющий камерам и ПО записи разных производителей работать вместе, разделённый на профили по задачам. Профиль, управляющий записанным видео, – ONVIF Profile G, открытый стандарт записи и выдачи – текущая версия 1.1, опубликована в октябре 2025 года, – который стандартизирует, как система управляет записью и как ищет и воспроизводит хранимое видео (FindRecordings, FindEvents) у разных вендоров.

Граница – та же, что мы провели для локального хранения: Profile G стандартизирует интерфейс к записанному видео, а не носитель, что его держит. Запрос на выдачу выглядит одинаково, лежит ли запись на локальном RAID-массиве, в буфере моста или в облачном бакете на другом конце света. Помните правило из нашего объяснения ONVIF: ONVIF гарантирует базовый уровень, к которому обе стороны conform, а не хранилище под ним. Коммерческий обзор того, как профили ложатся на реальные продукты, даёт гид Фора Софт по профилям ONVIF в системах безопасности. Это чистое разделение и позволяет системе стартовать на локальных дисках, добавить облачный бэкап и позже перенести старую запись наверх в архивный уровень – всё без изменения того, как приложение пишет или выдаёт, потому что каждый путь по-прежнему говорит на Profile G.

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

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

Главное

• Цена за гигабайт – малое число; полоса отдачи и плата за egress – это счёт.
• Чисто облачная запись бьётся о стену отдачи: ~40 камер требуют ~80 Mbps постоянно, 24/7.
• Облако берёт плату за чтение данных назад – egress (~$90/ТБ) делает выгрузку расследования дорогой.
• Глубоко-архивные уровни дёшевы, но медленны (12–48 ч на чтение) – не для живой записи.
• Рабочий паттерн – гибрид: локальное устройство берёт шланг, облако берёт события и бэкап.
• Где приземляется запись – выбор приватности: GDPR ограничивает ретенцию и регулирует передачи.

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

• Локальная архитектура хранения: NVR, SAN, NAS и RAID
• Уровни хранения: горячий, тёплый, холодный и архив
• Политика хранения: сколько хранить запись и почему