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

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

Как это вообще происходит: ИИ и базы данных в 2026 году

Вайбкодинг — это реальность. Разработчики дают ИИ-агентам (Cursor, Claude Code, GitHub Copilot Workspace, Devin, Windsurf) доступ к терминалу, к файловой системе, к базам данных. Иногда агент выполняет что-то необратимое.

Типичные сценарии:

ИИ запустил DROP TABLE или DROP DATABASE при попытке «почистить» схему
Агент выполнил DELETE FROM users без WHERE условия — стёр все данные
Cursor запустил команду docker-compose down -v, удалив volumes с данными
ИИ запустил скрипт миграции, который затёр данные в продакшене вместо staging
Агент удалил файл .db или .sqlite, думая, что это временный файл
ИИ выполнил rm -rf в папке с данными при «очистке проекта»

В апреле 2026 года несколько публичных инцидентов (включая случай с платформой PocketOS) показали: ИИ-агенты с избыточными правами могут уничтожить данные быстрее, чем человек успевает среагировать.

Шаг 0: остановите запись прямо сейчас

Остановите приложение и все сервисы, использующие базу
Остановите Docker-контейнеры: docker-compose stop
Остановите PostgreSQL: sudo systemctl stop postgresql
Не устанавливайте никаких программ на тот же диск
Не скачивайте файлы на тот же диск
Отзовите токены и ключи доступа, которые использовал ИИ-агент

Уровень 1: проверьте самые очевидные места

Корзина Windows / Trash macOS

Прежде чем искать где-то ещё — проверьте корзину.

Windows: Откройте «Корзину» на рабочем столе. Найдите файл с расширением .db, .sqlite, .sql, .dump. Правый клик → «Восстановить».

macOS: Откройте «Корзину» в Dock. Найдите файл базы. Правый клик → «Вернуть на место».

Если ИИ удалял файлы через rm в терминале или через Python/Node.js скрипт — они не попадут в корзину. Переходите к следующему шагу.

Папка с бэкапами проекта

Проверьте папку backups/ в проекте. Проверьте, нет ли файлов .db.bak, .sql.old, backup_* в папке проекта и рядом.

find . -name "*.db" -o -name "*.sqlite" -o -name "*.dump" -o -name "*.sql" 2>/dev/null

История Git

Если файл базы данных был в репозитории (что редко, но бывает):

git log --all --full-history -- "*.db"
git log --all --full-history -- "*.sqlite"

# Восстановить файл из конкретного коммита
git checkout <commit_hash> -- path/to/database.db

Если ИИ делал коммиты до удаления — в истории может сохраниться последнее состояние схемы и данных.

Уровень 2: облачные синхронизации

iCloud Drive (macOS)

Перейдите на icloud.com и войдите
Откройте iCloud Drive
В левой панели найдите «Недавно удалённые» (Recently Deleted)
Файлы хранятся 30 дней после удаления
Найдите .db, .sqlite, .sql файлы
Правый клик → «Восстановить»

Также проверьте: нажмите на иконку профиля → «Восстановление данных» (Data Recovery). Там иногда есть расширенные опции восстановления.

Google Drive

Откройте drive.google.com
В левой панели нажмите «Корзина» (Trash)
Файлы хранятся 30 дней
Найдите ваш файл базы данных
Правый клик → «Восстановить»

Если файл был изменён (не удалён), а данные в нём испорчены — используйте историю версий. Правый клик на файл → «Управление версиями» → выберите версию до инцидента.

Яндекс.Диск

Перейдите на disk.yandex.ru
Нажмите «Корзина» в левом меню
Файлы хранятся 30 дней
Найдите и восстановите нужный файл

Dropbox

Откройте dropbox.com
Нажмите «Удалённые файлы» в боковом меню
Платные планы хранят историю 180 дней, бесплатный — 30 дней
Найдите файл и нажмите «Восстановить»

OneDrive (Microsoft)

Откройте onedrive.live.com
Нажмите «Корзина» в левом меню
Файлы хранятся 30 дней (93 дня при переполнении хранилища)
Восстановите файл

Уровень 3: системные бэкапы ОС

macOS Time Machine

Если у вас подключён внешний диск с Time Machine — это самый надёжный способ восстановления.

Откройте папку, где хранился файл базы данных
Нажмите на иконку Time Machine в строке меню → «Просмотр резервных копий Time Machine»
Используйте временную шкалу справа, чтобы перейти ко времени до инцидента
Найдите файл базы данных
Нажмите «Восстановить»

Time Machine сохраняет снапшоты каждый час последние 24 часа, ежедневно за последний месяц и еженедельно за последний год.

Windows File History (История файлов)

Если File History включена:

Откройте папку, где хранился файл
Нажмите «Главная» в проводнике → «История»
Прокрутите назад до нужного момента
Нажмите кнопку восстановления (зелёная стрелка)

Windows Shadow Copy (Теневые копии)

Windows иногда автоматически создаёт теневые копии файлов:

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

Проверить через командную строку (от администратора):

vssadmin list shadows /for=C:

Если теневые копии есть — можно смонтировать том:

mklink /d C:\ShadowCopy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\

Уровень 4: облачные провайдеры баз данных

Если база данных хоститься на облачном сервисе, а не локально — у вас гораздо больше шансов.

Supabase

Supabase делает автоматические бэкапы на платных планах. Перейдите в Dashboard → Settings → Database → Backups. Можно восстановить на точку во времени (Point-in-Time Recovery).

Railway

В случае инцидентов Railway может восстановить данные — обратитесь в поддержку немедленно через help.railway.app. Запрос нужно подать как можно быстрее.

PlanetScale

Поддерживает автоматические бэкапы и возможность восстановления через Dashboard → Backups.

AWS RDS / Aurora

Войдите в AWS Console → RDS
Выберите инстанс → Automated backups
Point-in-Time Recovery: можно восстановить базу на любую секунду за последние 35 дней
Кнопка «Restore to point in time»

Google Cloud SQL

Console → SQL → Instances → Ваш инстанс → Backups. Есть автоматические бэкапы и Point-in-Time Recovery.

Azure SQL Database

Portal → SQL databases → Ваша база → Restore. Поддерживается восстановление на точку во времени в пределах 35 дней.

Render.com

Managed databases на Render имеют автоматические снапшоты. Проверьте Dashboard → Your database → Backups.

Timeweb Cloud, Selectel, Яндекс.Облако (российские провайдеры)

У каждого провайдера есть собственный механизм снапшотов. Войдите в панель управления, найдите раздел «Резервные копии» или «Снапшоты» для вашей базы данных. Если в UI нет нужного бэкапа — создайте тикет в поддержку немедленно.

Уровень 5: восстановление данных PostgreSQL без бэкапа

Если нет никаких бэкапов, но PostgreSQL инстанс ещё жив (просто данные удалены командой DELETE или TRUNCATE, а не DROP):

pg_undrop / pgundo

Некоторые операции в PostgreSQL можно отменить, если база не перезаписана:

# Проверьте WAL-логи (Write-Ahead Log)
# WAL хранит все изменения до checkpoint
ls $PGDATA/pg_wal/

Инструмент pg_filedump позволяет читать страницы данных напрямую из файлов PostgreSQL — иногда удалённые строки ещё физически присутствуют до VACUUM.

Проверьте транзакционные логи

-- Если включён аудит-лог
SELECT * FROM pg_stat_activity;

-- Посмотрите последние команды (если включён log_statement)
-- В postgresql.conf: log_statement = 'all'

pg_waldump для анализа WAL

pg_waldump -p $PGDATA/pg_wal -n 100 > wal_dump.txt
grep -i "DELETE\|TRUNCATE\|DROP" wal_dump.txt

Уровень 6: восстановление удалённых файлов с диска

Если файл базы данных (.db, .sqlite) был физически удалён — попробуйте утилиты восстановления файлов.

Важно: устанавливайте утилиты НЕ на тот диск, где была база. Используйте другой диск или загрузочную флешку.

Photorec / TestDisk (бесплатно, Windows/macOS/Linux)

# Linux/macOS
sudo testdisk /dev/sda

# Windows — запустите testdisk_win.exe от администратора

TestDisk умеет находить удалённые файлы SQLite по сигнатуре (53 51 4C 69 74 65 — первые байты SQLite-файла).

Recuva (Windows, бесплатно)

Скачайте с piriform.com/recuva. Установите на другой диск или USB. Запустите сканирование, фильтруйте по расширению .db, .sqlite, .sql.

Disk Drill (Windows/macOS, платный)

Мощный инструмент с поддержкой SSD и APFS (macOS). Сайт: cleverfiles.com. Есть бесплатный режим для просмотра найденных файлов.

R-Studio (профессиональный)

Для критически важных данных — R-Studio один из лучших инструментов форенсики. Сайт: r-studio.com

Внимание по SSD: если диск — SSD с включённым TRIM, данные, скорее всего, безвозвратно уничтожены сразу после удаления. На HDD шансов больше.

Уровень 7: профессиональные сервисы восстановления данных

Если все предыдущие методы не помогли, а данные критически важны:

Kroll (OnTrack) — международная компания, восстанавливает данные с физически повреждённых носителей
ACE Lab (Россия) — российская компания, разрабатывает профессиональное оборудование для восстановления данных
Профессиональный сервис дороже, но иногда это единственный вариант при повреждении микросхем SSD

Как предотвратить повторение: защита от ИИ-агентов

1. Принцип минимальных прав для ИИ

Никогда не давайте ИИ-агенту токен с правами администратора базы данных. Создайте отдельного пользователя с ограниченными правами:

-- PostgreSQL: создаём пользователя только для чтения
CREATE USER ai_agent WITH PASSWORD 'secure_password';
GRANT SELECT ON ALL TABLES IN SCHEMA public TO ai_agent;
-- НЕ даём INSERT, UPDATE, DELETE, DROP

-- Для разработки: только нужные таблицы
GRANT SELECT, INSERT ON users TO ai_agent;

2. Подтверждение деструктивных операций

В .cursorrules или AGENTS.md добавьте явный запрет:

# AGENTS.md
## Правила работы с базой данных
- НИКОГДА не выполнять DROP TABLE, DROP DATABASE, DELETE без WHERE без явного подтверждения пользователя
- НИКОГДА не запускать команды с флагом --force или -v для docker-compose down
- Перед любой деструктивной операцией с БД — спросить подтверждение

3. Автоматический бэкап перед каждой операцией ИИ

Добавьте в workflow: перед тем как дать ИИ задачу, связанную с БД — сделайте бэкап.

Сервис dbsend.ru позволяет настроить автоматические бэкапы SQLite, PostgreSQL и NoSQL в облако одной строкой. Если бэкап уходит в облако автоматически каждые несколько часов — даже при инциденте с ИИ вы потеряете максимум несколько часов работы, а не всё.

4. Разделение окружений

Никогда не давайте ИИ-агенту доступ к продакшен-базе при работе с кодом. Только staging или dev-окружение.

# .env.development
DATABASE_URL=postgresql://localhost:5432/myapp_dev

# .env.production  
DATABASE_URL=postgresql://prod-server:5432/myapp_prod
# Продакшен-URL никогда не попадает в контекст ИИ

5. Мониторинг деструктивных операций

Включите аудит-логирование в PostgreSQL:

-- postgresql.conf
log_statement = 'ddl'  -- Логировать все DDL (CREATE, DROP, ALTER)
log_min_duration_statement = 0  -- Логировать все запросы

Чек-лист восстановления (для паники)

Распечатайте и повесьте на стену:

Стоп — прекратить запись на диск прямо сейчас
Корзина (Windows/macOS) — проверить
Папка backups/ в проекте — проверить
Git history — git log --all -- "*.db"
iCloud / Google Drive / Яндекс.Диск — корзина в облаке
macOS Time Machine — если подключён диск
Windows Previous Versions — правый клик на папке → Свойства
Windows Shadow Copy — vssadmin list shadows
Облачный провайдер БД (Supabase, Railway, RDS) — Dashboard → Backups
Утилиты восстановления файлов (TestDisk, Recuva) — с другого диска
Поддержка провайдера — тикет с пометкой «срочно»
Профессиональный сервис восстановления данных

FAQ

ИИ выполнил DELETE без WHERE — данные можно восстановить? Если PostgreSQL — есть шанс через WAL-логи, если VACUUM ещё не прошёл. Остановите базу немедленно и проверьте WAL. Если SQLite — без бэкапа почти невозможно, только специализированный forensic-анализ файла.

Cursor запустил docker-compose down -v — volumes удалены. Что делать? Если volumes были смонтированы как named volumes без bind mount на хост — данные, скорее всего, потеряны. Docker не отправляет данные volumes в корзину ОС. Единственный вариант — внешние бэкапы.

Есть ли у меня права на восстановление через облако, если я на бесплатном плане? Google Drive, iCloud, Яндекс.Диск и OneDrive имеют корзину на всех планах (30 дней). Для Point-in-Time Recovery у облачных БД (Supabase, Railway, RDS) обычно нужен платный план.

Как настроить автоматические бэкапы, чтобы больше не попасть в эту ситуацию? Самый простой путь — dbsend.ru: одна строка настройки, бэкап SQLite или PostgreSQL уходит в облако по расписанию. Для локальной разработки — см. нашу статью «Бэкапы при локальной разработке».

Файл был на SSD. Есть ли шанс? На SSD с TRIM (а это почти все современные SSD) шансы минимальны — данные физически стираются сразу после удаления. Единственный вариант — профессиональный сервис восстановления или холодный анализ чипов флеш-памяти. Это дорого и не гарантирует результат.

Как объяснить ИИ-агенту, что он не должен удалять данные? Используйте файл AGENTS.md или .cursorrules с явными запретами. Но помните: это инструкции для модели, не системные ограничения. Настоящая защита — права доступа на уровне базы данных и отдельный пользователь с ограниченными правами.