ИИ удалил базу данных: что делать в первые часы

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

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

Шаг 1. Остановите всё, что пишет на диск

Закройте сессию агента (Claude Code, Cursor, Replit Agent, Copilot Workspace — что используется). Остановите приложение, если оно крутится локально или в контейнере без постоянного тома: работающий процесс может продолжать писать в файл базы, перезаписывая освободившиеся страницы.

Не перезапускайте контейнер, не пересоздавайте инстанс, не делайте «redeploy». Управляемые платформы при пересоздании стирают эфемерную файловую систему — а именно там чаще всего и лежит вся база vibe-coded проекта.

Шаг 2. Сделайте снимок того, что осталось

До любых экспериментов снимите текущее состояние:

• скопируйте папку с данными целиком (включая файлы *.db-wal, *.db-shm, *.journal — в них часто лежит последняя порция записей, ещё не перенесённая в основной файл);
• скачайте логи приложения за последние сутки;
• сделайте снапшот диска или бэкап инстанса у хостера, если такая функция есть;
• сохраните вывод git status и git log, если репозиторий вообще есть.

Даже если база выглядит пустой — снимок нужен. По нему восстанавливается хронология и находятся фрагменты, которые не видны «на глаз».

Шаг 3. Поймите, что именно произошло

От характера разрушения зависит, что вообще возможно вернуть. Три типовых случая:

Таблицы удалены или пересозданы

Для Postgres/MySQL это значит: данные лежат в файлах табличного пространства, которое уже переиспользуется. Шансы есть, пока файлы не перезаписаны — но только при немедленной остановке записи и работе с копией. Для SQLite удаление таблиц часто оставляет данные в свободных страницах файла: восстановление возможно до того, как база выполнит VACUUM или начнёт переиспользовать освободившиеся страницы.

Файл базы перезаписан или удалён

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

База была в эфемерном хранилище

Самый жёсткий вариант: платформа (Replit, Vercel-подобные serverless-среды, контейнеры без volume) не хранит файлы между пересборками. Здесь восстанавливать нечего — только собирать данные извне и перестраивать хранение правильно.

Шаг 4. Соберите внешние источники данных

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

• письма и уведомления о заказах/регистрациях на почте и в CRM;
• выгрузки в Google Sheets, Notion, Excel — типичный «дашборд на скорую руку»;
• платёжный провайдер: история транзакций с идентификаторами и суммами;
• аналитика и логи веб-сервера: кто, когда, с какими данными обращался;
• экспорт из админки, сделанный когда-то раньше;
• кэш приложения, Redis, файлы сессий;
• локальные копии у разработчика и «та самая папка на ноутбуке».

Из этого набора обычно собирается 80–95% записей — с потерями по необязательным полям. Это несравнимо лучше, чем ноль.

Шаг 5. Проверьте, не утекли ли ключи

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

Шаг 6. Восстановите и закрепите результат

Работайте на копии в изолированной среде. Сначала поднимите схему, затем залейте данные, затем сравните контрольные суммы и количество записей по ключевым таблицам. Только после проверки переключайте продакшен.

Как только сервис поднялся, до конца дня закройте причину, иначе всё повторится:

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

Сколько это занимает

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

Отдельно про «я попросил ИИ, и он сказал, что данные можно восстановить из логов». Агент не проверяет, а предполагает: он не знает, что лежит в вашем хранилище. Верить стоит только результату восстановления на копии.

Читайте также: 5 признаков, что ваш vibe-coded проект не переживёт первого клиента