ИИ удалил базу данных: что делать, playbook на 7 минут 2026

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

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

Что делать в первую минуту: STOP и не паникуй

Закрой терминал с агентом командой Ctrl+C. Ноутбук при этом не выключай и систему не перезагружай. Удалённые файлы и базы физически всё ещё лежат на диске - они просто помечены как «свободные блоки», и любая новая запись может перезаписать их насовсем.

Активные процессы тоже не трогай. Если процесс держал удалённый файл открытым, через lsof его потом можно вытащить. Закроешь процесс - потеряешь этот шанс. Первая минута решает примерно 70% успеха всего восстановления.

Показательный случай был весной 2026 года. Агент в редакторе кода за девять секунд удалил продакшен-базу стартапа вместе со всеми резервными копиями. Через минуту он сам написал в чате:

Я предположил, что удаление staging-тома через API будет ограничено только staging. Никогда не угадывай - и именно это я сделал.

- из переписки с агентом, апрель 2026, по материалам The Register

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

Вот что делаешь в первую минуту, по пунктам:

• Закрой терминал агента: Ctrl+C или закрой окно. Если агент прямо сейчас выполняет команду, дай ей завершиться, потом закрывай. Принудительный kill через SIGKILL оставит процессы-зомби.
• Не перезагружай ноутбук. Файлы, удалённые через rm или DROP DATABASE, физически ещё на диске, просто помечены свободными. Любая запись их перезапишет.
• Не закрывай открытые процессы. Если процесс держит удалённый файл, его можно вернуть через lsof (разберём ниже).
• Включи запись экрана. На macOS: Shift+Cmd+5, дальше Record Entire Screen. Скриншоты состояния понадобятся для тикета в облако и для разбора инцидента.

Дальше шесть минут на восстановление. Поехали.

Минуты 2-3: зафиксируй ошибку точно

До восстановления - диагностика. Без точного понимания, что именно удалено, кем, когда и какими командами, ты будешь восстанавливать вслепую и рискуешь убить те данные, которые ещё живы. Открой новое окно терминала (не то, где сидит агент) и выполни три команды по очереди.

Первое - зафиксируй, что изменилось в git-репозитории:

git status
git log --since="30 minutes ago" --all --oneline

Если git показывает удалённые файлы как deleted, они ещё в индексе и возвращаются одной командой git restore .. Если коммит уже сделан - тоже нормально, идём дальше.

Второе - проверь, какие процессы агента работают:

ps aux | grep -i claude
ps aux | grep -i cursor

Видишь активные процессы - убей их через kill -TERM PID. Именно -TERM, а не -9, чтобы агент успел корректно закрыть файловые дескрипторы. С -9 можно потерять как раз тот открытый удалённый файл.

Третье - сохрани лог сессии агента. Claude Code хранит JSONL-сессии в ~/.claude/projects/, Cursor - в ~/.cursor/. Сделай копию прямо сейчас:

cp -r ~/.claude/projects ~/claude-projects-backup-$(date +%Y%m%d-%H%M%S)

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

Минута 4: git reflog - твой главный шанс

Большинство случаев «ИИ удалил мой код» закрываются двумя командами: git reflog плюс git reset --hard HEAD@{N}. Git хранит все ссылки на коммиты 90 дней по умолчанию, даже после reset --hard или принудительной перезаписи ветки. Это первый шанс восстановления, и он срабатывает почти всегда.

git reflog - журнал всех движений HEAD, веток и stash за последние 90 дней. Каждый коммит, который когда-либо существовал в твоём локальном репозитории, лежит там, даже если он уже не виден через обычный git log.

Шаг 1. Посмотри журнал:

git reflog --all

Получишь список вроде такого:

1a2b3c4 HEAD@{0}: reset: moving to HEAD~3
9z8y7x6 HEAD@{1}: commit: рабочая версия дашборда
5w4v3u2 HEAD@{2}: commit: добавил админку

Ищи момент до того, как агент сломал. Каждая запись - это «фотография» состояния репозитория в тот момент.

Шаг 2. Восстанови состояние:

git reset --hard HEAD@{N}

Где N - номер записи в reflog, на которую откатываешься. Например, git reset --hard HEAD@{2} вернёт репозиторий в состояние сразу после коммита с админкой.

Если reflog тоже почищен (агент успел выполнить git gc):

git fsck --lost-found

Эта команда найдёт «потерянные» коммиты и блобы (объекты файлов), которые уже не привязаны ни к одной ветке. Они окажутся в .git/lost-found/commit/ и .git/lost-found/other/. Вытащить файл оттуда:

git cat-file -p <SHA1-блоба> > recovered-file.ext

Когда git reflog не помогает, случаев ровно три:

• Файл был только в рабочей папке, без коммита и без stash. Reflog его не видит.
• Прошло больше 90 дней (стандартный gc.reflogExpire) и был запущен git gc.
• Удалён весь репозиторий целиком (rm -rf .git). Тогда нужен Time Machine или снапшот диска.

Про штатный откат агента без git, через /rewind и другие способы, отдельно разобрано в гайде как откатить изменения в Claude Code. Он спасает, когда правки ещё не ушли в репозиторий.

Минута 5: восстановление базы данных из бэкапа

PostgreSQL Point-In-Time Recovery (PITR) откатывает базу на любую секунду в окне 7-35 дней. Работает в Yandex Cloud Managed PostgreSQL, AWS RDS, Supabase Pro и через локальный pg_dump по cron в Coolify. Главное условие: PITR должен быть включён до инцидента. Задним числом ничего не включишь.

База удалена через DROP DATABASE, DROP TABLE или DELETE FROM ... без WHERE. Разберём по шагам.

Шаг 1. Узнай, есть ли PITR у твоего провайдера.

Шаг 2. Восстанавливай в новый инстанс, не в старый. Никогда не разворачивай бэкап поверх живой базы. Создавай новый инстанс из бэкапа, потом переключай приложение на него. Если что-то пойдёт не так, откатишь DNS обратно, и старая база останется цела.

Шаг 3. Если PITR не был включён, используй последний снапшот:

# AWS RDS, список снапшотов:
aws rds describe-db-snapshots --db-instance-identifier my-db

# Восстановление из снапшота:
aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier my-db-restored \
  --db-snapshot-identifier rds:my-db-2026-05-28-12-00

Отдельный нюанс по Supabase, на котором в 2026 году горели многие. При включении PITR дневные бэкапы у него перестают создаваться. Поведение неочевидное, и можно остаться вообще без точки отката. Проверь в Dashboard → Database → Backups, что PITR активен и что при этом есть снапшот, к которому можно вернуться.

Минута 6: Time Machine, lsof и снапшот диска

Если файлы удалены прямо с диска, не из git и не из базы, есть три рабочих способа их вернуть.

На macOS - Time Machine с шагом в один час, при условии, что ноутбук был подключён к Time Capsule или внешнему диску:

# Список снапшотов:
tmutil listbackups

# Восстановить файл из последнего бэкапа:
tmutil restore /Volumes/Backup/.../my-project/file.tsx ~/projects/my-project/file.tsx

Time Machine делает снапшоты каждый час, хранит сутки почасовых копий, неделю - суточных, недельные держит бессрочно. Если ноутбук подключён к бэкап-диску, твой проект там есть с шагом в час.

На Linux, когда файл удалён, но процесс ещё держит его открытым:

# Найди все «удалённые» файлы, которые процесс держит:
sudo lsof | grep deleted

# Получишь строки вроде:
# node 12345 user 24w REG 8,1 4096 1234567 /path/to/deleted/file.txt (deleted)

# Скопируй файл прямо из /proc/PID/fd/N:
sudo cp /proc/12345/fd/24 ~/recovered-file.txt

Шанс успеха тут примерно 95%, если процесс не закрыли. Работает на ext4, xfs, btrfs.

На macOS аналог через lsof тоже есть, но копировать сложнее, потому что нет /proc/:

lsof | grep deleted

Достать содержимое можно через отладчик lldb, подключившись к процессу по его PID и вычитав нужный участок памяти в файл. Способ тонкий, но иногда это единственный путь.

Снапшот всего раздела - последний шанс на Linux:

sudo dd if=/dev/sda1 of=/external/disk-image.img bs=4M status=progress

Команда сохраняет весь раздел в образ, дальше восстанавливаешь через extundelete или photorec. Шанс зависит от того, сколько на диск записано с момента удаления. Если почти ничего - 80-90%. Если система уже поработала час - 20-30%. Поэтому первое правило и было: не перезагружать и не писать на диск.

Минута 7: что если бэкапа нет

Бэкапа нет, git reflog пуст, диск уже перезаписан. Остаётся три варианта последнего шанса.

Первый - техподдержка провайдера. Крупные облака периодически поднимают данные из своего внутреннего хранилища даже после катастрофы на стороне клиента, особенно на платных тарифах. Пиши через тикет, укажи точное время инцидента, приложи скриншоты состояния. Ниже в разделе про реальные случаи есть история, где облако вернуло 2.5 года данных. Шанс тут примерно 40-60%, окно реакции 24-72 часа.

Второй - S3-версионирование. Если файлы лежали в S3 или Yandex Object Storage и версионирование было включено, все версии физически на месте, просто помечены как «удалённые»:

# AWS - список версий объекта:
aws s3api list-object-versions --bucket my-bucket --prefix files/

# Восстановить конкретную версию:
aws s3api copy-object \
  --bucket my-bucket \
  --copy-source my-bucket/files/data.json?versionId=ABC123 \
  --key files/data.json

Третий - реконструкция из JSONL-сессий Claude Code. В 2026 году был публичный случай: у человека агент удалил недельную работу, reflog пуст, бэкапа нет. Помогла утилита claude-file-recovery:

pip install claude-file-recovery
claude-file-recovery

Скрипт парсит JSONL-сессии Claude Code из ~/.claude/projects/ и восстанавливает файлы из контекста, который агент видел во время работы. На разобранном примере вернулось около 84% файлов.

Важный нюанс: Claude Code не хранит сессии вечно, старые JSONL-файлы по сообщениям из сообщества удаляются автоматически через несколько недель. Чтобы в случае катастрофы у тебя был запас истории, копируй папку раз в неделю простым cron:

# В crontab каждое воскресенье в 03:00:
0 3 * * 0 rsync -av ~/.claude/projects/ /external/claude-history-backup/

Стоит ноль рублей, а спасает ровно в ситуации «всё пропало, бэкапа нет, reflog пуст».

Реальные случаи 2026 года: три катастрофы и три вывода

Три задокументированных истории, у каждой свой урок.

Первый случай, весна 2026. Агент в редакторе кода получил задачу прибрать staging-окружение и одним вызовом API удалил продакшен-volume вместе с volume-level бэкапами. База ушла за девять секунд, копии - вместе с ней, потому что лежали в том же volume.

ИИ-агент удалил нашу продакшен-базу и все volume-level бэкапы одним вызовом API.

- основатель пострадавшего стартапа, апрель 2026, по материалам Tom's Hardware

Вывод: бэкап должен лежать в другом месте, чем то, что он защищает. Отдельный bucket с отдельными правами, а не копия рядом с базой.

Второй случай, начало 2026. Агент стёр продакшен-инфраструктуру образовательной data-платформы с данными за 2.5 года. Ситуацию спасло обращение в техподдержку облака, там подняли всё из внутреннего хранилища. Основатель публично разобрал инцидент и подчеркнул главное: восстановление через техподдержку - это удача, а не процесс, полагаться на него нельзя.

Вывод: не «положись на провайдера в случае катастрофы», а «планируй, что он не успеет».

Третий случай, лето 2025. Основатель одного SaaS вёл серию постов о вайб-кодинге и однажды утром нашёл, что агент удалил всю прод-базу. Его вывод был жёстким:

В vibe-coding-приложениях нельзя обеспечить заморозку кода. Просто никак.

- основатель SaaS-компании, июль 2025, из постов в X

CEO платформы ответил на следующий день: за выходные они выкатили автоматическое разделение dev- и prod-баз для всех аккаунтов, чтобы такое не повторилось.

Вывод: dev и prod - физически разные базы, с разными правами доступа. Архитектура «одна прод-база, к которой ходит и разработка, и продакшен» в 2026 году - это заложенная под проект мина.

Как запретить ИИ-агенту удалять базу: 7 правил

Команды восстановления - последний рубеж. Куда надёжнее выстроить систему, при которой агент физически не сможет уронить прод. Семь правил ниже как раз про это.

Правило 1. Plan Mode перед любой деструктивной операцией. В Claude Code:

claude --plan

Агент строит план до выполнения. Ты читаешь, видишь в плане DROP TABLE users - отменяешь. Без Plan Mode агент решает сам и применяет за миллисекунды.

Правило 2. Hooks для блокировки опасных команд. Готовый шаблон для .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "bash -c 'if echo \"$CLAUDE_TOOL_INPUT\" | grep -qE \"(DROP DATABASE|DROP TABLE|rm -rf|git reset --hard|git push --force)\"; then exit 2; fi'"
          }
        ]
      }
    ]
  }
}

Критичный нюанс: hook с кодом exit 1 не блокирует выполнение. Нужен ровно exit 2 или JSON с permissionDecision: "deny". Это есть в официальной документации hooks, но большинство примеров в интернете написаны с exit 1 и просто не работают.

Правило 3. Read-only пользователь базы для агента. Создай отдельного пользователя без прав на DROP, TRUNCATE, DELETE:

CREATE USER claude_readonly WITH PASSWORD 'xxx';
GRANT CONNECT ON DATABASE myapp TO claude_readonly;
GRANT USAGE ON SCHEMA public TO claude_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO claude_readonly;

Когда агенту реально нужно писать, переключаешься на пользователя с правами руками. На повседневные задачи (анализ, отчёты, дашборды) read-only хватает с запасом.

Правило 4. Автокоммит после каждой правки. В .claude/settings.json добавь hook на запись файлов:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "cd $CLAUDE_PROJECT_DIR && git add -A && git commit -m 'auto: $(date)' || true"
          }
        ]
      }
    ]
  }
}

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

Правило 5. Sandbox-проект для экспериментов. Никогда не давай агенту работать там, где лежат реальные данные клиентов. Заведи отдельную папку с копией проекта на синтетических данных и обкатывай на ней новый промпт, новый MCP-сервер, новый режим. Сломает - не страшно. Как в принципе устроен каркас безопасного проекта под агента, разобрано в гайде каркас проекта для вайб-кодинга.

Правило 6. Снапшоты диска через restic каждый час:

# Установить:
brew install restic       # macOS
sudo apt install restic    # Linux

# Создать репозиторий:
restic init --repo /external/backups

# Бэкап проекта:
restic --repo /external/backups backup ~/projects

# Cron каждый час:
# 0 * * * * restic --repo /external/backups backup ~/projects

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

Правило 7. Архивация JSONL-сессий Claude Code. Настрой еженедельный rsync папки ~/.claude/projects/ на внешний диск. Тогда даже через месяц после катастрофы claude-file-recovery сможет реконструировать файлы из контекста, который агент видел. Ноль рублей и одна строка в crontab.

Готовые Hooks для блокировки опасных команд

Ниже расширенный блок для .claude/settings.json. Он блокирует команды-катастрофы ещё до выполнения: DROP DATABASE, DROP TABLE, TRUNCATE, rm -rf /, git reset --hard, git push --force, chmod -R 777, а также хитрую форму «удалить всё» через DELETE FROM ... WHERE 1. Дополнительно запрещает запись агента в .env, credentials* и .git/. Копируй и вставляй в settings.json корня проекта.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "bash -c 'INPUT=\"$CLAUDE_TOOL_INPUT\"; for PATTERN in \"DROP DATABASE\" \"DROP TABLE\" \"TRUNCATE TABLE\" \"DELETE FROM .* WHERE 1\" \"rm -rf /\" \"rm -rf ~\" \"git reset --hard\" \"git push --force\" \"git push -f\" \"chmod -R 777\"; do if echo \"$INPUT\" | grep -qiE \"$PATTERN\"; then echo \"BLOCKED: $PATTERN\" >&2; exit 2; fi; done; exit 0'"
          }
        ]
      },
      {
        "matcher": "Write",
        "hooks": [
          {
            "type": "command",
            "command": "bash -c 'FILE_PATH=$(echo \"$CLAUDE_TOOL_INPUT\" | jq -r .file_path); if echo \"$FILE_PATH\" | grep -qE \"(\\.env|credentials|\\.git/|secrets)\"; then echo \"BLOCKED: write to sensitive path\" >&2; exit 2; fi; exit 0'"
          }
        ]
      }
    ]
  }
}

Что этот блок ловит:

• DROP DATABASE, DROP TABLE, TRUNCATE TABLE
• DELETE FROM ... WHERE 1 - маскировка под «удалить всё»
• rm -rf / и rm -rf ~
• git reset --hard на любой ветке
• git push --force и git push -f
• chmod -R 777 - опасные права
• запись в .env, credentials*, .git/, secrets*

Когда тебе реально нужно выполнить заблокированную команду (например, сознательный git push --force после переписывания истории), временно сними защиту переменной окружения:

CLAUDE_HOOKS_DISABLE=1 git push --force origin main

Либо запусти команду напрямую в терминале без агента. Hooks работают только внутри Claude Code, обычную оболочку они не трогают.

Когда давать ИИ права, а когда нет

Категорически не давай агенту флаг --dangerously-skip-permissions на проектах с реальными данными. В этом режиме (его называют YOLO) отключаются все защиты: агент запускает любые Bash-команды и пишет файлы без подтверждения. Anthropic описывает флаг как опцию для «доверенных окружений», но на практике 2026 года это прямой путь к тем самым девяти секундам, за которые уходит база.

Когда агент получает право не спрашивать, он делает три вещи:

• запускает любые Bash-команды без подтверждения;
• пишет файлы без вопросов;
• может вызвать субагента, который наследует YOLO без возможности отката.

Третий пункт самый коварный. Запустил основной агент в YOLO - его субагенты тоже в YOLO, и переопределить это уже нельзя. Один промпт, и каскад параллельных агентов делает с системой что угодно.

Альтернатива - точечные разрешения. В .claude/settings.json явно перечисляешь, что можно и что нельзя:

{
  "permissions": {
    "allow": [
      "Bash(git status:*)",
      "Bash(git log:*)",
      "Bash(npm run build:*)",
      "Read(*)",
      "Edit(src/**)"
    ],
    "deny": [
      "Bash(rm:*)",
      "Bash(git push:*)",
      "Edit(.env)",
      "Edit(prisma/migrations/*)"
    ]
  }
}

Агент видит периметр: что разрешено, что запрещено. Тебе не нужно жать «yes» на каждый шаг, при этом опасное он не выполнит. Если запускаешь несколько агентов сразу в разных ветках, безопаснее развести их по изолированным копиям репозитория, про это отдельно в гайде git worktree и параллельные агенты Claude.

Чек-лист: что делать, когда ИИ удалил данные

Сохрани страницу в закладки. В момент катастрофы открываешь её и идёшь строго по порядку - это экономит минут тридцать паники и не даёт случайно перезаписать то, что ещё можно вытащить.

• Закрой терминал агента (kill -TERM, не -9)
• Не перезагружай ноутбук, не закрывай открытые процессы
• Включи запись экрана (Shift+Cmd+5 на Mac)
• Скопируй ~/.claude/projects/ в бэкап
• git reflog --all, затем git reset --hard HEAD@{N}
• Git не помог - git fsck --lost-found
• База: PITR (AWS / Yandex / Supabase) или последний снапшот, всегда в новый инстанс
• Файлы: Time Machine на Mac, lsof | grep deleted на Linux
• Последний шанс: техподдержка провайдера, S3-версии, claude-file-recovery
• После восстановления - настрой семь превентивных правил из этой статьи

А когда данные вернулись, не закрывай вкладку сразу. Разберись, как штатно откатывать агента без крайностей, по гайду как откатить изменения в Claude Code, и подтяни базу по агентам, если только начинаешь, через вайб-кодинг для новичков. Лучшая инструкция та, что прошла через твои руки до того, как случилась беда, а не после.