Локальное хранилище: NVR, SAN, NAS и RAID

Коротко

Локальное хранение видеонаблюдения складывается из двух решений, поставленных одно на другое: где лежат диски относительно сервера записи – подключены напрямую (DAS), доступны по сети как файлы (NAS) или доступны по сети как сырые блоки (SAN) – и как эти диски сгруппированы с помощью RAID, чтобы один, а то и два, могли отказать без потери записи. Видеонаблюдение – необычная нагрузка на хранилище, потому что десятки камер пишут непрерывно и почти ничего не читается обратно, так что вы считаете под устойчивую пропускную способность записи и круглосуточный ресурс, а не только под ёмкость. Отказ, который решает, была ли архитектура хорошей, – это выпадение диска посреди инцидента: RAID продолжает писать сквозь него, но ребилд после этого медленный на нынешних больших дисках и сам по себе самое опасное окно, поэтому RAID 6 с двойной чётностью в основном вытеснил RAID 5 с одинарной для крупных массивов. Ничего из этого не видно программе видеонаблюдения, которая обращается к записи через один и тот же интерфейс ONVIF Profile G, лежат ли байты на одном внутреннем диске или в массиве из сорока дисков.

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

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

Одна мысль: ёмкость – лёгкая половина; пережить запись и мёртвый диск – сложная

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

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

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

Где физически оседает запись: DAS, NAS и SAN

Первое решение – как сервер записи (машина с ПО записи, будь то специализированный сетевой видеорегистратор – NVR, коробка, которая пишет IP-камеры, – или Video Management System, VMS, программная платформа, которая записывает и управляет многими камерами в масштабе) дотягивается до своих дисков. Ответов три, и разница между ними – в том, что сервер видит на другом конце провода.

Прямое подключение (DAS, direct-attached storage) – самое простое: диски стоят внутри сервера или в корпусе расширения, прикрученном прямо к нему коротким кабелем по тем же интерфейсам SATA или SAS, что и внутренний диск (SATA и SAS – два стандартных интерфейса, которые подключают диск к компьютеру). Сервер владеет этими дисками целиком; больше до них ничто не дотянется. DAS – самый дешёвый вариант с наименьшей задержкой, потому что в пути нет сети, и именно поэтому почти каждый малый и средний NVR – это DAS внутри одной коробки. Его предел – масштаб: когда корпус заполнен, вы в основном закончили, а рост обычно означает добавление целого нового сервера, а не просто дисков.

Сетевое хранилище (NAS, network-attached storage) выносит диски в сеть и отдаёт их как файлы. NAS – это сам по себе небольшой прибор со своими дисками и операционной системой, и он отдаёт сети общие папки по протоколам файлового обмена – SMB (протокол файлового обмена Windows) или NFS (его аналог в Unix). Сервер просит у NAS файл по имени, как вы открываете документ с общего диска. NAS удобен и дёшев в росте, но есть подвох, на котором спотыкаются многие новички: большинство ПО видеонаблюдения не пишет live-видео прямо на NAS надёжно, потому что файловый обмен добавляет накладные расходы и задержку, которые непрерывный многокамерный поток записи плохо переносит. На практике NAS зарабатывает место на бэкенде системы видеонаблюдения – как архивный уровень, куда переносят старую запись, – а не как основная цель записи.

Сеть хранения (SAN, storage-area network) тоже выносит диски в сеть, но отдаёт их как сырые блоки, а не файлы. «Блочный уровень» означает, что SAN отдаёт серверу кусок сырого хранилища, который сервер воспринимает ровно как локальный диск: он кладёт на него свою файловую систему и управляет им сам, никогда не зная, что диск на самом деле через комнату. Сервер дотягивается до SAN по одному из двух транспортов – iSCSI, который несёт трафик хранения по обычному Ethernet и IP (дешевле и гибче), или Fibre Channel, отдельной высокоскоростной кабельной фабрике под хранение (быстрее и дороже). Поскольку SAN отдаёт сырые блоки с низкой задержкой, он несёт ту непрерывную нагрузку записи, которую NAS не может, а поскольку к одному SAN могут подключаться многие серверы, это стандартный способ строить крупные многосерверные развёртывания, где хранилище объединено в пул и управляется централизованно.

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

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

Та же картина в виде таблицы, с углом видеонаблюдения на каждый случай.

RAID: превращаем много дисков в один, который переживёт отказ

Выбор того, где лежат диски, никак не защищает запись, если диск умрёт, – а диски умирают. Защиту даёт RAID, что расшифровывается как Redundant Array of Independent Disks (избыточный массив независимых дисков): практика группировки нескольких физических дисков так, чтобы операционная система видела один логический диск, устроенный так, что отказ диска не теряет данные. RAID делает это тремя кирпичиками, и каждый «уровень» RAID – это свой их рецепт. Чередование (striping) распределяет данные по дискам, чтобы несколько могли читать и писать одновременно, что добавляет скорость, но само по себе никакой защиты. Зеркалирование (mirroring) держит полный дубликат данных на втором диске, так что копия переживает любой одиночный отказ. Чётность (parity) – хитрая: массив вычисляет компактную математическую сводку данных (блок чётности) и хранит её, так что при потере одного диска его содержимое можно восстановить из уцелевших дисков плюс чётности – защита ценой всего одного диска вместо полного дубликата.

Уровней, важных для видеонаблюдения, пять.

RAID 0 – это только чередование, чистая скорость и нулевая избыточность. Потеряйте любой один диск – и весь массив пропал. Ему нет места под записанным видеонаблюдением; упомянут лишь для того, чтобы вы случайно его не выбрали.

RAID 1 – это прямое зеркало из двух дисков: всё, что пишется на один, пишется на другой. Он переживает отказ одного диска и даёт половину сырой ёмкости как полезное место. Просто и надёжно, но не растёт за пределы пары, так что подходит малому серверу, а не крупному массиву.

RAID 5 чередует данные по трём и более дискам и рассыпает между ними один набор чётности. Он переживает потерю любого одного диска и даёт полезную ёмкость всех-кроме-одного дисков – RAID 5 из четырёх дисков по 12 ТБ даёт около 36 ТБ полезных. Два десятилетия RAID 5 был выбором по умолчанию, потому что дёшево покупает защиту от одного диска. Как мы увидим, большие современные диски его подорвали.

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

RAID 10 сочетает зеркалирование и чередование: диски разбиты на зеркальные пары, а данные чередуются по парам. Он даёт половину сырой ёмкости как полезное место (как зеркало), но добавляет скорость чередования и, что важно, восстанавливается быстро, потому что восстановление заменённого диска означает лишь копирование с его зеркала, а не пересчёт чётности по всему массиву. Это выбор, когда производительность записи и быстрое восстановление важнее, чем выжать ёмкость.

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

Разобранный пример ёмкости, потому что математика полезного места удивляет. Возьмите восемь дисков по 12 ТБ – 96 ТБ сырых. В RAID 6 вы теряете два диска на чётность, так что полезная ёмкость – (8 − 2) ÷ 8 × 96 ТБ = 6 ÷ 8 × 96 = 72 ТБ полезных. Эти 72 ТБ – до накладных файловой системы и запаса, который стоит оставить (никогда не заполняйте массив видеонаблюдения выше ~80%), так что плановая цифра ближе к 58 ТБ по-настоящему полезного места. Урок математики: избыточность не бесплатна, и сырых дисков вы покупаете заметно выше полезной цели. Наша статья про математику ретенции проходит накладные «сырое → с запасом» целиком.

Почему запись видеонаблюдения необычна

Теперь часть, которую офисные руководства по хранению путают для видеонаблюдения: штраф записи (write penalty). Когда уровень RAID использует чётность, каждое изменение данных должно ещё и обновить чётность, и это превращает одну логическую запись в несколько физических дисковых операций. Стандартные цифры таковы: RAID 1 и RAID 10 несут штраф ×2 (пишут данные дважды, в обе половины зеркала); RAID 5 несёт штраф ×4 (чтобы изменить полосу, надо прочитать старые данные, прочитать старую чётность, записать новые данные, затем записать новую чётность – четыре операции); а RAID 6 с двумя чётностями несёт штраф ×6. Для офисной нагрузки с преобладанием чтения это редко кусается, потому что у чтения штрафа нет. Для видеонаблюдения, которое почти всё запись, штраф ложится почти на каждую операцию.

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

40 камер × 4 Mbps = 160 Mbps
160 Mbps ÷ 8 бит на байт = 20 МБ/с непрерывной записи

Двадцать мегабайт в секунду звучит пустяком – один современный диск тянет вдесятеро больше последовательно. Но это логическая скорость записи, и она предполагает, что каждая камера пишет непрерывно; стратегия записи, которую вы выберете – непрерывная, по движению или по событию, – задаёт, какая часть этой нагрузки на самом деле устойчива. Положите её на RAID 6 с его штрафом ×6 – и диски массива делают работу до 120 МБ/с сырых операций, и эта нагрузка не прекращается ни днём, ни ночью, всю жизнь системы. Масштабируйте до 200 камер по 6 Mbps – и логическая скорость записи 150 МБ/с до штрафа; теперь вы считаете шпиндели и контроллеры под пропускную способность, а не под терабайты. Две вещи спасают бюджет. Аппаратный RAID-контроллер (выделенная плата, управляющая массивом) с батарейным кэшем записи поглощает всплески и собирает много мелких записей в эффективные полнополосные, что обходит большую часть штрафа чётности; батарея означает, что внезапная потеря питания не теряет кэшированные записи. И сами диски должны быть для этого построены.

Диски для видеонаблюдения – другой продукт

Диск для видеонаблюдения – линейки Western Digital Purple, Seagate SkyHawk – это не тот же продукт, что настольный диск, и разница построена ровно под эту запись-доминантную круглосуточную службу. Их отличают три вещи. Они несут куда более высокий рейтинг нагрузки – объём данных, который производитель сертифицирует диску читать и писать в год: обычные настольные диски рассчитаны примерно на 55 ТБ в год, тогда как диски для видеонаблюдения рассчитаны от примерно 180 ТБ/год на младших моделях до 360 ТБ/год на старших, а топовые семейства SkyHawk AI и WD Purple Pro достигают 550 ТБ/год. Непрерывный многокамерный поток записи проскакивает рейтинг настольного диска за месяцы; вот что «рассчитан на 24/7» значит в цифрах. Они терпят вибрацию множества дисков, вращающихся в одном корпусе, с датчиками, которые компенсируют, чтобы шестнадцатидисковый корпус не растряс свои же диски в ошибки. И их прошивка использует потоковый набор команд, который приоритезирует запись входящего потока над идеальным перечитыванием старых данных – верный компромисс для регистратора, где потерянный кадр хуже на миг задержанного чтения; те же семейства валидированы под большое число камер (WD Purple называет до 64 камер на диск).

«Частая ошибка: ставить SMR-диски в массив видеонаблюдения. Современные жёсткие диски бывают двух стилей записи. CMR (conventional magnetic recording) пишет на неперекрывающиеся дорожки и держит ровную скорость записи. SMR (shingled magnetic recording) накладывает дорожки внахлёст, как черепицу, чтобы дёшево упаковать больше ёмкости, но перекрытие дорожек означает, что запись часто вынуждена переписывать соседей, так что под устойчивой нагрузкой записи маленький быстрый буфер диска заполняется за минуты, а пропускная способность падает до единиц мегабайт в секунду. В регистраторе видеонаблюдения это потерянные кадры; в ребилде RAID – хуже: SMR-диск застревает так сильно, что RAID-контроллер объявляет его отказавшим и выбрасывает из массива, превращая поправимую ситуацию в потерянную. Диски для видеонаблюдения всегда CMR именно поэтому. Сверяйте номер модели со списком CMR/SMR производителя перед каждой покупкой – вендоры тихо отгружали SMR-диски в потребительские линейки, и один такой в массиве видеонаблюдения – бомба замедленного действия.»

Размер под устойчивую запись, а не только под ёмкость

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

Две практические детали завершают проект. Hot spare (горячий резерв) – это запасной диск, который стоит в массиве без дела, пока другой диск не откажет, после чего контроллер автоматически вводит его и начинает ребилд на него, не дожидаясь человека; на необслуживаемом регистраторе этот автоматический старт может быть разницей между несколькими часами и несколькими днями уязвимости. А выбор между аппаратным RAID-контроллером (выделенная плата, обычно с тем самым батарейным кэшем) и программным RAID (операционная система считает чётность на основном процессоре) сводится к нагрузке записи: видеонаблюдение в целом за аппаратный контроллер, потому что разгрузка вычисления чётности и кэширование записей – ровно то, что нужно непрерывному потоку записи.

Главный отказ: диск выпадает во время инцидента

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

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

Затем приходит ребилд, и ребилд – опасная часть. Когда вы заменяете мёртвый диск (или включается hot spare), массив должен восстановить каждый байт, живший на отказавшем диске, и записать его на замену, что на нынешних больших дисках медленно. Восстановление одного большого диска читает по всем уцелевшим дискам и рутинно занимает от 12 до 24 часов, а на загруженном или плохо рассчитанном массиве может растянуться на дни. Всё это окно массив всё ещё деградирован и теперь работает тяжелее обычного, и две конкретные опасности складываются.

Первая опасность – второй отказ диска во время ребилда. На RAID 5, который переживает лишь один отказ, второй умирающий диск посреди ребилда теряет весь массив – а тяжёлая, устойчивая нагрузка чтения ребилда по стареющим дискам, купленным все в одно время, – именно тот момент, когда второй отказ наиболее вероятен. Вторая опасность тоньше и есть причина, по которой опытные проектировщики отказались от RAID 5 для больших дисков: неустранимая ошибка чтения, или URE (unrecoverable read error). У каждого жёсткого диска есть крошечная заявленная доля битов, которые он может не прочитать обратно, – для потребительских дисков примерно одна ошибка на каждые 10^14 бит, что грубо одна нечитаемая секция на 12,5 терабайт чтения. Ребилд RAID 5 должен успешно прочитать каждый байт на всех уцелевших дисках, и как только эти диски достаточно велики, суммарный объём, читаемый при ребилде, приближается к этому порогу ошибки – так что у ребилда есть реальный шанс наткнуться на нечитаемую секцию, что на RAID 5 с одинарной чётностью означает провал восстановления и потерю данных. Чтение каждого байта пятидискового массива из дисков по 12 ТБ при ребилде сканирует около 44 ТБ – того же порядка, что потребительский предел URE. Эта математика – причина, почему RAID 6 с его второй чётностью – стандарт для любого большого современного массива: он переживает второй отказ диска и стряхивает URE при ребилде, потому что у него остаётся ещё один слой защиты. RAID 10 обходит проблему иначе – ребилд там лишь копирует с одного зеркального партнёра, читая несколько терабайт вместо сорока, так что и время ребилда, и риск URE намного меньше.

«Частая ошибка: RAID 5 на больших дисках, без hot spare, без запаса. Классический локальный отказ видеонаблюдения – массив из четырёх дисков по 16 ТБ в RAID 5, заполненный под завязку, без hot spare, рассчитанный так, что нагрузка записи ровно равна дискам. Он пишет идеально два года. Затем диск отказывает во время инцидента; массив уходит в деградацию и начинает терять кадры, потому что не было запаса по пропускной способности; админ меняет диск через день; многодневный ребилд молотит три уцелевших диска того же возраста; один из них выдаёт URE – и запись инцидента пропала. Каждый шаг был избегаем: RAID 6 вместо RAID 5, hot spare для немедленного старта ребилда и запас 20–30% по пропускной способности, чтобы деградированный режим всё равно успевал.»

Вывод прямой. Инцидент – ровно тот момент, когда массив не должен отказать, так что архитектуру судят не по тому, как она работает здоровой, а по тому, как она ведёт себя с мёртвым диском внутри. Это означает RAID 6 с двойной чётностью (или RAID 10) на любом сколько-нибудь крупном массиве, hot spare, чтобы ребилд стартовал в тот миг, когда диск умирает, CMR-диски для видеонаблюдения, которые не застрянут на ребилде, и достаточный запас по пропускной способности, чтобы деградированный режим всё равно писал каждый кадр. Надёжность здесь ещё и доказательственный вопрос: запись, которая существует, но нечитаема, когда нужна следствию, для практических целей – запись, которую вы не сохранили; поэтому международный стандарт систем видеонаблюдения IEC 62676 трактует доступность и целостность хранения как системные требования, а не как запоздалую мысль.

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

Где место стандартам: ONVIF Profile G и слой хранения

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

Граница чистая. Profile G стандартизирует интерфейс к записанному видео – как ПО просит клип с заданной камеры и времени и получает его обратно. Он ничего не говорит о том, что держит байты: DAS, NAS или SAN; сгруппированы ли диски как RAID 5, 6 или 10; идёт ли под низом ребилд. Всё это живёт в слое хранения под VMS, и с точки зрения ПО запрос приходит через тот же интерфейс Profile G, что бы ни было внизу. Помните правило из нашего разбора ONVIF: ONVIF гарантирует базовый уровень, которому соответствуют обе стороны, а не реализацию под ним. За коммерческим обзором того, как профили ложатся на реальные продукты, спутник – гид Фора Софт по профилям ONVIF в системах безопасности.

Это разделение и делает архитектуру хранения свободным инженерным выбором, а не ограничением ПО. Вы можете начать развёртывание на дисках прямого подключения в регистраторе, позже объединить хранилище на SAN по мере роста числа камер и перенести старую запись в архив NAS или вверх в облако – и всё это без того, чтобы приложение видеонаблюдения меняло, как оно пишет или выдаёт, потому что каждый путь по-прежнему говорит на Profile G. Распределение этой записи по возрасту между быстрым и дешёвым хранилищем – тема нашей статьи про уровни хранения, а облачную и гибридную сторону покрывает облачное и гибридное хранение для видеонаблюдения. Системное планирование ёмкости, избыточности и доступности по всему развёртыванию – тема статьи масштабирование VMS.

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

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

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

Главное

• Локальное хранение складывает два выбора: топологию (DAS, NAS или SAN) и уровень RAID.
• DAS подключает диски напрямую; NAS отдаёт файлы (только архив); SAN отдаёт блоки (пишет live).
• Видеонаблюдение доминируется записью, так что считайте под устойчивую запись, не только ёмкость.
• Берите CMR-диски для видеонаблюдения; SMR-диск застрянет на ребилде и будет выброшен.
• RAID 6 (двойная чётность) – стандарт для больших массивов; RAID 5 проваливает математику ребилда.
• Выпадение диска посреди инцидента – настоящая проверка: hot spare, запас, двойная чётность.

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

• Как работает хранение видеонаблюдения: математика ретенции
• Уровни хранения: горячий, тёплый, холодный и архив
• Облачное и гибридное хранение для видеонаблюдения