Что станет с вашим tar.gz за семь лет хранения

MAATRIX

Вы заархивировали проект командой tar czf archive-2019.tar.gz ./project семь лет назад и с тех пор ни разу к нему не притрагивались. Формат жив, gzip и tar никуда не делись, tar tzf на любом Linux 2026 года прочитает этот файл так же, как в день создания. Но если сегодня вам действительно понадобится то, что внутри, есть неплохой шанс, что вы либо не сможете его распаковать, либо не поймёте, что это, либо не найдёте вовсе. Разбираемся, откуда берутся эти риски и как их снять, пока архив ещё жив.

Формат не виноват — и в этом ловушка

tar.gz — это два слоя: tar (POSIX-стандарт объединения файлов в один поток, описан ещё в спецификации Unix V7) поверх gzip (открытый алгоритм сжатия по DEFLATE, RFC 1952). Оба открыты, документированы, реализованы в десятках независимых утилит на всех платформах. У формата нет владельца, который может его "закрыть", нет лицензии, которая истечёт, нет привязки к конкретной версии софта. Файл, упакованный tar в 1996 году, открывается современным tar без единой правки — это редкое для IT свойство, и именно оно создаёт ложное чувство безопасности.

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

Риск 1: физическая деградация носителя

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

Жёсткие диски. Магнитное покрытие теряет намагниченность со временем, а секторы могут "протухать" (bit rot) даже без механического сбоя — контроллер диска перестаёт их корректно читать. SMART-атрибуты вроде Reallocated_Sector_Ct и Current_Pending_Sector растут постепенно и незаметно, если никто не смотрит на них годами:

smartctl -a /dev/sda | grep -E "Reallocated|Pending|Uncorrectable"

SSD и флеш-накопители без питания. У SSD есть параметр retention — сколько времени контроллер гарантирует сохранность данных без подачи питания. По спецификации JEDEC JESD218 для потребительских SSD это ориентировочно около года при комнатной температуре (у энтерпрайз-дисков условия жёстче, у свежих ячеек с малым износом — лучше). Если архив лежит на SSD, который вы отключили и убрали в ящик стола на несколько лет, это реальный риск потери данных без единого сообщения об ошибке — диск просто не подаёт питания, ему нечем сообщить о деградации.

Лента (LTO) и оптика. Лента предсказуема при правильном хранении (контроль влажности и температуры, вертикальное положение), но требует периодической перемотки — статичное натяжение годами деформирует носитель. Записываемые DVD и Blu-ray подвержены деградации отражающего слоя за 5-10 лет, особенно у дешёвых болванок — эти цифры сильно зависят от конкретного производителя и условий хранения, воспринимайте их как ориентир, а не гарантию.

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

sha256sum archive-2019.tar.gz > archive-2019.tar.gz.sha256
# при следующей проверке:
sha256sum -c archive-2019.tar.gz.sha256

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

tar tzf archive-2019.tar.gz > /dev/null && echo "OK, архив читается"

Если диски объединены в RAID или ZFS/Btrfs, добавьте периодический scrub — он находит и, если есть избыточность, чинит битые блоки до того, как их накопится критично много.

Риск 2: потеря знания о том, что внутри архива

Это риск, о котором реже всего думают заранее, и он бьёт больнее всего на длинной дистанции. Файл archive-2019.tar.gz через семь лет ничего не говорит о содержимом, кроме года. Кто его создавал, что за проект, зачем его хранят, можно ли удалить, есть ли внутри персональные данные, подпадающие под требования о хранении или, наоборот, об удалении — всё это знание живёт в голове человека, который давно может не работать в компании.

Практическое решение — не полагаться на память, а класть манифест прямо рядом с архивом или внутрь него:

cat > archive-2019-manifest.txt <<'EOF'
Архив: archive-2019.tar.gz
Дата создания: 2019-03-14
Автор: И. Петров, backend-разработчик
Содержимое: полный дамп проекта "biller-legacy" на момент отключения
Причина хранения: требование бухгалтерии — хранить 7 лет по 402-ФЗ
Можно удалить после: 2027-03-14
Проверка целостности (sha256): a1b2c3...
EOF

Такой манифест — не бюрократия ради бюрократии, а страховка от ситуации "юрист спрашивает, что у нас лежит и почему, а ответить некому". Если архивов десятки и сотни, манифесты стоит собирать в один реестр — простую CSV- или JSON-таблицу на сервере рядом с самими архивами, с колонками: имя файла, дата, владелец, содержимое, срок хранения, дата последней проверки целостности. Реестр — не разовая задача, а процесс: без регламента, кто и когда его обновляет, он устаревает так же тихо, как и сам архив.

Риск 3: потеря пароля от зашифрованного архива

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

Типичные способы шифрования архива и что с ними не так на дистанции в годы:

# симметричное шифрование через gpg — пароль в одной голове
gpg --symmetric --cipher-algo AES256 archive-2019.tar.gz

# asymmetric через gpg-ключ — зависит от того, жив ли приватный ключ через 7 лет
gpg --encrypt --recipient admin@company.ru archive-2019.tar.gz

# через openssl — тот же риск с паролем, плюс исторически слабые дефолты в старых версиях
openssl enc -aes-256-cbc -pbkdf2 -in archive-2019.tar.gz -out archive-2019.tar.gz.enc

Проблема не в алгоритме (AES-256 за семь лет свою стойкость не потеряет), а в хранении секрета. Пароль в личной заметке на телефоне уволившегося сотрудника, GPG-ключ в keyring на его личном ноутбуке, мастер-пароль в голове одного человека — всё это разовые решения, которые не переживают смену команды.

Рабочий подход для организации, а не для одного человека:

• Хранить ключи и пароли шифрования в общем менеджере паролей команды (Vaultwarden, Bitwarden, 1Password для бизнеса), а не у одного человека.
• Для GPG — держать резервную копию приватного ключа и revocation-сертификата отдельно от рабочей машины, с понятной процедурой доступа для нескольких доверенных лиц.
• Раз в год-два проверять, что расшифровка реально работает: не просто "ключ есть в хранилище", а gpg --decrypt на тестовом архиве проходит от начала до конца.
• Записывать в манифест архива не пароль (это отдельный секрет), а способ шифрования и где искать ключ: "AES256 через gpg, ключ в Vaultwarden, папка Archive Keys".

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

Риск 4: миграция между серверами теряет часть архивов

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

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

# перенос с проверкой контрольных сумм, а не только размера и времени модификации
rsync -avz --checksum /path/to/archives/ user@new-server:/path/to/archives/

# после переноса — сверить, что ничего не потерялось и не побилось
find /path/to/archives/ -type f -name "*.sha256" -exec sh -c 'cd "$(dirname "{}")" && sha256sum -c "$(basename "{}")"' \; | grep -v OK

Вторая частая причина — избирательный перенос "на глаз". Кто-то переносит вручную папки, которые кажутся важными, и пропускает архив трёхлетней давности, потому что его не открывали и забыли, что он вообще есть (снова риск №2 — без реестра архивов такой перенос неизбежно теряет часть данных). Третья — смена структуры каталогов или кодировки имён файлов при переносе между Linux и Windows/NAS: кириллица в именах файлов внутри архива обычно переживает перенос самого tar.gz без проблем, а вот россыпь несжатых файлов рядом — не всегда.

Практика, которая закрывает этот риск системно: перед любой миграцией хранилища составлять полный список архивов с их хэшами (find /archives -name "*.tar.gz" -exec sha256sum {} \; > pre-migration-manifest.sha256), переносить, а затем прогонять sha256sum -c по этому же списку уже на новом месте. Расхождение — сигнал, что файл либо не доехал, либо повредился в пути, и это нужно увидеть сразу после переезда, а не через три года, когда архив понадобится.

Практический регламент на годы вперёд

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

Практический пример: если вы храните архивы на арендованном VPS или выделенном сервере, регламент проще автоматизировать через cron — скрипт раз в квартал прогоняет sha256sum -c по всем архивам, шлёт уведомление в Telegram или на почту при первом же несовпадении, а не ждёт, пока кто-то вручную вспомнит об этом. Отдельный сервер под холодное хранение (не тот же, что под боевую нагрузку) снижает риск, что архивы зацепит инцидент с продакшеном — переполнение диска, обновление, которое требует пересоздания тома, или миграция под нагрузкой. Про сам выбор носителя для холодного хранения — отдельный разговор: холодное хранение архивов разбирает варианты (объектное хранилище, свой HDD, офлайн-диск) с честными плюсами и минусами каждого.

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

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