Как увеличить архив видеорегистратора

Обновлено: 24.01.2025

Как вы знаете, существует масса объектов, для которых сохранность видеоархива является основополагающим требованием к системе видеонаблюдения. А на некоторых объектах заказчик, помимо резервирования архива,

хочет увеличить его глубину до 3-6 месяцев, а иногда и до года. Реализовать данные требования можно несколькими способами, в том числе с помощью сетевого хранилища VIDEOMAX-STORAGE. Давайте рассмотрим эти способы более подробно.

О возможностях резервирования и долговременного хранения видеоархива смотрите в нашем видео:

На канале VIDEOМАХ регулярно публикуются обучающие видео, демонстрации работы технологий, записи мероприятий.
Подпишитесь, чтобы быть в курсе новых технологий видеонаблюдения.Подпишись на канал

Резервирование видеоархива

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

Первое – это организация RAID массива непосредственно на сервере. Информация в этом случае записывается так, что при выходе из строя любого диска в массиве, видеоархив не теряется. Однако при выходе из строя сервера вы, на время его ремонта, теряете доступ к этим данным. Подробно о резервировании на основе RAID массивов мы рассказывали в нашей статье "Резервирование HDD. RAID массивы для видеонаблюдения".

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

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

Обобщенно это можно представить в виде таблицы:

Способ резервирования	Преимущества	Недостатки
RAID массив	Сохранность архива	При выходе из строя сервера на время ремонта доступ к архиву теряется
Запись архива на отдельное устройство, NAS	Сохранность архива даже при поломке сервера	Работа напрямую с файлами архива без фильтрации по времени, привью, поиску в архиве по событиям и т.п.
Сервер резервного хранения видеоархива	Сохранность архива даже при поломке сервера. Возможность работы с архивом с удалённого рабочего места системы видеонаблюдения	-

Долговременный архив

Объемы записываемых данных в системах видеонаблюдения с каждым днём растут. Здесь и рост количества мегапикселей в камерах, и увеличение количества камер на одном объекте вследствие снижения их стоимости, а также расширение возможностей ПО видеонаблюдения и решение бизнес задач при помощи видеоаналитики. В этой ситуации решение задачи организации долговременного хранения данных на 3-6 месяцев или даже год требует ответственного подхода. Рассмотрим варианты построения систем с большими объёмами видеоархива.

Увеличение дискового массива основного сервера при помощи добавления к нему дополнительных полок с дисками - JBOD. Это недорогое и эффективное решение для увеличения глубины архива локального видеосервера. Но опять-таки, при выходе из строя сервера, архив, на время ремонта, будет не доступен.

JBOD удобное и недорогое решение для увеличения глубины архива, но нужно понимать, что при потери связи с сервером утерян будет и доступ к записанному видеоархиву.

Если важна оперативность доступа к видеоданным, можно использовать сетевое хранилище на основе NAS систем. В этом случае видеосервер пишет архив по ЛВС или напрямую через iSCSI сразу на NAS, доступ к которому возможен удаленно с любого ПК.

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

Ну и, как и в случае с резервированием, если доступа к видеосерверу по каким-то причинам нет, то подключившись к NAS мы получим доступ к видеоархиву. Но это снова папки, файлы, ручная сортировка и анализ данных.

Сетевое хранилище большого объёма остается доступным независимо от сервера, но доступ к видеоданным вне ПО видеонаблюдения большая проблема - приходится работать напрямую с файлами без возможности сортировки по дате, времени, событию.

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

Использование сервера архивации в качестве долговременного архива позволяет обеспечить постоянный доступ к записанным данным в рамках интерфейса ПО видеонаблюдения - с удобным поиском и просмотром фрагментов записей.

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

Обобщенно это можно представить в виде таблицы:

Способ увеличения архива	Преимущества	Недостатки
JBOD к локальному видеосерверу	Необходимое увеличение глубины архива	Не доступность архива при выходе из строя сервера на время ремонта
Использование NAS систем	Необходимое увеличение глубины архива, сохранность	Высокая стоимость для большой глубины архива
Сервер долговременного хранения архива	Необходимое увеличение глубины архива, сохранность, использование полного функционала ПО видеонаблюдения	-

VIDEOMAX-STORAGE для резервного и долговременного хранения видеоархива

VIDEOMAX-STORAGE – это PC-based решение для надёжного хранения видеоархива. Может использоваться как резервное хранилище, так и долговременное. При помощи дополнительных полок с дисками можно организовать дисковый массив в 600Тб и более. Давайте рассмотрим его подробнее.

VIDEOMAX-STORAGE собирается только из серверных комплектующих на базе материнской платы Supermicro, процессоров Intel Xeon. Используются серверные диски корпоративного класса, организованные в RAID массив с функцией горячей замены. Также предусмотрено резервирование блоков питания и наличие нескольких сетевых интерфейсов. Помимо этого, в VIDEOMAX-STORAGE используется технология, позволяющая производить удалённый мониторинг и контроль работы сервера хранения данных, о чём мы рассказывали в одном из наших видеороликов.

список камер для резервного копирования
глубина хранения архива по каждой камере
прореживание архива

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

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

Об этом решении далее и пойдет речь, на примере работы с популярным NVR HIKVISION DS-7604NI-SE. NVR у нас будет выступать в роли локомотива, а в качестве состава вагонов с дисками — модуль расширения емкости (DAS) компании CFI B8283JDGG (8 дисковая модель) с поддержкой простого и удобного аппаратного RAID.

Для тех, кто не знаком с NVR HIKVISION DS-7604NI-SE, знакомимся

Запись с разрешением до 5 Мп
Поддержка камер других производителей (например, Zavio)
Управление квотами дискового пространства
HDMI и VGA выходы с разрешением до 1920×1080р
Разрешение при записи/воспроизведении 5MP /3MP / 1080P / UXGA / 720P / 4CIF / VGA / DCIF / 2CIF / CIF / QCIF
Аудиовыход 1 канал, RCA (Линейный, 1 kOm)
Тип потока Видео / Видео и аудио
Синхронное воспроизведение 4 канала
Жесткий диск SATA 2 SATA (Объем до 4 Тб каждый) Наружные интерфейсы
Сетевые интерфейсы 1, RJ45 10M / 100M / 1000M Ethernet интерфейс
Интерфейс передачи 1 RS-485 интерфейс
USB-интерфейс 2, USB2.0
Тревожные входы/выходы 4/1 (опционально) Общие Питание 100 — 240 В
АC Потребляемая мощность до 15Вт (Без жестких дисков и DVD привода)
Рабочие условия -10°C— +55°C
Размер 445 x 290 x 45 мм
Вес менее 2 кг (Без жестких дисков и DVD привода)

Про CFIйский DAS я узнал в общем-то не так давно, отчасти из постов других людей на habr, отчасти изучая вопрос может ли быть что-то с USB/eSATA на количество более 2-х дисков. Оказалось, что есть такие устройства.

А теперь от теории переходим к практике. Я подключил к видеорегистратору HIKVISION накопитель CFI. В моем случае NVR HIKVISION оборудован только USB-портом, через него и соединил оба устройства. В данном опыте использовались HDD от Seagate, Constellation ES.3.

Здесь мы можем выбрать наш основной HDD или же нашу группу Дисков. Примечание: отобразить S.M.A.R.T. устройства CFI-B8283JDGG не удается из-за более сложного технического исполнения с использованием дополнительного контроллера JMicron JMB391.

Были поставлены следующие задачи.

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

Для исследования использовал множество программных инструментов: дисковый редактор (он же и файловый бинарный редактор) DiskExplorer (WinHex я использовал позже), MS Excel для вспомогательных расчётов и фиксации результатов, среда программирования Dev-C++ для написания вспомогательных и окончательных консольных программ и прочее. В этой статье я попробую рассказать о данной процедуре.

Сначала посмотрим на самый первый сектор HDD (один сектор (1 LBA) занимает 512 Байт). Данный сектор, как правило, содержит MBR структуру. В неё входит загрузчик и базовое оглавление разделов. Структура этого сектора, а также, структура описания раздела, приведены ниже (взято из Википедии).

В случае с исследуемым HDD имеем следующее. Глядя на рисунок ниже и руководствуясь таблицами выше, мы видим, что загрузчик отсутствует. Но нас интересует больше таблица разделов. Она выделена в красную рамку. Последние два байта (синяя заливка) – сигнатура MBR. Из таблицы разделов видно, диск поделён на два раздела. Код типа первого раздела (жёлтая заливка) – 0x0B. Это раздел FAT32. Код типа второго (оранжевая заливка) – 0x83. Это один из разделов Linux (в смысле, EXT). Байты кода типа раздела обведены в синюю рамку.

Полная расшифровка сектора MBR с таблицей разделов и их параметрами приведена ниже.

Обращая внимание на размеры разделов (пересчитывая число секторов в гигабайты), несложно догадаться, что на компьютере с ОС Xubuntu отображался именно первый раздел, занимающий незначительную часть дискового пространства. Кстати говоря, в Windows XP также отобразился только первый раздел, но из проводника не открылся. А почему же тогда второй раздел Linux не отобразился в ОС Xubuntu?

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

Как видно из таблицы разделов, второй раздел начинается с сектора 16016805. Руководство по файловой системе EXT2 свидетельствует о наличии так называемого суперблока, который располагается в 1024 байтах от начала раздела (то есть в двух секторах от начала). Однако сектор 16016805+2=16016807 оказался пустым. Зато первый сектор 16016805 по своей структуре напоминал суперблок. Но его содержимое полностью не соответствовало описанию содержимого суперблока из руководства. Суперблок – это основной блок, в котором содержится своеобразная таблица различных констант и параметров для функционирования файловой системы: адреса положений и размеры других необходимых блоков, в частности, заголовков файловых записей и директорий. Дальнейшие исследования этого раздела привели меня только к одному выводу: DVR использует свою уникальную файловую систему.

В дальнейшем решил взглянуть на первый сектор первого раздела (сектор 63) и пролистать вниз. Было обнаружено на секторе 65 (двумя секторами ниже) содержимое, полностью похожее на содержимое суперблока ФС EXT2, которое описано в руководстве. Дальнейшие исследования привели к выводу, что первым разделом HDD DVR является раздел EXT2, который и отображался в ОС Xubuntu, невзирая на метку 0x08 (не EXT) в оглавлении раздела! Таким образом, первый раздел жёсткого диска видеорегистратора – раздел EXT2, на котором записаны файлы nvr, являющиеся ключами к требуемым видеозаписям.

Перейдём к изучению структуры самих файлов nvr. Вид одного такого файла в бинарном (точнее, в 16-ричном) редакторе приведён на рисунке ниже. Не вдаваясь в подробности описания структуры содержимого (часть которой так и осталась для меня загадкой), я выделил самые основные параметры, которые и являются искомым ключом. Это 32-битные (4-байтные) значения, располагающиеся через каждые 32 байта, начиная с байта по смещению 40. На рисунке они выделены красным прямоугольником. В дальнейшем я убедился, что этого вполне достаточно для ключа к видеозаписям. Напоминаю, что 4 байта значения этого ключевого параметра располагаются от младшего к старшему, но не наоборот! Такая нотация обусловлена архитектурой процессора ПК. В приведённом на рисунке примере изображён первый nvr файл первого каталога. Он соответствует первой видеозаписи, сделанной видеорегистратором. Очевидно, что значения параметров, которые я назвал ключевыми, в приведённом примере образуют последовательность целых чисел, начиная с нуля и идущие по порядку по возрастанию. Исследуя другие nvr файлы, и просматривая в них именно эти указанные байты, были также замечены целые числа, идущие по возрастанию. Но данная последовательность начиналась естественно уже не с нуля, и в некоторых случаях местами наблюдались пропуски по одному или два числа. Например (числа от балды): 435, 436, 438, 439, 442,…(или в 16-ричном виде: B3010000, B4010000, B6010000, B7010000, BA010000,…).

Также, предстояло выяснить, какие именно данные делятся на вышесказанные нумерованные сегменты? Первое предположение – данными являются потоки аудио и видео, которые в контейнере 264 представлены короткими блоками, причём, как было сказано, блоки видеопотока имеют разный размер. При этом DVR на этапе извлечения видеозаписи на внешний носитель собирает эти потоки и упаковывает в контейнер 264. Второе предположение – потоки аудио и видео DVR упаковывает в контейнер 264 в начале и во время видеозахвата. И при этом на HDD записываются уже сформированные данные файла .264, который бы получился в результате его извлечения на внешний носитель. Исследуя пространство HDD где-то в середине второго раздела, наряду с байтами потоков аудио и видео и их заголовками того же вида, что и в контейнере 264, мне также попадались и заголовки самого контейнера: MDVR96NT_2_R. После данного заголовка также присутствовало множество байтов нулей. В целом, исследование показало, что имеет место второй вариант из двух вышеприведённых. Поэтому, для получения нужного файла .264, вероятнее всего, нужно просто соединить вместе все сегменты, номера которых содержатся в соответствующем файле nvr.

Приступим к поиску зависимости между номером сегмента и координатами на HDD.

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

Я провёл ещё один дополнительный интересный эксперимент, чтобы окончательно развеять все сомнения. Он описан ниже.

Итого, мы получили предполагаемую зависимость: S=16046629+128*d, где d – номер сегмента в файле nvr, а S – номер сектора на HDD, начиная от самого начала диска, с которого начинаются данные содержимого сегмента. Размер сегмента – 128 секторов. Приведённая выше формула не берёт во внимание существование второго раздела. Зависимость найдена только для конкретного примера с HDD на 1TB. Возможно, если поставить в DVR HDD другой ёмкости, константы примут иной вид.

Всё-таки, попытаемся исследовать второй раздел. Как уже отмечалось ранее, нечто похожее на суперблок находится прямо в первом секторе раздела (16016805). А его точная копия была обнаружена семью секторами ниже (16016812). Очевидно, ненулевая основная информация находится в первом секторе суперблока. Его вид в дисковом редакторе приведён на рисунке ниже.

То есть, второй раздел можно назвать урезанным и немного видоизменённым разделом EXT2. В нём есть суперблок, его копия, битовая карта. Но отсутствуют т. н. информационные узлы, соответствующие файловым записям. Раздел содержит данные файлов .264 (аудио и видео потоки), но информационные узлы (скажем так) для этих данных размещены в nvr файлах на первом разделе. Может быть, существует более грамотная формулировка? Но мне это уже не столь важно.

Для сканирования директорий я не использовал рекурсию, принимая во внимание, что формат директорий фиксирован и имеет два уровня вложения. Соответственно, я применил два цикла: пробег по папкам, пока они не закончатся, и пробег по файлам в каждой папке с тем же условием. Для чтения файлов я применил сишную функцию fopen. Для работы с секторами HDD я использовал функционал WinAPI по аналогии работы с файлами. Перейдём к коду программы.

Библиотеки нужны такие.

А эти функции я полностью скопировал с какого-то форума.

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

Основная функция также довольно простая.

На старом компьютере с процессором Pentium 4 и PCI контроллером SATA программа успешно переложила до конца заполненный HDD несколькими тысячами файлов .264 в среднем за 7 часов. На новом компьютере – раза в три быстрее. Как я уже отметил, программа не универсальная, все константы и переменные подстроены под мой конкретный случай с HDD на 1TB. Однако, можно ещё немного поработать и сделать её универсальной, нарисовать к ней графический интерфейс.

Для хранения видеоархива в регистраторах используются жесткие диски HDD.

Как гибридные (SVR) , так и сетевые (SVN) видеорегистраторы поставляются без HDD в комплекте. Для хранения видеоархива необходимо приобрести и установить внутрь корпуса с помощью двух кабелей (информационного и кабеля питания) жесткий диск.

При выборе HDD для видеорегистратора следует учитывать следующие параметры:

количество жестких дисков, поддерживаемое регистратором – указывается в спецификации оборудования;
максимально поддерживаемый объем HDD – указывается в спецификации оборудования (измеряется в Gb или Tb);
дополнительные технические характеристики: форм-фактор (3.5" и 2.5"), интерфейс подключения (SATA 2, SATA 3).

Так, сетевой регистратор SVN-4625 (NVMS-9000) поддерживает один HDD объемом до 6Tb, а гибридный SVR-6115F – два HDD объемом до 8Tb каждый, то есть общий объем хранилища составляет 16Tb.

Кроме того, при подборе жестких дисков следует учитывать перечень рекомендованных HDD .

Стоимость HDD достаточно высока, поэтому актуален вопрос подбора оптимального объема хранилища. Данный параметр зависит от множества факторов, таких как: количество камер, их разрешения, режима записи (постоянная / по детекции движения / по тревоге) и др.

Для увеличения объема хранилища можно использовать SATABOX – это устройство, подключаемое к регистратору с помощью кабеля e-SATA. Внутри устройства предусмотрено место для установки четырех HDD, объемом до 6 Tb каждый. Таким образом, SATABOX позволяет увеличить объем хранилища максимально на 24Tb. Однако, стоит отметить, что на момент написания данной статьи его подключение возможно только к гибридным видеорегистраторам 1-ой серии.

Есть ли еще способы увеличения объема хранилища?

Увеличить объем хранилища, а точнее глубину видеоархива, можно используя профессиональное программное обеспечение, установленное на сервере, или облачные сервисы.

Так, применение профессионального программного обеспечения IProject позволяет производить запись видео непосредственно на сервер, при этом объем хранилища зависит от общего объема HDD, установленных на сервере.

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

В данной статье рассмотрены основные моменты, связанные с хранением видеоархива, и способы увеличения объема хранилища.

При выборе HDD для видеорегистратора следует учитывать следующие параметры:

количество жестких дисков, поддерживаемое регистратором – указывается в спецификации оборудования;
максимально поддерживаемый объем HDD – указывается в спецификации оборудования (измеряется в Gb или Tb);
дополнительные технические характеристики: форм-фактор (3.5" и 2.5"), интерфейс подключения (SATA 2, SATA 3).

Кроме того, при подборе жестких дисков следует учитывать перечень рекомендованных HDD .

Есть ли еще способы увеличения объема хранилища?

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

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

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

В технических характеристиках большинства видеорегистраторов линейки NOVIcam Pro заявлена поддержка NAS хранилищ или протокола NFS , что позволяет с лёгкостью решить вышеописанные задачи.

Что же такое NAS и как его можно использовать в составе системы видеонаблюдения?

Если обратиться к Википедии, то NAS (англ. Network Attached Storage) — это сетевая система хранения данных, сетевое хранилище. Представляет собой компьютер, подключенный к сети и предназначенный для предоставления сервисов хранения данных другим устройствам.

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

На сегодняшний день готовое NAS хранилище можно без труда приобрести в любом крупном магазине, который торгует компьютерной техникой. А также, если в кладовке завалялся системный блок с устаревшим железом, то вполне реально сделать сетевое хранилище своими руками на базе бесплатной операционной системы типа NAS4Free или FreeNAS .

При выборе сетевого хранилища под определённые задачи обычно в первую очередь руководствуются количеством подключаемых дисков.

К регистраторам линейки NOVIcam Pro можно подключить до 8 сетевых хранилищ одновременно для прямой записи или для резервирования данных, хранящихся на жёстком диске видеорегистратора. При этом NAS может находиться как в одной локальной сети с регистратором прямо на объекте, так и удалённо, например, в другом городе.

Если к одному регистратору подключить 8 сетевых хранилищ с максимальным количеством жёстких дисков 24 , то при учёте, что диски имеют ёмкость по 4ТБ каждый , суммарный архив будет достигать 768ТБ . Таким образом при построении системы видеонаблюдения на регистраторах линейки NOVIcam PRO ёмкость архива практически не ограничена.

Итак, рассмотрим пример подключения видеорегистратора NOVIcam Pro TR2116A к готовому NAS хранилищу от компании Netgear.

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

Список регистраторов, поддерживающих сетевые NAS хранилища или протокол NFS:

Часть 2. NAS хранилище или IP регистратор? (NAS+IPС vs. NAS+NVR/DVR/HVR)

В линейке профессионального оборудования для систем видеонаблюдения NOVIcam Pro не только регистраторы имеют поддержку работы с сетевыми NAS хранилищами , но и IP-камеры . Исходя из этого, возникает вопрос о целесообразности покупки специализированного видеорегистратора, когда можно использовать универсальный NAS . Но не всё так просто как кажется. Даже самое простое сетевое хранилище на 1 HDD стоит дороже 4-х канального регистратора, у которого будет ещё ряд дополнительных преимуществ. Поэтому в качестве основного средства хранения видеоархива использовать NAS не совсем гуманно.

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

Для примера рассмотрим настройку купольной IP видеокамеры NOVIcam Pro NC22VP для работы с сетевым хранилищем.

5. Форматирование диска может занять длительное время.

6. По завершению форматирования диска отобразится его статус и количество свободного дискового пространства. Диск готов к записи.

8. Если необходимо, то можно настроить запись скриншотов в соответствующей вкладке.

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

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

Читайте также: