Сколько стоит закрыть проект правильно: архив, экспорт, удаление

MAATRIX

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

Почему «выключить сервер» — это не закрытие, а риск

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

Три сценария, которые случаются на практике:

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

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

Архив: что и зачем сохранять

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

Обычно в архив стоит класть:

• Код и историю разработки. Git-репозиторий целиком, включая ветки и теги, а не только последний коммит в main.
• Дамп базы данных со схемой. Не выгрузку в CSV «на всякий случай», а полноценный dump, который можно восстановить и получить рабочую копию.
• Конфигурацию инфраструктуры. Файлы docker-compose, nginx-конфиги, cron-задания, переменные окружения (без секретов в открытом виде — об этом ниже) — всё, что нужно, чтобы через два года понять, как это вообще работало.
• Документацию и решения. Короткий README «как это было устроено» экономит часы тому, кто (в том числе вы сами) будет разбираться в архиве через год.
• Бухгалтерские и юридически значимые документы. Счета, договоры, акты — их часто нужно хранить дольше, чем кажется естественным, и это не зависит от того, жив проект или нет.

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

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

Как архивировать технически: от дампа до холодного диска

Технически архивирование проекта — рутинная задача, но с парой нюансов, которые легко упустить в спешке закрытия.

Дамп базы с сжатием и проверкой целостности:

# PostgreSQL — полный дамп со схемой и данными
pg_dump -Fc -f project_final_dump.sql dbname

# MySQL/MariaDB — аналогично, с грепом на ошибки в конце
mysqldump --single-transaction --routines --triggers dbname | gzip > project_final_dump.sql.gz

# Контрольная сумма — чтобы через год знать, что архив не побился
sha256sum project_final_dump.sql.gz > project_final_dump.sql.gz.sha256

Код и репозиторий — зеркалом, а не архивом одной ветки:

git clone --mirror git@host:org/project.git project.git
tar -czf project-code-archive.tar.gz project.git

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

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

# age — простой и современный вариант шифрования файла
age -r age1yourpublickeyhere... -o project-archive.tar.gz.age project-archive.tar.gz

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

И последнее — зафиксируйте дату, до которой архив точно нужен, и дату, после которой его можно пересмотреть. «Храним вечно» на практике означает «никто никогда не проверит, нужно ли это ещё» — а это снова риск, а не экономия.

Экспорт: обязательство перед пользователями, о котором забывают

Если у проекта были живые пользователи — хоть десять, хоть десять тысяч, — при закрытии на вас, как правило, лежит обязанность дать им забрать свои данные до отключения. Это не только вопрос юридики (право на переносимость данных прямо закреплено в GDPR и всё чаще встречается в похожем виде в других юрисдикциях — если у вас были пользователи из ЕС, стоит свериться с общими принципами в статье про GDPR для бизнеса с клиентами из Европы), но и вопрос репутации: люди помнят, кто дал им спокойно скачать историю заказов, а кто просто исчез вместе с их перепиской.

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

Здесь легко перегнуть в обе стороны. Строить полноценный self-service личный кабинет с кнопкой «экспорт» ради проекта, который и так закрывается, — избыточно. А молча выключить сервер, не предупредив никого, — недостаточно даже для маленького проекта с горсткой пользователей. Золотая середина — заранее сообщить о закрытии и дать конкретное окно, в течение которого экспорт доступен, а не «когда-нибудь потом, если попросите».

Как организовать окно экспорта технически

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

Минимальный вариант: разовый скрипт, который для каждого пользователя формирует архив с его данными и кладёт по ссылке, доступной только после аутентификации:

# псевдокод разового экспорт-скрипта
for user in users:
    data = {
        "profile": user.profile_dict(),
        "orders": [o.to_dict() for o in user.orders],
        "content": [c.to_dict() for c in user.content_items],
    }
    write_json(f"exports/{user.id}.json", data)
    zip_with_files(f"exports/{user.id}.zip", data, user.uploaded_files)

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

• Не публикуйте ссылки без авторизации. Прямая ссылка вида /export/12345.zip без токена — это утечка чужих данных по предсказуемому URL.
• Логируйте факт скачивания, а не содержимое — этого достаточно, чтобы через месяц понимать, кто уже забрал данные, а с кем стоит связаться отдельно.
• Не держите сервер живым дольше, чем нужно ради этого окна. Продлить аренду ещё на один оплачиваемый период ради спокойного окна экспорта почти всегда дешевле, чем разбираться с последствиями поспешного отключения — этот расчёт стоит держать в голове при планировании бюджета закрытия.

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

Удаление: безопасно стереть то, что хранить нельзя

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

Что обычно нужно сделать на этом шаге:

• Отозвать и удалить секреты. API-ключи, токены сторонних сервисов, вебхуки, доступы в панелях управления — если их не отозвать явно, они продолжают действовать даже после того, как код перестал существовать.
• Отменить сторонние подписки и интеграции. Платёжные системы, email-рассылки, аналитика, мониторинг — иначе счета продолжают приходить за сервис, которым никто не пользуется.
• Убрать DNS-записи и снять привязки домена, если домен больше не нужен для проекта.
• Стереть данные с диска, а не просто удалить файлы. Обычное удаление файла снимает ссылку на данные, но не обязательно перезаписывает содержимое — что конкретно происходит на уровне inode и почему на SSD ситуация сложнее из-за TRIM, разобрано в статье что происходит с данными при удалении файла. Если диск был зашифрован с самого начала, задача упрощается: достаточно уничтожить ключ, и данные становятся недоступны без полного стирания диска — разница между шифрованием диска и шифрованием бэкапа показана в статье про шифрование диска и бэкапа.
• Не оставлять «спящий» сервер из лени. Самая частая ошибка — оставить виртуалку выключенной, но не удалённой, «а вдруг понадобится», и забыть про неё на полгода. Выключенный сервер с чужими персональными данными, который никто не проверяет и не патчит, — это не архив, это забытая дверь.

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

Смета закрытия: время, ресурсы, чек-лист

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

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

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