VMS: on-prem, облако или гибрид – выбор

Кратко

Каждый проект видеонаблюдения принимает решение о развёртывании прежде любого другого, и у него три ответа: держать записывающий софт и хранилище на объекте (on-premises), запускать их в дата-центре провайдера по подписке (облако, часто продаётся как Video Surveillance as a Service, или VSaaS) либо разделить работу – писать локально, а управлять из облака (гибрид). Выбор не про функции; он про то, кто несёт четыре счёта – стартовые затраты, текущие затраты, трафик интернета и юридический вес того, где физически живут ваши записи. On-premises меняет крупную разовую трату на низкие текущие расходы и полный контроль; облако меняет лёгкий старт на ежемесячную плату за камеру и постоянный счёт за отдачу в интернет, который становится ограничителем после примерно сотни камер; гибрид держит тяжёлое видео локально и отправляет наверх только лёгкие части – поэтому большинство серьёзных мультиплощадочных систем приходят именно к нему. Эта статья проходит все три модели простым языком, показывает арифметику трафика и стоимости для объекта на 40 камер тремя способами и даёт путь решения, который можно защитить и перед финансовым директором, и перед специалистом по защите данных на одной встрече.

Почему это важно

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

Одно решение, три формы

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

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

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

Держите эти четыре в поле зрения – и три модели перестанут быть маркетинговыми категориями и станут ясным набором компромиссов.

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

Модель 1 – On-premises: всё остаётся в здании

В одну строку: камеры, сервер записи, хранилище и софт VMS живут в вашей собственной сети, внутри ваших стен.

On-premises – изначальная форма видеонаблюдения и всё ещё выбор по умолчанию для крупных объектов. Представьте частную библиотеку: книги (ваши записи) стоят на полках в вашем здании, полки купили вы, и снаружи их не достать без вашего разрешения. Камеры шлют потоки по локальной сети на сервер записи – часто специализированный сетевой видеорегистратор (Network Video Recorder, NVR), устройство или сервер, записывающий IP-камеры, – и этот сервер пишет на диски на объекте, обычно собранные в массив RAID, чтобы один мёртвый диск не потерял улики. Софт VMS, связывающий всё вместе, тоже работает на объекте, а операторы смотрят с клиентов в той же сети.

Определяющая черта on-premises – видео не обязано покидать здание. Объект на 40 камер может гонять 80 мегабит в секунду видео по своей локальной сети весь день, и этот трафик не стоит ничего сверху, потому что локальная сеть дешёвая и быстрая – гигабит и десять гигабит на коммутаторах обычны. Интернет-канал используется только когда кто-то заходит удалённо посмотреть камеру, а это небольшая, нечастая нагрузка. По трафику on-premises – самая дешёвая модель с большим отрывом.

Форма затрат – это капитальные расходы (CapEx), крупная разовая трата. Вы покупаете камеры, сервер, диски, коммутаторы и лицензии VMS заранее, всё устанавливаете, а дальше текущие расходы скромные: электричество, охлаждение, изредка замена диска и контракт на обслуживание. Никакой ежемесячной платы за камеру нет. На достаточно длинном горизонте on-premises обычно даёт самую низкую полную стоимость, особенно в масштабе, потому что вы не арендуете ту же ёмкость месяц за месяцем.

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

Цена всего этого контроля в том, что вы владеете всем, что может пойти не так. Вы рассчитываете хранилище (и живёте с этим, если ошиблись в меньшую сторону), планируете ёмкость, патчите софт, меняете отказавший диск и строите собственное резервирование, если хотите пережить отказ сервера. Одно здание означает и единую точку физического риска: пожар или кража, забравшие сервер, заберут и записи, если вы не организовали копию вне объекта. On-premises мощна и приватна, но это модель, которая больше всего требует от вашей собственной команды.

Типовой режим отказа: хранилище и вычисления, рассчитанные под сегодня и больше не пересмотренные, – массив, заполняющийся на три недели раньше, потому что кто-то заложил запись по движению, а камеры приехали с непрерывной записью; или сервер без копии вне объекта, так что один пожар, который имеет значение, стирает улики, ради которых его и ставили.

Модель 2 – Облако (VSaaS): запись и управление в дата-центре

В одну строку: камеры шлют видео через интернет в дата-центр провайдера, где происходят запись, хранение и управление, а вы платите месячную подписку за камеру.

Облачное видеонаблюдение обычно продаётся как Video Surveillance as a Service (VSaaS) – софт, хранилище и управление, поставляемые по подписке, так же как Netflix поставляет фильмы вместо того, чтобы вы покупали диски. Вы ставите камеры (иногда небольшое устройство-мост), направляете их в облако провайдера, и дальше заходите в веб-приложение, чтобы смотреть и управлять всем. Почти нет железа на объекте, нет сервера, который надо патчить, и нет хранилища, которое надо рассчитывать – провайдер занимается всем этим, а ёмкость растёт настройкой, а не заявкой на закупку. Для небольшого объекта, сети небольших точек или команды без ИТ-персонала это удобство и есть весь смысл, и оно реально.

Форма затрат переключается с CapEx на операционные расходы (OpEx) – предсказуемую месячную плату вместо крупной разовой траты. Эта предсказуемость действительно проще для бюджета и снижает порог входа. Но счётчик не останавливается. Облачные подписки на запись в 2026 году обычно стоят $10–30 за камеру в месяц при коротком хранении (7–30 дней непрерывной записи), $30–60 при более долгом (60–90 дней) и $75–150 в корпоративном сегменте с расширенным хранением и аналитикой (Solink). Бюджетные тарифы есть и от нескольких долларов за камеру для записи кадров или по движению, но непрерывная запись в полезном разрешении сидит в верхних полосах. Умножьте на камеры и месяцы, и число растёт быстро – арифметику сделаем через минуту, – а для крупного развёртывания, хранимого годами, сумма подписки может превысить то, во что обошлась бы система on-premises при прямой покупке.

Дальше – ограничитель, который решает больше облачных проектов, чем стоимость: трафик. В облачной модели видео каждой камеры должно подниматься по вашему интернет-каналу, постоянно, потому что запись живёт в дата-центре. Одна камера 1080p потребляет примерно 1–2 Mbps отдачи круглосуточно; камера 4 мегапикселя на 15 кадрах в секунду – около 2–4 Mbps (Videoloft; SecurityCameraKing). Звучит скромно, пока не умножишь: десяти камерам нужно 10–20 Mbps постоянной отдачи, а несколько десятков камер могут насытить исходящий канал, от которого зависит и остальной бизнес, иногда вынуждая на апгрейд интернета за $50–200 в месяц поверх подписки. Поэтому интеграторы раз за разом упираются в практический потолок: выше примерно 100 камер чистое облако обычно становится неосуществимым по трафику и стоимости хранения, и более эффективной опорой становится on-premises или гибрид (Wittenbach; Salient). Облако комфортнее всего для меньшего числа камер на хороших каналах.

Облако также меняет уравнение устойчивости. Запись теперь зависит от интернета: если канал до здания упал, чисто-облачная камера может перестать писать до его восстановления, если у неё нет локальной буферизации. Провайдеры рекламируют высокую доступность – «99,9%» или «99,99%» аптайма, – но эти числа заслуживают строгого взгляда. Облачное соглашение об уровне услуг (SLA) – это пер-сервис, а не общее обещание; компенсация за его нарушение обычно – небольшая скидка на счёт следующего месяца, а не возмещение потерянных записей; и развёртывание в одном регионе – это единая точка отказа, какой бы процент на нём ни был напечатан (Cloud Computing Authority). Честная формулировка: облако может быть очень надёжным, но его надёжность – это свойство вашего интернет-канала и архитектуры провайдера вместе, а не гарантия, которую можно принять как данность.

Наконец, облако обостряет вопрос резидентности данных, на который on-premises отвечал так просто. Ваши записи теперь живут на чужих серверах, возможно в другой стране, а видео наблюдения с узнаваемыми людьми – это персональные данные по законам вроде европейского GDPR (Reg. (EU) 2016/679). GDPR не запрещает хранить эти данные вне ЕС, но жёстко регулирует передачу: вывоз персональных данных в страну вне ЕС законен только при наличии «решения об адекватности» для этой страны (GDPR ст. 45) или надлежащих гарантий, таких как Standard Contractual Clauses (GDPR ст. 46) – правила Главы V Регламента. Практический вывод конкретен: с облаком вы обязаны знать, в каком регионе провайдер хранит записи, и подтвердить законное основание передачи, прежде чем подписывать. Это инженерное руководство, а не юридическая консультация; уточняйте детали у квалифицированного юриста. Наша статья GDPR для видеонаблюдения разбирает юридический слой глубже.

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

Модель 3 – Гибрид: писать локально, управлять из облака

В одну строку: держите тяжёлую непрерывную запись на локальном устройстве, а облако используйте только для лёгкой работы – удалённого управления, резервирования, переполнения и аналитики.

Гибрид – это модель, к которой приходит большинство серьёзных мультиплощадочных развёртываний, потому что она ставит каждую задачу туда, где она дешевле всего. Полнобитрейтное видео пишется локально – на NVR, edge-сервере или в хранилище внутри самих камер – поэтому тяжёлые 80 Mbps объекта на 40 камер остаются в локальной сети, где трафик бесплатен, ровно как в модели on-premises. Затем тонкий слой трафика идёт наверх в облако: данные управления и конфигурации, состояние и здоровье, и только те записи, что важны – клипы по движению, записи по событиям, тревоги и метаданные. Записывая тяжёлый поток локально и выгружая лишь небольшие клипы событий, гибридные системы берегут интернет-канал для всего остального и обходят потолок трафика, ограничивающий чистое облако (Spotter Security; iVIS).

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

По четырём счетам гибрид сидит сознательно посередине. Стартовые затраты ниже, чем у полного on-premises (вы всё ещё покупаете локальную запись, но можете опереться на облако для управления и резервирования вместо постройки собственного). Текущие затраты ниже, чем у полного облака (вы платите за облачное управление и долю облачного хранения, а не за непрерывную потоковую передачу и хранение каждой камеры). Трафик драматически ниже облачного, потому что через интернет идут только события и управление. А устойчивость – тихая сила модели: поскольку запись локальна, обрыв интернета не останавливает запись – видео продолжает накапливаться на локальном устройстве и синхронизируется в облако, когда канал вернётся. Облачная копия при этом означает, что уничтоженный локальный регистратор – не конец улик.

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

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

Четыре счёта, бок о бок

Вот всё сравнение на одном экране – версия, которую стоит держать рядом при планировании. Читайте по столбцу, если уже знаете своё ограничение (фиксированную форму бюджета, тонкий интернет-канал, правило резидентности), или по строке, если взвешиваете модели поровну.

Таблица 1. Три модели против счетов, которые реально решают проекты. Ни одна модель не выигрывает каждую строку – правильная та, чьи компромиссы совпадают с вашим объектом, сетью и требованиями комплаенса.

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

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

Пример расчёта: 40 камер, тремя способами

Числа делают компромиссы конкретными, поэтому давайте рассчитаем и оценим один реальный объект – 40 камер, каждая 4 мегапикселя, непрерывная запись около 2 Mbps в H.265, хранение 30 дней – во всех трёх моделях. Арифметика проста, и вы контролируете каждый вход.

Сначала две физические величины, которые двигают всё. Объём на камеру в день – это битрейт, умноженный на секунды в сутках, а удобный приём даёт тот же ответ: объём в ГБ в день ≈ битрейт в Mbps × 10,8. Итак:

2 Mbps × 10,8 ≈ 21,6 ГБ на камеру в день.

На 40 камер за 30 дней:

21,6 ГБ × 40 камер × 30 дней ≈ 25 920 ГБ ≈ 26 ТБ.

И отдача – величина, которая важна только когда видео пересекает интернет:

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

Теперь три модели.

On-premises. Эти 80 Mbps остаются целиком в локальной сети, так что трафик интернета для записи равен нулю. 26 ТБ живут на локальных дисках (заложите массив больше с учётом накладных RAID и запаса). Вы платите один раз за сервер, диски, коммутаторы и лицензии VMS – разовая трата порядка десятков тысяч долларов в зависимости от хранения и резервирования, – а дальше только питание и обслуживание. Второй и третий год добавляют почти ничего.

Облако (VSaaS). Те же 80 Mbps теперь должны постоянно покидать здание, что уже само по себе может вынудить на апгрейд интернета. 26 ТБ сидят в облаке провайдера, включены в подписку. При средней цене $20 за камеру в месяц:

40 камер × $20 × 12 месяцев = $9 600 в год, и около $48 000 за пять лет – текуще, до любого апгрейда канала или надстройки аналитики.

Есть и ловушка, которую стоит назвать: если вы когда-нибудь вытягиваете большие объёмы видео обратно из сырого облачного хранилища, провайдеры берут плату за egress – за данные, покидающие облако. Для ориентира, Amazon S3 берёт около $0,09 за ГБ за первый уровень интернет-egress (AWS S3 pricing). Экспорт месяца видео одной камеры (≈ 648 ГБ) обойдётся примерно в $58 только за egress, поверх хранения, – строка, которую команды регулярно забывают при моделировании облачной стоимости. (Управляемый VSaaS обычно включает обычный просмотр в подписку; ловушка egress сильнее всего кусает на самостоятельно собранном облачном хранилище.)

Гибрид. Эти 80 Mbps непрерывного видео пишутся локально, так что они вообще не касаются интернета – тот же выигрыш по трафику, что у on-premises. Наверх идут только клипы событий и управление; если события составляют, скажем, 10% записи, постоянная отдача падает примерно до 8 Mbps – нагрузка, которую почти любой бизнес-канал несёт спокойно. Вы платите меньшую облачную плату (управление плюс долю хранения событий) и умеренные стартовые затраты на локальную запись. Вы получаете внешнюю копию и управление из одного окна без полной подписки и полного счёта за трафик.

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

Формы затрат важны не меньше сумм, потому что они пересекаются. On-premises – это высокая ступень, затем ровная линия; облако – низкий старт, затем стабильный подъём, который никогда не кончается; гибрид сидит между ними. Для небольшого, недолгого или быстро меняющегося развёртывания низкий старт облака выигрывает. Для крупной системы, хранимой годами, линия on-premises или гибрида в итоге оказывается ниже – облачная подписка часто обгоняет разовую стоимость on-premises где-то на втором-третьем году.

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

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

Как выбрать: путь решения

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

Первый жёсткий барьер – резидентность и контроль данных. Если закон, контракт или правило суверенитета говорят, что записи не могут лежать на стороннем железе или должны оставаться в конкретной юрисдикции, это указывает на on-premises или на гибрид с чувствительным видео, удерживаемым локально. Решите это первым, потому что никакое удобство или цена не оправдывают незаконного развёртывания.

Второй барьер – интернет-канал. Измерьте постоянную отдачу, доступную на каждом объекте, затем сравните её с суммой камеры × битрейт. Если канал не тянет все камеры непрерывно с запасом для остального бизнеса, чистое облако для этого объекта отпадает, и вы выбираете между on-premises и гибридом. Удалённые и бедные на трафик объекты склоняются к гибриду; хорошо подключённые малые объекты могут рассмотреть облако.

Третий вопрос – масштаб и рост. Горстка камер на объекте без ИТ-персонала – зона комфорта облака. Сотни камер или число, которое будет расти, благоволят on-premises или гибриду, потому что именно там разворачиваются трафик и экономика на камеру. Четвёртый – форма затрат, которую вы можете нести: разовый капитальный бюджет указывает на on-premises; нужда в предсказуемом ежемесячном OpEx – на облако или гибрид. Последний – сколько объектов вы ведёте: одно здание терпит управление on-premises; флот объектов гораздо легче из единой облачной консоли, которую дают облако и гибрид.

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

Где стандарты, во всех моделях

Успокаивающий момент, верный для всех трёх моделей: стандарты, делающие мультивендорную систему работающей, не меняются с развёртыванием. ONVIF – отраслевой стандарт, позволяющий камерам и софту разных производителей понимать друг друга, – всё так же управляет тем, как VMS обнаруживает и забирает поток каждой камеры, работает ли VMS в вашем подвале или в дата-центре. Один профиль ONVIF особенно важен для вопроса развёртывания. ONVIF Profile G – это профиль записи и хранения: устройство Profile G (камера или энкодер) может писать видео по сети или на самом устройстве, а клиент Profile G (VMS) может настраивать, запрашивать и контролировать эту запись (ONVIF, Profile G Specification v1.1, 2025). Эта способность записи на устройстве – ровно то, что делает гибридную модель практичной: камера или локальный регистратор держит записи, а VMS, где бы она ни жила, управляет ими через стандартный интерфейс.

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

Типичная ошибка, которой стоит избегать

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

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

Фора Софт строит софт реального времени для видео, стриминга и компьютерного зрения с 2005 года, через 250+ выпущенных проектов, и решение о модели развёртывания мы принимаем с клиентами постоянно, потому что готовые платформы навязывают свой собственный ответ. Команды приходят к нам, когда стандартный облачный продукт не может выполнить правило резидентности, когда флоту объектов нужна гибридная запись, которую ни один отдельный вендорский ящик не поддерживает чисто, или когда арифметика трафика и стоимости при полном числе камер исключает модель, которую продаёт вендор. Мы строим кастомный слой VMS – конвейеры «писать локально, управлять из облака», мультирегиональное хранение, чтящее ограничения резидентности, и пути отказоустойчивости, держащие запись через обрыв интернета, – и подход, с которого мы ведём, всегда: сначала как система ведёт себя под реальной нагрузкой и в реальных условиях сети, затем удобство. Модель, переживающая худший день, бьёт ту, что блестит на демо.

Главные выводы

• Модель развёртывания задаёт форму бюджета, потребность в трафике и риски комплаенса раньше любой функции.
• On-premises: высокие стартовые, низкие текущие затраты, минимум трафика, полнейший контроль – всё обслуживание ваше.
• Облако (VSaaS): низкий старт, плата за камеру/мес., постоянный счёт за отдачу; трафик ограничивает его около ~100 камер.
• Гибрид пишет тяжёлое видео локально и шлёт наверх только события – модель, к которой приходит большинство мультиплощадочных систем.
• Облачная подписка часто обгоняет разовую стоимость on-premises на втором-третьем году в масштабе.
• Сначала решите резидентность и трафик интернета; форму затрат и число объектов взвешивайте вторыми.

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

• Что такое VMS, NVR и DVR
• Как работает хранение видеонаблюдения: математика ретенции
• NVR-софт против VMS: когда регистратора достаточно