Холодное хранение архивов: что выбрать в 2026

MAATRIX

Годовые бэкапы баз, отчётность за прошлые периоды, архив проектов, к которым не притрагивались три года — всё это данные, которые нельзя удалить, но и не нужно держать под рукой на быстром диске. Если такой архив лежит на том же NVMe, что и рабочая база, вы просто переплачиваете за скорость, которая никому не нужна. Ниже — три рабочих варианта холодного хранения, с честными цифрами, компромиссами и методикой, как выбрать между ними, не гадая.

Что такое "холодное" хранение и зачем оно вообще нужно

Данные делятся не по возрасту, а по частоте обращения. "Горячие" — это то, что читается и пишется постоянно: рабочая база, файлы активного проекта, логи за последнюю неделю. Для них важна скорость — задержка в миллисекунды, диск NVMe или SSD, потому что каждое лишнее ожидание бьёт по пользователю или процессу.

"Холодные" данные — противоположность. Годовой архив бухгалтерии, который обязаны хранить по закону, но открывают раз в год на проверке. Бэкапы трёхлетней давности, которые нужны только если случится катастрофа и придётся восстанавливать состояние "как было". Отснятый видеоархив проекта, который закрыт. К такому не обращаются неделями и месяцами, но потерять его нельзя — иногда по закону, иногда потому что восстановить неоткуда.

Ошибка, которая стоит денег в обе стороны: держать холодные данные на дорогом быстром хранилище (переплата за ненужную скорость) или, наоборот, решить, что раз данные редкие — с ними можно не церемониться и хранить на честном слове без резервной копии (тогда единственная копия исчезнет вместе с диском). Правильный ответ — не "какое хранилище лучше", а "какой компромисс между ценой, надёжностью и временем восстановления подходит под конкретный архив".

Дальше — три реальных варианта, которыми это решается на практике.

Вариант 1: архивные тарифы облачных объектных хранилищ

У большинства объектных хранилищ (S3-совместимых) есть отдельный класс хранения для холодных данных — существенно дешевле обычного "горячего" тарифа за гигабайт в месяц. У AWS это линейка S3 Glacier (Instant Retrieval, Flexible Retrieval, Deep Archive), у Yandex Object Storage — класс ICE, у Selectel и других S3-совместимых провайдеров — свои аналоги под похожими названиями. Суть одна: вы платите в разы меньше за хранение, но получаете два ограничения, которые нельзя игнорировать.

Первое — время восстановления (retrieval time) не мгновенное. В зависимости от класса и провайдера это может быть от нескольких минут до нескольких часов, а у самых дешёвых архивных тарифов (типа Glacier Deep Archive) — до 12–48 часов при "экономном" режиме извлечения. Конкретные цифры и правила у каждого провайдера свои и меняются — перед тем как класть туда что-то критичное, проверьте актуальные SLA по retrieval time именно на момент, когда вы это читаете, а не верьте цифрам из старой статьи.

Второе — извлечение данных обратно стоит отдельных денег. Это не разовая мелочь: тариф за retrieval считается за каждый гигабайт, который вы скачиваете обратно, и может быть сопоставим по деньгам или даже дороже, чем месяцы хранения. Если архив в 5 ТБ придётся восстанавливать целиком (а не выборочно), эта плата всплывает как неприятный сюрприз в счёте — именно поэтому её нужно закладывать в расчёт заранее, а не постфактум.

Практическая механика для S3-совместимого архивного хранилища:

# Загрузка файла сразу в архивный класс (пример для AWS CLI, S3 Glacier)
aws s3 cp ./backup-2025.tar.zst s3://my-cold-archive/ \
  --storage-class GLACIER

# Инициировать восстановление объекта (появится через часы, не сразу)
aws s3api restore-object \
  --bucket my-cold-archive \
  --key backup-2025.tar.zst \
  --restore-request '{"Days":7,"GlacierJobParameters":{"Tier":"Standard"}}'

# Проверка статуса восстановления
aws s3api head-object --bucket my-cold-archive --key backup-2025.tar.zst

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

Вариант 2: своё хранилище на обычных HDD

Второй вариант — не облачный архивный тариф, а обычный механический диск большого объёма (сейчас это диски на 16–24+ ТБ) на арендованном или своём сервере. По цене за гигабайт HDD дешевле SSD/NVMe в разы, и для данных, где скорость доступа не критична, это разумный компромисс: вы platите за место, а не за скорость, которая не нужна.

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

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

Практические нюансы, которые стоит знать заранее:

• Большие HDD (18 ТБ и выше) в RAID 5 — рискованная комбинация: время ребилда массива после отказа одного диска растёт вместе с объёмом, и вероятность второго отказа именно во время ребилда — не теория, а статистика. Если держите архив в RAID, посмотрите разбор почему RAID 5 на больших дисках опасен — для холодного архива обычно разумнее RAID 6 или ZFS с двойной чётностью.
• Диски, которые почти не крутятся (архив читают редко), всё равно нужно мониторить — SMART-атрибуты предсказывают деградацию до того, как диск умрёт полностью. Разбор конкретных показателей — в статье SMART: какие показатели предсказывают смерть диска.
• Архив на HDD без второй копии (хоть в облаке, хоть на офлайн-носителе) — это не резервная копия, это единственная копия. Правило "3-2-1" (три копии, два разных носителя, одна вне основной площадки) для архивов работает так же, как для рабочих данных.

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

Вариант 3: офлайн-носители — диски, отключённые от сети

Третий вариант — самый низкотехнологичный и при этом самый устойчивый к одной конкретной угрозе: сетевым атакам и шифровальщикам. Внешний диск, который физически отключён от сети (offline / air-gapped), не может быть зашифрован вирусом-вымогателем, потому что до него физически нельзя дотянуться, пока кто-то не подключит его руками. Это единственный вариант из трёх, который даёт такую гарантию по умолчанию — и облачный архив, и сервер с HDD остаются сетевыми ресурсами, а значит теоретически достижимыми при компрометации учётных данных или инфраструктуры.

Плата за эту устойчивость — дисциплина. Офлайн-носитель нужно:

• физически где-то хранить (в идеале — не в том же здании, что основные данные, иначе пожар или кража решают проблему за вас);
• регулярно обновлять и ротировать: если бэкап на диске не обновлялся полгода, а рабочие данные изменились, вы восстановите устаревшее состояние;
• проверять на читаемость — диск, который два года пролежал в ящике, не гарантированно включится и прочитается с первого раза;
• защищать физически — от кражи, потери, повреждения при переезде, банального "диск отдали не тому человеку".

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

# Пример: инкрементальный бэкап на подключённый внешний диск с проверкой
rsync -av --delete /data/archive/ /mnt/external-drive/archive/
# Проверка целостности после копирования
sha256sum -c /mnt/external-drive/archive/checksums.sha256
# После проверки — отключить диск от сети/компьютера

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

Сравнение трёх вариантов

Цифры по стоимости и retrieval у облачных провайдеров нужно смотреть на момент принятия решения — тарифы и правила меняются, а расхождение между "дешёвым" и "дорогим" архивным классом может быть кратным.

Частые вопросы