Замороженный проект: минимальный ценник, чтобы не потерять данные

MAATRIX

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

Когда "заморозить" — правильный выбор, а не отговорка

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

Заморозка оправдана, когда выполняется хотя бы одно из условий:

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

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

Что дороже на самом деле: работающий сервер vs архив

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

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

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

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

Как перевести проект из рабочего режима в архив: пошагово

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

1. Снять полный снимок состояния. Не просто файлы — весь стек: код, базу, конфиги, секреты (в зашифрованном виде), список установленных пакетов и версий.

# База данных
pg_dump -Fc -f project_db_$(date +%F).dump mydb
mysqldump --single-transaction --routines --triggers mydb > project_db_$(date +%F).sql

# Файлы приложения и конфиги
tar -czf project_files_$(date +%F).tar.gz /var/www/project /etc/nginx/sites-available/project.conf

# Docker-проект — сохраняем и volumes, и сам compose-файл
docker compose config > project_compose_$(date +%F).yml
docker run --rm -v project_data:/data -v $(pwd):/backup alpine \
  tar -czf /backup/project_volume_$(date +%F).tar.gz -C /data .

2. Зафиксировать версии окружения отдельным файлом — через год вы не вспомните, на какой версии Node или PostgreSQL всё работало.

{
  echo "OS: $(cat /etc/os-release | grep PRETTY_NAME)"
  echo "Node: $(node -v 2>/dev/null)"
  echo "Python: $(python3 --version 2>/dev/null)"
  echo "PostgreSQL: $(psql --version 2>/dev/null)"
  docker images --format "{{.Repository}}:{{.Tag}}"
} > environment_snapshot_$(date +%F).txt

3. Проверить целостность архива до того, как выключите сервер — не после.

sha256sum project_files_*.tar.gz project_db_*.dump > checksums.sha256
tar -tzf project_files_*.tar.gz > /dev/null && echo "архив читается корректно"

4. Загрузить архив в холодное хранилище и только после подтверждения успешной загрузки — гасить рабочий сервер.

# rclone к S3-совместимому хранилищу
rclone copy ./project_archive_$(date +%F)/ remote:archive-bucket/project-name/ \
  --progress --checksum

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

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

Что забрать в архив, а что можно не хранить

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

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

Куда и как хранить: варианты холодного хранения и их цена

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

• Объектное хранилище S3-совместимого типа (в холодном или инфочастом тарифе) — самый предсказуемый вариант: платите за объём в месяц плюс небольшую плату за операции чтения/записи, которых у замороженного проекта почти нет.
• Архивный уровень хранения (аналог "глубокого архива") — дешевле обычного объектного хранилища, но с задержкой при извлечении файлов (от нескольких часов до суток у некоторых провайдеров) и платой за досрочное удаление раньше минимального срока хранения. Подходит, если вы уверены, что не понадобится восстановление "прямо сейчас".
• Внешний диск/NAS у себя — вариант для небольших объёмов и тех, кто не хочет зависеть от третьей стороны, но тогда на вас переходит забота о физической сохранности и резервном копировании самого диска.
• Снапшот виртуальной машины провайдера, поставленной на паузу — самый простой в реализации, но обычно и самый дорогой: часть провайдеров продолжает частично тарифицировать выделенное под снапшот место так же, как обычный диск.

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

Отдельно стоит определиться с доменом. Если вы отказываетесь от рабочего сервера, но домен по-прежнему нужен, — не обязательно держать его "живым" на VPS: можно оставить простую статическую заглушку на минимальном хостинге или вообще временно снять A-запись, сохранив саму регистрацию домена. Это отдельная и обычно копеечная статья расходов, независимая от того, где лежит архив.

Чек-лист перед заморозкой: бэкап, доступность, план возврата

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

• Бэкап реально свежий, а не "вроде бы автоматический". Проверьте дату последнего успешного дампа базы, а не дату последнего запуска cron-задачи — задача могла запускаться и падать месяцами.
• Архив проверен на восстановимость, а не только на факт записи. Разверните дамп базы на тестовой машине и убедитесь, что приложение с ним стартует — это единственный надёжный способ узнать, что архив рабочий.
• Секреты и ключи вынесены отдельно от общего архива и зашифрованы — не стоит держать пароли от боевой базы простым текстом в том же tar.gz, что и остальные файлы, особенно если архив лежит у стороннего провайдера.
• Есть письменная (хотя бы в заметке) инструкция по восстановлению — команды разворачивания, версии окружения, порядок запуска сервисов. Пишется это за 20 минут сейчас, а не за два дня в панике через год.
• Домен и DNS-записи задокументированы отдельно — если домен продолжает жить своей жизнью, а сервер выключен, легко забыть, что и куда указывало.
• Назначен срок пересмотра — раз в 3-6 месяцев стоит вернуться и решить: реанимировать проект, продлить заморозку или наконец закрыть его окончательно. Без этого шага заморозка рискует стать бессрочной, а вместе с ней — бессрочной статьёй расходов на хранение того, что никому уже не нужно.

Если план — не просто хранить, а суметь быстро вернуться в строй, полезно заранее прикинуть, сколько времени займёт разворачивание из архива на новом сервере: это тот самый показатель RTO (recovery time objective), который часто важнее самой стоимости хранения. Логика его расчёта разобрана в статье про цену восстановления, а не хранения — идея переносится один в один: чем быстрее вам нужно вернуть проект в рабочее состояние, тем дороже обходится "простое" хранение, потому что приходится держать более быстрый, а значит и более дорогой уровень архива.

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

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