Уровни хранения: горячий, тёплый, холодный, архив

Автор: Николай СапуновОбновлено: август 202618 мин чтения
Содержание статьи +

Коротко

Не каждый час записанного видео стоит одинаковых денег на хранение, и уровневое хранение – это практика сопоставления цены хранилища возрасту записи: быстрое и дорогое хранилище для последних дней, всё более дешёвое и медленное по мере старения записи к удалению. Четыре уровня, которые используют большинство команд, – горячий (мгновенный доступ, самая высокая цена за терабайт), тёплый (тоже мгновенный, но дешевле), холодный (выдача за минуты-часы, заметно дешевле) и архив (выдача за часы, самый дешёвый из всех). Разброс велик: в 2026 году облачное объектное хранилище идёт примерно от $23 за терабайт в месяц для горячего до примерно $1 для deep archive – почти 23-кратная разница за один и тот же терабайт. Подвох в том, что дешёвые в хранении уровни дороги при чтении, поэтому экономия реальна лишь тогда, когда политика жизненного цикла сама двигает запись вниз по уровням и вы верно угадали, как часто запись каждого возраста будут смотреть.

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

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

Одна идея: запись стареет и теряет ценность – значит, её хранилище должно дешеветь

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

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

Одно число из статьи про математику ретенции задаёт масштаб. Скромный объект на 40 камер, пишущий постоянно на 2 Mbps, генерирует около 21,6 ГБ на камеру в день, или примерно 0,86 ТБ по всему объекту каждый день. Держите это 90 дней – и в любой момент вы храните около 78 ТБ. Лежат ли эти 78 ТБ на одном дорогом уровне или размазаны по четырём – и есть разница, о которой эта статья.

Рис. 1. Запись стареет слева направо; каждый уровень меняет скорость выдачи на меньшую цену за терабайт – пока политика хранения её не удалит.

Четыре уровня: от горячего к архиву

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

Горячее хранилище держит запись в активном использовании: живые потоки, которые пишутся прямо сейчас, и примерно последние несколько дней – окно, где оператор или дознаватель вероятнее всего прокручивает видео на полной скорости. Горячее хранилище даёт мгновенный доступ – задержка в миллисекундах – и оно самое дорогое за терабайт. On-premises горячее – это быстрое твердотельное хранилище (NVMe или SSD) или быстрый RAID-массив на жёстких дисках, принимающий живую запись. В облаке это класс объектного хранилища по умолчанию, у Amazon – S3 Standard.

Тёплое хранилище держит запись, которая уже не в ежедневном ходу, но должна быстро вернуться по запросу – скажем, последние недели, период, на который ещё может ссылаться отчёт об инциденте. Тёплое сохраняет мгновенный доступ, но стоит заметно дешевле горячего; компромисс в том, что провайдер исходит из редкого чтения и берёт небольшую плату за каждое. On-premises тёплое – обычно массовый RAID на жёстких дисках, те самые ёмкие surveillance-диски, что держат основной объём записи. В облаке оно ложится на класс «нечастого доступа» – S3 Standard-IA или S3 Glacier Instant Retrieval.

Холодное хранилище держит запись, к которой обращаются редко, – месяцы, хранят по требованию политики, а не потому, что кто-то ждёт просмотра. Главная перемена на холодном уровне – мгновенный доступ исчезает: выдача холодной записи занимает от минут до нескольких часов, потому что хранилище оптимизировано под дешевизну, а не под скорость. Взамен цена за терабайт резко падает. У холодного нет точного on-prem-аналога на малой системе, но на больших это более медленный, плотный диск или nearline-библиотека; в облаке – архивный класс вроде S3 Glacier Flexible Retrieval.

Архивное хранилище – самый глубокий, дешёвый и медленный уровень: запись на долгий юридический срок, которую по сути никто не ждёт читать, где задержка выдачи в часах вполне приемлема, ведь вы достанете её лишь по повестке или для аудита. Архив – самое дешёвое хранилище за терабайт с большим отрывом. On-premises архив – классически магнитная лента: современные картриджи LTO хранят десятки терабайт каждый по несколько долларов за терабайт и лежат на полке, не потребляя энергии. В облаке это deep-archive-класс, например S3 Glacier Deep Archive, где выдача измеряется часами.

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

Рис. 2. Четыре уровня в сравнении – скорость доступа, частота чтения, носитель on-prem, класс в облаке и относительная цена.

Сколько стоит каждый уровень: математика цены за терабайт

Аргумент за уровни силён ровно настолько, насколько велик ценовой разрыв между ними, – поэтому посмотрите на реальные числа 2026 года. Облачное объектное хранилище публикует цены за гигабайт в месяц, и это самый чистый способ увидеть разброс; цифры ниже – прайс-лист Amazon S3 в главном регионе США, переведённый в доллары за терабайт в месяц для удобства сравнения.

УровеньКласс в облаке (пример)Цена за ТБ / месЗадержка чтения
ГорячийS3 Standard~$23,00миллисекунды
ТёплыйS3 Standard-IA~$12,50миллисекунды (+ плата за выдачу)
Тёплый/ХолодныйS3 Glacier Instant Retrieval~$4,00миллисекунды (+ плата за выдачу)
ХолодныйS3 Glacier Flexible Retrieval~$3,60минуты-часы
АрхивS3 Glacier Deep Archive~$0,99часы

Прочтите верхнюю и нижнюю строки вместе: хранение терабайта на горячем уровне стоит около $23 в месяц; тот же терабайт на deep archive – около $1. Это почти 23-кратная разница за хранение одной и той же записи, и в ней вся причина существования уровней. Самый дешёвый уровень не на 10% дешевле – он более чем на 95% дешевле.

On-premises экономика рифмуется, хотя хранилище вы покупаете разово, а не арендуете помесячно. В 2026 году примерные цены покупки за терабайт – около $60-80 за быстрое твердотельное NVMe (горячий), около $18 за специализированные surveillance-диски (тёплый) – например, линейки Western Digital Purple или Seagate SkyHawk – и около $5 за терабайт за картриджи LTO (архив), которые к тому же не потребляют энергию на полке. Форма та же: горячий уровень стоит за терабайт примерно на порядок дороже архивного.

Одна особенность 2026 года, которую стоит знать, потому что она делает уровни ценнее в этом году, чем в прошлом: цены на жёсткие диски подскочили – отраслевые трекеры сообщили о среднем росте около 46% за четыре месяца – а корпоративные твердотельные накопители подорожали ещё сильнее на дефиците чипов памяти, расширив разрыв между быстрым и массовым хранилищем. Когда быстрое хранилище дорожает относительно массового, штраф за оставленную не на том уровне старую запись растёт. Уровни – хедж ровно против этого.

Рис. 3. Цена облака за терабайт в месяц, от горячего к архиву – разрыв цен, ради которого уровни стоят усилий (прайс 2026, иллюстративно).

Политика жизненного цикла: правило, которое само двигает запись вниз

Уровни экономят деньги, только если запись действительно перемещается между ними, а вручную для миллионов видеофайлов этого никто делать не будет. Механизм, который это автоматизирует, – политика жизненного цикла (lifecycle policy), набор правил по возрасту, иногда называемый управлением жизненным циклом информации (ILM): когда запись достигает такого-то возраста – перенести на такой-то дешёвый уровень; когда достигнет конца срока хранения – удалить.

В облачном хранилище это полноценная функция. Конфигурация S3 Lifecycle у Amazon позволяет задать правила перехода («через 7 дней – в Standard-IA; через 30 – в Glacier Flexible Retrieval; через 90 – в Deep Archive») и правило истечения («через 365 дней – удалить»), и платформа автоматически применяет их к каждому объекту. Есть и вариант «без рук» – S3 Intelligent-Tiering, который следит, как часто каждый файл реально читают, и сам двигает его между уровнями частого, нечастого и архивного доступа, беря небольшую плату за мониторинг вместо того, чтобы требовать угадать схему доступа заранее. On-premises VMS-платформы и системы хранения реализуют ту же идею через свои функции архивирования и иерархического хранения, перенося стареющую запись с быстрого массива на массовый диск и на ленту по заданному вами расписанию.

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

Рис. 4. Политика жизненного цикла переводит запись на дешёвые уровни по мере старения и удаляет в лимит хранения – всё автоматически.

Пример с числами: один счёт тремя способами

Поставим числа. Возьмём объект, хранящий 100 ТБ записи при сроке 90 дней, с ровным ежедневным притоком видео. Раз приток ровный, объём записи каждого возраста одинаков – десятая часть лежит в любой 9-дневной полосе, – поэтому доля на каждом уровне есть просто доля от 90 дней, которую этот уровень покрывает.

Сначала наивная схема: держать всё на горячем уровне.

100 ТБ × $23 / ТБ-мес = $2 300 в месяц

Теперь по уровням. Скажем, последние 7 дней остаются горячими (операторы прокручивают их вживую), дни 8-30 уходят в тёплый, дни 31-90 – в холодный:

Горячий (дни 1-7):    7/90 × 100 ТБ =  7,8 ТБ × $23,00 = $179
Тёплый  (дни 8-30):  23/90 × 100 ТБ = 25,6 ТБ × $12,50 = $320
Холодный(дни 31-90): 60/90 × 100 ТБ = 66,7 ТБ × $3,60  = $240
                                              итого ≈ $739 в месяц

Уровневая схема стоит около $739 в месяц вместо $2 300 – почти на 68% меньше – а оператор, открывающий вчерашнюю или прошлонедельную запись, не замечает ничего, потому что всё в пределах 30 дней по-прежнему на хранилище мгновенного доступа. Спустите самую старую запись в deep archive вместо холодного, на системе с годовым сроком хранения, – и экономия вырастет ещё, потому что та нижняя полоса схлопывается с $3,60 до примерно $1 за терабайт.

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

Ловушка стоимости выдачи: дёшево хранить, дорого читать

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

«Частая ошибка: считать цену хранения архивного уровня всей ценой. Холодный и архивный уровни берут отдельную плату за выдачу при каждом чтении данных наружу, и на глубоких уровнях эта плата может затмить месяц хранения. Если расследование вынуждает вытащить десятки терабайт холодной записи, плата за выдачу – плюс ожидание, которое на deep archive может идти часами, – способна стереть месяцы экономии за один вечер. Лекарство – уровень по тому, как часто запись реально читают, а не только по возрасту: если класс записи поднимают для расследований хотя бы изредка, ему место на уровне с дешёвой или мгновенной выдачей, а не в deep archive. Угадайте схему доступа неверно – и «дешёвый» уровень станет дорогим.»

Вторая ловушка – минимальные сроки хранения. Дешёвые облачные уровни берут плату за минимальный срок, когда бы вы ни удалили: 30 дней для нечастого доступа, 90 для классов Glacier, 180 для Deep Archive. Если ваша политика удаляет запись на 30-й день, а вы перенесли её на уровень с 90-дневным минимумом, вы всё равно платите за 90 дней – уровень был дешевле за месяц, но месяцев вы купили больше, чем нужно. Правило простое: никогда не переносите запись на уровень, чей минимальный срок длиннее времени, что вы её реально продержите. Короткому сроку место на горячем и тёплом; глубокие уровни заслуживает лишь долгий срок.

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

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

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

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

У этой границы есть одно практическое следствие, и именно поэтому уровни и VMS надо проектировать вместе. Если запрос дотягивается до холодного или архивного уровня, запись не вернётся за миллисекунды – на восстановление уровня могут уйти минуты или часы. VMS, ждущая мгновенного воспроизведения, может отвалиться по таймауту или просто ничего не показать. Поэтому схема уровней должна соответствовать ожиданиям VMS и операторов: держите всё, что нужно прокручивать мгновенно, на горячем или тёплом, а холодный и архивный уровни считайте намеренным путём «запроси и жди» для старой записи, а не тем, во что оператор врезается случайно посреди расследования. Железо, держащее эти уровни on-premises – быстрый массив, массовый RAID, ленточная библиотека – тема нашей статьи про архитектуру хранилища on-prem; облачная и гибридная сторона, включая стоимость egress и выдачи в деталях, разобрана в облачном и гибридном хранилище для видеонаблюдения.

Рис. 5. ONVIF Profile G стандартизирует интерфейс записи и выдачи; уровни и движок жизненного цикла живут в слое хранения под ним – и выдача с глубокого уровня не мгновенна.

Уровни – ещё и рычаг хранения и приватности

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

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

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

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

Ключевые выводы

  • Уровни сопоставляют цену хранилища возрасту записи: быстро и дорого для свежего, дёшево и медленно для старого.
  • Четыре уровня – горячий, тёплый, холодный, архив – меняют меньшую цену за терабайт на более медленную выдачу.
  • Облако: разброс ~23× от горячего (~$23/ТБ-мес) до deep archive (~$1/ТБ-мес); on-prem рифмуется.
  • Политика жизненного цикла сама двигает запись вниз по возрасту – и удаляет в лимит хранения.
  • Уровни на объекте 100 ТБ / 90 дней могут срезать счёт примерно на две трети без видимых перемен.
  • Дешёвые уровни дороги при чтении: помните о плате за выдачу, минимальных сроках и не пишите прямо в архив.

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

Строите такую систему?

Подберём параметры кодирования под ваш контент и посчитаем стоимость доставки до старта разработки.