Архив без описания — набор байтов: что хранить рядом с данными

MAATRIX

Через три-пять лет любой архив без пояснительной записки превращается в файл backup_final_v2.tar.gz весом 40 гигабайт, про который никто в компании не может сказать точно: что внутри, зачем это хранили и можно ли это удалить. Формально данные целы — контрольная сумма сходится, файл распаковывается. Но без контекста это просто набор байтов, а не информация. Ниже — практический минимум того, что стоит записывать рядом с каждым важным архивом, и в каком виде это хранить, чтобы через годы у него был шанс снова стать полезным.

Что происходит с архивом без описания через три года

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

Типичная находка при аудите старого сервера выглядит так: каталог /archive/2021/, в нём полтора десятка .tar.gz и .sql.gz файлов с именами вроде export_final.tar.gz, db_dump_new.sql.gz, backup2_do_ne_udalyat.zip. Дат в именах нет или они не совпадают с реальным содержимым — кто-то переименовал файл при копировании. Спросить не у кого: человек, который это делал, уволился, а переписка велась в мессенджере, доступ к которому давно потерян вместе с его рабочим аккаунтом.

Дальше решение принимается вслепую в одну из двух сторон, и обе плохие:

• Оставить всё как есть — архив продолжает занимать место и требовать ресурсов на хранение без понимания, зачем он вообще нужен. Мы разбирали, во что это выливается в цифрах, в статье про стоимость хранения терабайта на пять лет — расходы на «архив на всякий случай» накапливаются годами и никто их не пересматривает.
• Удалить не глядя — а через полгода выясняется, что там были единственные исходные данные для отчёта, который требует налоговая, или единственная копия договоров с клиентом, который подал в суд.

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

Минимальный набор метаданных, который стоит хранить всегда

Не нужно городить полноценную систему управления архивами с базой данных и веб-интерфейсом — на практике для 95% случаев достаточно шести полей, записанных простым текстом. Вот они, с пояснением, почему каждое важно именно в горизонте нескольких лет, а не при создании архива.

1. Что это за данные и откуда они. Не просто «дамп базы», а какая база, какой системы, какого проекта или подразделения. «Экспорт заказов из интернет-магазина shop.example.ru, таблицы orders, order_items, customers, выгружено перед переездом на новую CMS» — это описание, по которому через пять лет можно понять содержимое без распаковки. «db_backup.sql» — нет.

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

3. Формат и версия ПО, которым данные были созданы. Это поле спасает больше всего времени при восстановлении. «PostgreSQL dump в формате custom (pg_dump -Fc), сервер версии 14.9» — вы точно знаете, каким pg_restore это разворачивать и на какой версии СУБД. «Экспорт из 1С:Бухгалтерия 8.3, релиз платформы 8.3.23, файловая база» — понятно, что нужна именно эта или более новая версия платформы. Для фото и видео сюда же идёт кодек, контейнер, цветовой профиль — через несколько лет ПО для чтения формата может исчезнуть с рынка.

4. Кто ответственный или кто знает контекст. Не «Иван», а имя, роль на момент создания архива и хотя бы один способ связи, который переживёт увольнение — рабочая почта не переживёт, а личная или упоминание отдела, где искать преемника контекста, — переживёт. Если человек уже недоступен, честно напишите это в описании: «создавал Иван Петров, менеджер проекта, уволился в 2023, актуальный контакт по этому проекту — руководитель отдела продаж».

5. Зависимости от других архивов или систем. Дамп базы без файлов вложений бесполезен, если приложение хранит файлы отдельно от БД. Зашифрованный архив без указания, где лежит ключ, — это не архив, а криптографический мусор. Экспорт из 1С без файла конфигурации может не встать в чистую базу. Явно перечисляйте: «требует также attachments_2021.tar.gz из того же каталога» или «ключ шифрования — в KeePass-базе отдела ИБ, запись CRM-archive-2021».

6. Срок хранения и чувствительность данных. Не строго обязательное, но крайне полезное поле: сколько это нужно хранить (по регламенту, по закону, по здравому смыслу) и есть ли внутри персональные данные, которые накладывают отдельные требования. Без этого поля решение «можно ли удалить» снова принимается вслепую — мы подробно разбирали правильный процесс закрытия проекта в статье сколько стоит закрыть проект правильно: архив и экспорт.

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

Практический формат: текстовый файл, а не переписка и не память

Есть три места, где обычно живёт описание архива, и все три ненадёжны в горизонте нескольких лет:

• В голове человека, который его создавал. Люди увольняются, забывают детали, путают проекты между собой — самый ненадёжный носитель информации из всех возможных.
• В переписке (почта, мессенджер, тикет-трекер). Формально информация где-то есть, но найти её через три года почти нереально: почтовый ящик уволенного сотрудника закрыт, чат в Telegram удалён, тикет в трекере, который сменили на другой сервис два раза с тех пор.
• В названии файла. db_backup_final_v3_ACTUAL.sql.gz — это отчаянная попытка втиснуть метаданные в 255 символов имени файла, и она никогда не работает достаточно хорошо.

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

Практическая схема именования:

/archive/2026/
├── crm_export_2026-08-15.tar.gz
├── crm_export_2026-08-15.tar.gz.sha256
├── crm_export_2026-08-15.README.txt
├── mail_backup_2026-08-01.tar.gz
├── mail_backup_2026-08-01.README.txt

Файл .README.txt (или MANIFEST.txt, INFO.txt — название не так важно, важна договорённость внутри команды) лежит рядом с архивом, копируется вместе с ним при переносе между дисками или в холодное хранилище и остаётся человекочитаемым без специального софта — открыть .txt можно на любой машине через двадцать лет. Ту же логику для проверки целостности байтов (не путать с описанием контекста — это разные задачи) мы разбирали в статье про манифест целостности и хеши, посчитанные один раз и забытые: хеш подтверждает, что файл не повреждён, а README рядом с ним объясняет, что это вообще такое и что с ним делать. Оба файла нужны одновременно и решают разные проблемы.

Шаблон MANIFEST.txt: разбор по полям

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

# ARCHIVE MANIFEST

archive_name: crm_export_2026-08-15.tar.gz
created: 2026-08-15
created_by: Анна Смирнова, руководитель отдела продаж
contact_fallback: отдел продаж, спросить текущего РОПа

source: PostgreSQL, продуктивная БД CRM компании,
  инстанс crm-db-01, база "crm_prod"
reason: плановый архив перед миграцией CRM на новую платформу

format: pg_dump, custom format (-Fc), сжатие включено
software_version: PostgreSQL 14.9, pg_dump той же версии
encoding: UTF-8

contents:
  - crm_export_2026-08-15.tar.gz — дамп БД, таблицы orders,
    customers, deals, activities
  - crm_export_2026-08-15_files.tar.gz — вложения к сделкам
    (лежит в этом же каталоге, без него дамп неполный)

dependencies:
  - для восстановления нужен PostgreSQL >= 14
  - схема расширений: pg_trgm, uuid-ossp (см. extensions.sql
    внутри архива)
  - вложения из files.tar.gz нужно вернуть в /var/crm/uploads/

restore_notes: |
  pg_restore -d crm_prod_restored -Fc crm_export_2026-08-15.tar.gz
  Проверено на тестовом сервере 2026-08-15, восстановление
  заняло около 40 минут на 12 ГБ данных.

checksum: sha256, см. crm_export_2026-08-15.tar.gz.sha256
sensitivity: содержит персональные данные клиентов (ФИО,
  телефон, email) — хранить с ограничением доступа
retention: хранить минимум 3 года по внутреннему регламенту,
  пересмотреть в августе 2029
related_archives: crm_export_2026-08-15_files.tar.gz (тот же каталог)

Не каждый архив требует все поля целиком — для видеозаписи с камеры достаточно источника, даты, кодека и ответственного. Но структура одинаковая: контекст, происхождение, формат, зависимости, ответственный, срок хранения. Держите шаблон в одном месте (например, в корне архивного каталога как TEMPLATE.README.txt), чтобы формат был единым для всех архивов в компании.

Как встроить это в процесс, чтобы не забывать

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

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

#!/usr/bin/env bash
set -euo pipefail

ARCHIVE_NAME="crm_export_$(date +%F).tar.gz"
ARCHIVE_DIR="/archive/2026"

pg_dump -Fc crm_prod > "${ARCHIVE_DIR}/${ARCHIVE_NAME}"
sha256sum "${ARCHIVE_DIR}/${ARCHIVE_NAME}" > "${ARCHIVE_DIR}/${ARCHIVE_NAME}.sha256"

# без README скрипт не считается завершённым
if [[ ! -f "${ARCHIVE_DIR}/${ARCHIVE_NAME%.tar.gz}.README.txt" ]]; then
  cp "${ARCHIVE_DIR}/TEMPLATE.README.txt" \
     "${ARCHIVE_DIR}/${ARCHIVE_NAME%.tar.gz}.README.txt"
  echo "ВНИМАНИЕ: заполните ${ARCHIVE_NAME%.tar.gz}.README.txt вручную"
  exit 1
fi

Скрипт копирует шаблон и намеренно завершается с ошибкой, если README не заполнен — грубовато, но работает лучше, чем надежда на то, что кто-то вспомнит сделать это потом.

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

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

Раз в год делайте ревизию архивного каталога. Не обязательно глубокую — достаточно пробежаться по README и убедиться, что поля retention не просрочены, а contact_fallback ведёт на живого человека.

Частые ошибки и что с ними делать

Описание пишут после архивации, а не до или во время. Через час контекст уже начинает стираться. Пишите README сразу после того, как архив создан, максимум в тот же день.

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

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

Зависимости не документируются, потому что "и так очевидно". В момент создания архива это действительно очевидно. Через три года — не очевидно совершенно никому.

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

Единственная копия README живёт на том же диске, что и единственная копия архива. Если диск умрёт, вы потеряете и данные, и их описание одновременно. README должен реплицироваться туда же, куда реплицируется сам архив.

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