Диск DVR/NVR не читается? Пошаговый план спасения архива, когда регистратор “лег”

Регистратор пишет архив не как “обычный компьютер”, а как маленький завод по непрерывной записи. Ему важны две вещи: 1) гарантированно писать десятки потоков 24/7 без “фризов” и фрагментации,
2) быстро находить нужную минуту по времени, камере и событию.
Ради этого многие DVR/NVR форматируют диск в собственную файловую систему или используют стандартную (например, ext-подобную) только как “обертку”, а внутри держат закрытую структуру индексов и контейнеров. В итоге Windows видит “непонятный диск” и предлагает его инициализировать, а попытка “просто скопировать файлы” заканчивается ничем.

В голове пользователя все выглядит логично: видеорегистратор записывает видео, значит на диске должны лежать видеофайлы. Открыли проводник, нашли папку “Record”, скопировали, посмотрели. Но регистратор живет не в мире “удобно пользователю”, а в мире “нельзя терять кадры”. Он пишет десятки потоков одновременно, часто с высокой частотой кадров и высоким битрейтом, делает это круглосуточно, иногда годами. Если хранить архив “как обычные файлы”, диск быстро превратится в лоскутное одеяло из фрагментов, поиск станет медленным, а при отключении питания вы легко получите “файл есть, но не открывается”.

Поэтому большинство регистраторов строят архив как систему, а не как набор файлов. Диск для них это часть механизма. Индексы, служебные таблицы, логика циклической перезаписи, иногда шифрование. В результате Windows видит нечто чужое: либо раздел, который она не умеет читать, либо набор непонятных контейнеров, которые не открываются обычными плеерами. И да, Windows в этот момент искренне пытается “помочь”, предлагая инициализацию. Если согласиться, будет очень чисто. Архив, правда, станет историей.

Если упростить, у регистратора на диске почти всегда есть несколько зон. Служебная зона хранит “паспорт” диска: как он размечен, какие параметры, какие версии форматов, иногда ключи защиты. Отдельно хранится зона индексов: таблицы, которые связывают время, канал, события и физические блоки данных. Есть зона видеоданных: туда пишутся кадры или группы кадров, часто большими последовательными блоками. Часто есть журналы: ошибки, перезагрузки, тревоги, действия пользователя. Иногда рядом живут метаданные: распознавание лиц, номера, движение, классификация объектов.

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

Есть два слоя, и их важно не путать. Первый слой это файловая система, то есть как диск размечен и как хранятся сущности: NTFS, exFAT, ext4, или собственный формат производителя. Второй слой это контейнер видео, то есть во что упакован видеопоток: mp4, avi, dav, ps, “сырые” .h264/.h265 и прочие варианты.

Можно встретить стандартную файловую систему (например, ext4), но внутри будут файлы в фирменном контейнере, которые открываются только фирменным плеером. Можно встретить собственную структуру диска, но экспорт будет в mp4. Поэтому фраза “у регистратора своя файловая система” обычно означает целую архитектуру хранения: индексы плюс контейнеры плюс правила доступа.

В 2026 году в регистраторах обычно встречаются такие сценарии.

DAV (обычно .dav) это фирменный контейнер, встречающийся у ряда регистраторов. Внутри чаще всего лежат потоки H.264/H.265 и иногда аудио, плюс служебные заголовки и метаданные: таймкоды, номер канала, метки событий, иногда контроль целостности, иногда признаки защиты. DAV сделан под конвейер: можно писать кусками, быстро, устойчиво к внезапному выключению питания, удобно индексировать. Обычный плеер DAV часто не понимает, родной плеер понимает, а дальше обычно идет конвертация в mp4 для “нормального мира”.

PS (Program Stream, часто .ps) это контейнер из семейства MPEG. Он упаковывает потоки в последовательность пакетов и исторически дружит с потоковой записью. В видеонаблюдении PS удобен тем, что регистратор может писать, резать и продолжать без капризов “финализации”. Минус в том, что в реальных регистраторах PS нередко имеет фирменные особенности в метках времени и служебных данных, поэтому универсальные плееры могут открывать нестабильно.

Когда вы видите на диске файлы вида .h264 или .h265, это часто не “контейнер” в привычном смысле, а просто “голый” видеопоток. То есть последовательность NAL-юнитов (кадров и служебных блоков кодека), иногда с ключевыми кадрами, иногда с параметрами SPS/PPS, иногда эти параметры повторяются периодически, а иногда лежат только в начале сегмента.

Почему так делают. Потому что “сырое” писать максимально просто и быстро: минимум заголовков, минимум накладных расходов, минимальная вероятность “сломать файл” из-за незакрытого индекса, легко резать поток на сегменты фиксированной длины. Это идеальный формат для внутренней кухни регистратора. Но для человека он неудобен: таймкоды и привязка ко времени обычно хранятся отдельно, в индексах. Аудио часто лежит отдельно или вообще отсутствует. Перемотка и поиск завязаны на индекс, иначе придется сканировать поток и искать ключевые кадры.

Как это смотреть. Обычно либо через родной плеер, либо через конвертацию. Некоторые универсальные инструменты могут “съесть” сырой H.264/H.265, но если нет корректных параметров потока или если сегменты нарезаны хитро, придется сначала восстановить параметры (SPS/PPS) и потом уже собирать в контейнер (например, mp4). Важное: это часто дает видео, но не гарантирует точную временную шкалу, если индексы потеряны.

264 / 265
Это часто то же самое, что “сырой” поток H.264/H.265, просто расширение короче. Иногда это фирменный контейнер с минимальным заголовком. По смыслу это “технический формат”, а не “файл для пользователя”.
TS (Transport Stream, .ts)
Иногда встречается как формат сегментов, особенно в системах, которые любят потоковую нарезку по времени. TS устойчив к потерям и хорошо подходит для кусочной записи. Но это скорее история про передачу и сегментацию, чем про классические DVR.
AVI
Старый добрый контейнер, встречается в некоторых системах и в старых моделях. Может быть удобен, но не идеален для бесконечной записи и современных кодеков. Иногда используется только на этапе экспорта.
MP4
Самый дружелюбный формат для пользователя, но для регистратора требует аккуратной реализации: правильной индексации и корректного завершения сегментов, чтобы не получать “битые” файлы после отключения питания. Поэтому многие регистраторы используют mp4 именно как экспортный формат, а не внутренний.

Hikvision обычно строит опыт вокруг своей экосистемы: родные клиенты, родные форматы экспорта, родные плееры и конвертация. Внутреннее хранение ориентировано на быстрый поиск и контроль доступа. Сценарий “вынул диск и скопировал” не является целевым.

Dahua часто делает ставку на собственные структуры хранения и стабильность 24/7. Устройства массовые, практики много, но принцип тот же: диск это часть механизма.

Uniview (UNV) в целом играет в ту же лигу: внутренние форматы и индексы, наружу выдача через штатные инструменты.

Axis и Hanwha чаще встречаются в VMS сценариях и в инфраструктурных решениях. Там больше дисциплины и процессов, меньше “магии на диске”, но простого трюка с Windows все равно обычно нет.

OEM и ребрендинг это непредсказуемость. Иногда проще, иногда хуже, почти всегда надо заранее планировать “как вытаскивать архив, если что”.

Для честности: инициализация диска в Windows обычно записывает только таблицу разделов (MBR/GPT) в первые сектора. Она не стирает весь диск целиком, и сами видеоданные чаще всего физически остаются на месте. Поэтому иногда после инициализации действительно можно восстановить разделы или файлы правильными утилитами. Но у дисков от DVR/NVR есть подвох: многие регистраторы хранят критичные служебные данные именно там, куда Windows лезет “помогать”: паспорт диска, карту зон, ключи защиты, куски индексов. В итоге инициализация может не уничтожить блоки видео, но уничтожить “карту”, по которой из этих блоков собирается архив и привязка ко времени, каналам и событиям. Кирпичи остались, чертеж сожгли.

Когда инициализация может быть допустима, или хотя бы логична:

1. У тебя уже есть полный образ или клон диска, и ты работаешь только с копией. Эксперименты делаются на копиях. Оригинал пусть будет как улика.
2. Ты не пытаешься читать архив регистратора вообще. Твоя цель, просто использовать диск заново (под Windows, NAS или новый регистратор), а старый архив не нужен или уже извлечен. В сценарии “начать с чистого листа” инициализация нормальна.
3. Есть сильные признаки, что на диске обычная файловая система с обычными файлами, а проблема только в потерянной или битой таблице разделов. Такое бывает после сбоев питания: данные есть, а раздел “пропал”. Даже тут инициализация не лучший первый шаг, безопаснее начинать с утилит, которые умеют восстановить разметку без перезаписи первых секторов. Но если ты работаешь с образом, инициализация иногда может быть частью контролируемого сценария восстановления.
4. Нужный период архива уже перезаписан циклической записью, или диск и так был “под замену” и на нем нет ценного окна. Если спасать нечего, можно перестать относиться к диску как к артефакту.
5. Ты точно знаешь, что хранение было “по-человечески” (например, отдельный раздел со стандартными MP4/TS/AVI), и есть основания думать, что служебные данные регистратора не лежат в первых секторах этого же диска. Это чаще встречается в VMS-сценариях и реже в классических DVR/NVR.

Когда инициализацию делать не стоит:

1. Это родной диск DVR/NVR с проприетарной разметкой или контейнерами (DAV/PS/сырой H.264/H.265), и тебе важны шкала времени, события, каналы, точные таймкоды. Инициализация может сломать метаданные, которые “склеивают” архив.
2. Диск входит в RAID регистратора (часто у NVR). Инициализация одного диска может осложнить сбор массива и снизить шанс восстановления.
3. Windows предлагает не только “инициализировать”, но и “создать том” или “отформатировать”. Вот форматирование уже реально пишет по диску и портит намного больше. Инициализация это легкое касание. Форматирование это уже “поехали катком”.

Практическое правило: инициализация становится “возможной” только когда у тебя есть образ диска и ты готов к тому, что восстановление может перейти из режима “открыть файлы” в режим “доставать видео по блокам и упаковывать”, иногда без идеальной привязки ко времени, если индексы потеряны. Если цель именно спасти архив как архив, самый безопасный порядок прежний: сначала образ, затем DVR-aware инструменты, и только потом любые эксперименты, всегда на копии.

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

• DiskInternals DVR Recovery

• DVR Examiner (включая линейку DVR Examiner / DVR Examiner Lite)

• Belkasoft Evidence Center (как комплексный инструмент, иногда применяют для видео-артефактов)

• Magnet AXIOM (тоже как комплексный инструмент, в зависимости от задач)

• X-Ways Forensics (в связке с ручным анализом и плагинами, когда нужно низкоуровнево)

• UFS Explorer (иногда используют для работы с нестандартными разметками и RAID, плюс ручные сценарии)

• R-Studio (как инструмент для работы с образами и разметками, чаще как вспомогательный)

• SalvationDATA (линейки для данных с DVR/NVR, в зависимости от региона и поставок)

• SysDev Laboratories (их продукты по восстановлению видео, в зависимости от линейки)

• VLC и FFmpeg (не “восстановление диска”, но часто используют для проверки и конвертации экспортированных dav/ps/h264 сегментов)

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

Преимущество SmartVision практичное и скучное, а значит хорошее. Архив хранится на стандартных дисках обычными файлами в mp4. Это значит, что диск не становится загадкой для Windows. Если пароль потерян или система перестала загружаться, архив можно просто скопировать как файлы без необходимости поднимать фирменные индексы и контейнеры. Да, VMS должна уметь корректно писать mp4 сегментами, защищаться от внезапных выключений и вести быстрые индексы. Но зато данные остаются доступными стандартными средствами, без “черных ящиков”.

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

Подход VMS, где архив хранится в mp4 на стандартных дисках, это другая философия: данные должны оставаться данными. И когда в очередной раз кто-то говорит “пароль? какой пароль?”, вы начинаете ценить открытые форматы, как ценят обычный ключ, который открывает дверь, а не загадку на три страницы.