Холодный архив не трогали три года: как проверить, что он жив

MAATRIX

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

Почему «лежит и не трогали» — это не то же самое, что «архив цел»

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

Здесь легко попасть в ту же ловушку, что и с обычными бэкапами: «мы же его создали, контрольная сумма при создании сошлась — значит, всё нормально». Это верно только для момента создания. Дальше архив живёт своей жизнью на носителе, который стареет, и предположение «раз проверили один раз — можно не проверять больше никогда» не выдерживает горизонта в три-пять-десять лет. Разница между обычной проверкой восстановления бэкапа и проверкой холодного архива — в частоте и методе: рабочий бэкап проверяют восстановлением раз в месяц, потому что он меняется каждый день и стоимость ошибки высока прямо сейчас. Холодный архив почти не меняется годами, и для него имеет смысл не такая частая, но обязательная проверка — не «раз и забыли».

Что портится, пока до архива никому нет дела

Деградация холодных данных бывает двух принципиально разных типов, и путать их не стоит — у них разные причины и разные способы обнаружения.

Физическая деградация носителя. Механический жёсткий диск, который годами не включали, — не гарантированно исправен, когда его наконец подключают: подшипники и смазка деградируют от времени, а не только от наработки часов, головки могут «залипать» на пластинах (stiction), особенно после длительного простоя без вращения. У SSD и флеш-накопителей проблема другая и менее очевидная: заряд в ячейках NAND-памяти постепенно утекает без питания, и производители прямо указывают в спецификациях ограниченный срок хранения данных без подключения к сети — обычно порядка года при комнатной температуре для потребительских SSD, меньше при повышенной температуре хранения. Это не теоретическая угроза, а прямо документированное поведение носителя — SSD для холодного архива на десятилетия годится плохо именно поэтому. У ленточных накопителей (LTO) своя специфика — усадка и слипание слоёв ленты требуют периодической перемотки, обычно раз в год-два, просто чтобы лента физически не испортилась от долгого лежания в одном положении.

Тихая порча данных (bit rot). Даже если носитель физически исправен, отдельные биты могут «переворачиваться» на файловой системе без контроля чётности — без RAID с проверкой или ZFS/Btrfs с чексуммами эта порча никак не всплывает: файл открывается, размер тот же, ошибки никто не увидит, пока не сравнят содержимое с эталоном. Отдельно от порчи самих данных бывает порча метаданных архива — индекс каталога, оглавление tar-архива, таблица файлов — когда сами данные физически целы, но найти или прочитать их без ошибок уже нельзя. Диски в RAID-массиве, кстати, эту проблему частично ловит фоновая проверка секторов — если у вас архив лежит на RAID, стоит убедиться, что скрабинг диска на нём действительно настроен и выполняется, потому что скрабинг ловит битые сектора на уровне блоков, но не проверяет содержимое файлов на уровне приложения — это разные, дополняющие друг друга проверки, и подробнее о том, какое холодное хранилище вообще выбрать под конкретный архив, разобрано в статье про варианты холодного хранения архивов.

Периодичность: раз в год-два, и почему не чаще и не реже

Для рабочих бэкапов частая проверка оправдана — данные меняются каждый день, и цена ошибки при аварии высока прямо сейчас. Для холодного архива логика другая: деградация носителя и bit rot — процессы медленные, растянутые на годы, а вот стоимость самой проверки для холодных данных часто немаленькая. Если архив лежит в архивном классе облачного хранилища (S3 Glacier, Yandex ICE и аналоги), retrieval данных обратно стоит отдельных денег и может занимать часы — проверять такой архив ежемесячно означает регулярно платить за то, что почти наверняка не изменилось. Проверять раз в пять-десять лет — значит рисковать тем, что накопившаяся порча станет необратимой (например, если единственная резервная копия за это время тоже успеет испортиться, а вы узнаете об обеих проблемах одновременно).

Раз в год-два — рабочий компромисс между этими крайностями для большинства сценариев. Конкретный интервал стоит корректировать по двум факторам:

• Сколько независимых копий у архива. Если это единственная копия — проверяйте чаще, ежегодно, и в целом задумайтесь о второй копии по правилу «3-2-1» (три копии, два разных носителя, одна вне основной площадки). Если копий несколько и они на разных носителях/у разных провайдеров — раз в два года достаточно, потому что вероятность одновременной необнаруженной порчи всех копий ниже.
• Насколько критично время на восстановление, если проблема обнаружится поздно. Для юридически значимых архивов с фиксированными сроками хранения задержка в обнаружении порчи может означать, что к моменту, когда архив реально понадобится по запросу, чинить будет уже некогда — здесь интервал стоит сокращать до ежегодного независимо от количества копий.

Важно: интервал в год-два — это частота полной или выборочной проверки данных, а не частота фонового мониторинга носителя (SMART-показатели диска стоит отслеживать постоянно, а не раз в год — деградация носителя иногда предсказуема заранее по конкретным атрибутам).

Выборочная проверка целостности через контрольные суммы

Первый и самый дешёвый уровень проверки — не трогая архив целиком, сверить контрольные суммы файлов с эталоном, сохранённым в момент создания архива. Это ловит и bit rot, и большинство случаев физической порчи блоков, но не требует полного восстановления.

Манифест контрольных сумм нужно создавать сразу при закладке архива в холодное хранилище, и хранить его отдельно от самого архива — не только рядом с файлами, но и копией где-то ещё (в системе учёта, в репозитории, в отдельном маленьком файле, который легко скопировать в письмо себе). Если манифест лежит только внутри того же архива, который вы проверяете, а архив повредился структурно — сверять будет не с чем.

# создать манифест при закладке архива в холодное хранилище
find /archive/project-2023 -type f -exec sha256sum {} \; > project-2023.sha256

# манифест — это просто список "хеш  путь", копию храним отдельно от архива
cp project-2023.sha256 /mnt/manifests/project-2023.sha256

Используйте SHA-256, а не MD5 — контрольная сумма может формально совпасть, а файл при этом оказаться повреждён, и MD5 для этого нужен реже, чем принято думать: подробный разбор конкретного случая, когда контрольная сумма сошлась, а файл оказался битым, — хороший повод убедиться, что вы используете достаточно надёжный алгоритм хеширования именно там, где это критично.

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

# выбрать случайные ~5% файлов из манифеста
total=$(wc -l < project-2023.sha256)
sample_size=$(( total / 20 ))
shuf -n "$sample_size" project-2023.sha256 > sample.sha256

# пересчитать контрольные суммы только для выбранной подвыборки
# (пути читаем из sample.sha256 второй колонкой)
cut -d' ' -f3- sample.sha256 | sha256sum -c --quiet -

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

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

Тестовое восстановление небольшой репрезентативной части

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

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

# посмотреть структуру архива без полной распаковки — быстрая проверка,
# что оглавление читается и файлы на месте
tar --list --file=project-2023.tar.zst | head -50

# распаковать только один каталог из архива для тестового восстановления
tar --extract --file=project-2023.tar.zst \
  --wildcards 'project-2023/q1-2023/*' -C /tmp/restore-test/

# если архив зашифрован — расшифровать именно этот кусок и убедиться,
# что ключ и пароль реально работают, а не просто "должны быть где-то"
gpg --decrypt project-2023.tar.zst.gpg > /tmp/restore-test/project-2023.tar.zst

Для архива базы данных тестовое восстановление выглядит иначе, но принцип тот же — не просто pg_restore без ошибок, а реальная проверка, что данные внутри осмысленные:

# поднять тестовую базу и восстановить в неё дамп из архива
createdb -h localhost restore_test_2023
pg_restore -h localhost -d restore_test_2023 /tmp/restore-test/dump-2023.sql

# проверить не факт восстановления, а содержимое —
# количество строк в ключевых таблицах должно быть разумным
psql -h localhost -d restore_test_2023 -c "SELECT count(*) FROM invoices;"

Если архив в архивном классе облачного хранилища, тестовое восстановление не обязано означать скачивание всего объёма — retrieval можно инициировать только для выбранных объектов, ограничив и время ожидания, и стоимость операции конкретной проверяемой частью, а не всем архивом целиком.

Зафиксируйте, сколько времени занял весь процесс — от запроса на восстановление до момента, когда данные реально доступны и проверены. Эта цифра — единственный честный ответ на вопрос «а сколько мы будем ждать, если это понадобится по-настоящему», и обычно она сильно отличается от интуитивной оценки, особенно если в цепочке есть retrieval из архивного облачного тарифа с задержкой в часы.

Регламент: как не забыть и что документировать

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

Практический минимум:

• Явная запись в календаре или планировщике задач, а не «кто-нибудь вспомнит» — с конкретной датой следующей проверки, а не расплывчатым «примерно через год».
• Назначенный ответственный, а не «команда в целом» — задачи без персональной ответственности систематически откладываются на потом.
• Лог каждой проверки: дата, что именно проверяли (полный архив или выборка, какой процент), результат, сколько заняло время, кто выполнял. Этот лог стоит хранить отдельно от самого архива — если с архивом что-то случится, история проверок должна остаться доступной.
• Явный критерий «тревога»: например, если в выборке испортилось больше 1% файлов — это повод проверить архив полностью и переходить к восстановлению со второй копии, а не откладывать до следующего планового цикла.

Если проверка нашла проблему — не ждите следующего планового окна. Немедленно проверяйте резервную копию (по правилу 3-2-1 она должна быть), пересчитывайте манифест для той части архива, что осталась рабочей, и, если возможно, восстанавливайте повреждённые файлы из второй копии, обновляя оригинальный архив, а не оставляя его в известно плохом состоянии до следующей проверки через год.

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