Архив мёртвого проекта: как хранить десять лет и не платить за живой VPS

MAATRIX

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

Живой сервер и архив — это две разные задачи

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

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

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

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

Почему это разные деньги, а не разница в удобстве

Экономика тут не тонкая — она на порядки, а не на проценты. Минимальный тариф VPS всё равно включает выделенные вычислительные ресурсы, публичный IP, сетевой канал и готовность отвечать на запросы в любую секунду — вы платите за постоянную инфраструктурную готовность, даже если 99,9% времени сервер простаивает и никто на него не заходит.

Холодное хранение того же объёма данных устроено принципиально иначе: диск или объектное хранилище архивного класса просто хранит байты, ничего не вычисляя и не слушая на сетевом порту. Себестоимость для провайдера ниже на порядок — не нужно резервировать CPU и RAM, не нужна постоянная сетевая доступность, не нужен SLA на время отклика. Разница в себестоимости транслируется в разницу в цене для вас: пустой VPS с файлами обходится кратно дороже, чем те же файлы на архивном хранилище, при абсолютно одинаковом фактическом использовании — никаком.

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

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

Шаг 1. Финальный снимок — не только база данных

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

В финальный снимок стоит включать не меньше, чем при плановой архивации живого проекта:

• Код целиком, а не последний коммит в main. Полный git-репозиторий со всеми ветками и тегами: git bundle create project.bundle --all или git clone --mirror. Если репозиторий лежит на самостоятельно хостящемся GitLab или Gitea — экспортируйте архив проекта через API отдельно, не полагайтесь на то, что сама платформа доживёт до момента, когда архив понадобится.
• Полный дамп базы данных, а не инкрементальный бэкап и не выгрузка «на всякий случай» в CSV. Для PostgreSQL: pg_dump -Fc dbname > dbname.dump, для MySQL/MariaDB: mysqldump --single-transaction --routines --triggers dbname | gzip > dbname.sql.gz. Логический дамп со схемой переживает смену версии СУБД надёжнее, чем снимок файлов на диске.
• Конфигурация и инфраструктура как код. docker-compose.yml, конфиги nginx или traefik, systemd unit-файлы, переменные окружения. Секреты (API-ключи, пароли, токены) стоит вынести в отдельный зашифрованный файл, а не хранить открытым текстом рядом с остальным архивом.
• Файлы приложения — всё, что загружали пользователи, сгенерированные отчёты, медиа. Часто это самая объёмная часть архива, и именно её проще всего забыть, сосредоточившись на базе.
• Docker-образы, если проект собирался кастомно: docker save myapp:latest | gzip > myapp-image.tar.gz. Через несколько лет собрать тот же образ заново из Dockerfile может не получиться — зависимости из пакетных репозиториев исчезают или несовместимо обновляются.
• Документация «как это работало». Короткий README с архитектурой — какие сервисы из чего состояли, как взаимодействовали, где были нестандартные решения. Это легко держится в голове, пока проект жив, и полностью теряется через год после закрытия.
• Внешние зависимости, которых физически нет на сервере — список доменов, вебхуков, интеграций с платёжными системами и внешними API. Без этого списка восстановление упирается в детали, которые никогда не лежали на диске.

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

Шаг 2. Формат, который откроется через десять лет

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

Ключевые практические моменты:

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

mkdir -p /archive-staging/project-name/{db,code,files,config,secrets}
pg_dump -Fc project_db > /archive-staging/project-name/db/project_db.dump
git bundle create /archive-staging/project-name/code/repo.bundle --all
tar czf /archive-staging/project-name/files/uploads.tar.gz /var/www/project/uploads
cp docker-compose.yml nginx.conf /archive-staging/project-name/config/
tar czf project-name-archive-$(date +%F).tar.gz -C /archive-staging project-name
sha256sum project-name-archive-*.tar.gz > project-name-archive.sha256

• Зашифруйте архив перед тем, как он уедет с боевого сервера, особенно если внутри персональные данные пользователей или платёжные реквизиты:

age -r age1yourpublickeyhere... -o project-archive.tar.gz.age project-archive.tar.gz

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

Шаг 3. Холодное хранилище вместо работающего сервера

После того как архив собран, упакован и зашифрован, у него нет причин оставаться на VPS ни одного лишнего дня. Практические варианты, куда его перенести:

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

Шаг 4. Манифест: без описания архив — просто набор байтов

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

Рядом с самим архивом должен лежать документ, который отвечает на вопросы, которые сами себе не зададите сейчас, но обязательно зададите через пять лет:

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

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

# Восстановление project-name из архива

1. Скачать архив: project-name-archive-2026-08-25.tar.gz из архивного хранилища
2. Проверить целостность: sha256sum -c project-name-archive.sha256
3. Расшифровать: age -d -i keyfile.txt -o archive.tar.gz project-archive.tar.gz.age
4. Распаковать: tar xzf archive.tar.gz
5. Поднять БД: pg_restore -d project_db_restored db/project_db.dump
6. Восстановить код: git clone code/repo.bundle project-name
7. Поднять сервисы: docker compose -f config/docker-compose.yml up -d

Такой документ окупает себя один раз — когда клиент неожиданно возвращается или юристам нужны данные по старому договору. Без манифеста та же задача превращается в археологию по обрывочным файлам.

Шаг 5. Редкая, но не нулевая проверка целостности

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

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

• Проверить контрольную сумму архива на соответствие той, что зафиксирована в манифесте.
• Хотя бы раз распаковать архив и убедиться, что дамп базы реально накатывается, а не просто присутствует в файловой системе.
• Убедиться, что провайдер холодного хранилища всё ещё существует на тех же условиях, а доступы к нему не протухли (пароль, ключ API, двухфакторная аутентификация на давно неиспользуемом аккаунте — частое узкое место).

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

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