Что делать, если ИИ удалил твою базу данных: playbook за 7 минут

Каждый день в Telegram-канале - что нового в вайб-кодинге: инструменты, примеры, ошибки. Подпишись, чтобы быть в курсе.

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

В апреле 2026 года Cursor с моделью Claude Opus 4.6 за 9 секунд удалил продакшен-базу стартапа PocketOS вместе со всеми резервными копиями. Через минуту агент написал в чате:

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

1. Закрой терминал с агентом

   Ctrl+C или закрой окно. Если агент выполняет команду - дай завершиться, потом закрывай. Принудительный kill через SIGKILL может оставить процессы-зомби.

2. НЕ перезагружай ноутбук

   Файлы, удалённые через rm или DROP DATABASE, физически ещё лежат на диске - просто помечены как «свободные блоки». Любая запись на диск может их перезаписать.

3. НЕ закрывай открытые процессы

   Если процесс держал удалённый файл открытым, его можно вернуть через lsof (см. ниже). Закроешь процесс - потеряешь.

4. Включи запись экрана

   macOS: Shift+Cmd+5 → Record Entire Screen. Тебе понадобятся скриншоты состояния для AWS или Yandex Cloud и для разбора инцидента.

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

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

Открой новое окно терминала. Не то, где сидит агент - другое. Выполни три команды по очереди.

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

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

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

2. Проверь, какие процессы агента работают:

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

Если видишь активные процессы - убей их через kill -TERM PID. Не kill -9, а именно -TERM, чтобы дать корректно закрыть файловые дескрипторы.

3. Сохрани лог сессии агента:

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

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

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

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

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 НЕ помогает:

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

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

База удалена DROP DATABASE, DROP TABLE или DELETE FROM ... WHERE ... (без 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 активен И что у тебя есть snapshot к чему откатываться.

Хочешь не только знать команды, но и собрать систему, при которой ИИ-агент в принципе не уронит прод? Команды - лишь последний рубеж. На практикуме за 3 эфира собираешь все три кита смысло-кодинга: ИИ-клон + Второй мозг + Контекст-инжиниринг - связку, при которой Claude не угадывает, а работает по твоим правилам из CLAUDE.md и Plan Mode.

Практикум по вайб-кодингу

+Твой второй мозг

3 вечера - стек, метод, первый проект

Старт 9–11 июня  ·  2 000 ₽

Записаться →

Минута 6: Time Machine, lsof и snapshot диска

macOS - Time Machine:

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

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

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

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:

lsof | grep deleted

Скопировать файл сложнее (нет /proc/), но можно через lldb:

lldb -p 12345
(lldb) memory read --outfile recovered.txt --binary 0xADDRESS 0xSIZE

Snapshot всего диска (Linux, последний шанс):

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

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

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

Вариант 1 - техподдержка провайдера:

AWS, Yandex Cloud, Google Cloud и DigitalOcean периодически поднимают данные из своего внутреннего хранилища даже после катастрофы клиента, особенно на платных тарифах. Пиши через тикет, укажи точное время инцидента, добавь скриншоты состояния. Чаще всего срабатывает на крупных провайдерах с автоматическими бэкапами на их стороне. Полная история DataTalks.Club, где AWS вернул 2.5 года данных - в разделе «Реальные примеры» ниже. Шанс - 40-60%, окно реакции - 24-72 часа.

Вариант 2 - 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

Вариант 3 - реконструкция из JSONL-сессий Claude Code:

В апреле 2026 один пользователь на Hacker News описал случай: его агент удалил недельную работу, git reflog пуст, бэкапа нет. Помогла утилита claude-file-recovery:

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

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

Критичный нюанс: Claude Code не хранит сессии вечно - по сообщениям из коммьюнити, старые JSONL-файлы удаляются автоматически через несколько недель. Чтобы у тебя в случае катастрофы был месяц JSONL-истории, копируй ~/.claude/projects/ на внешний диск раз в неделю простым cron:

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

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

Реальные примеры 2026: PocketOS, DataTalks и Replit

PocketOS - 9 секунд, базы нет, бэкапов нет. Апрель 2026. Cursor с Claude Opus 4.6 получил задачу «прибрать staging-окружение» и одним вызовом API в Railway удалил продакшен-volume вместе с volume-level бэкапами. Бэкапы лежали в том же volume - это и убило компанию.

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

DataTalks.Club - 2.5 года данных, спасло AWS. Март 2026. Claude Code случайно стёр продакшен-инфраструктуру DataTalks.Club - платформы по data engineering для тысяч программистов. Основатель Алексей Григорьев публично разобрал инцидент: ситуацию спасло обращение в техподдержку AWS, они подняли все данные за 2.5 года из своего внутреннего хранилища. Подробности - в его разборе на ixbt. Главное, что Григорьев подчеркнул в выводе: восстановление через техподдержку - это случайность, а не процесс, на которую опасно полагаться.

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

Replit Agent - прод стёрт у Jason Lemkin (июль 2025). Основатель SaaStr Джейсон Лемкин писал серию постов в X про вайб-кодинг с Replit. Утром нашёл, что агент удалил всю прод-БД. Главный его вывод:

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

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

7 правил, чтобы это никогда не повторилось

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

claude --plan

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

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'"
          }
        ]
      }
    ]
  }
}

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

Подробнее про настройку - в гайде Hooks в Claude Code 2026.

3. Read-only DB user для агента. Создай отдельного пользователя для агента, который не имеет прав на 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. Автокоммит каждые 10 минут. В .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"
          }
        ]
      }
    ]
  }
}

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

5. Sandbox-проект для экспериментов. Никогда не давай агенту работать в проекте, где есть реальные данные клиентов. Создай отдельную папку ~/sandbox-projects/, в ней - копия проекта со синтетическими данными. На ней пробуешь новый промпт, новый агент, новый MCP-сервер. Если ломает - не страшно.

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

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

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

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

# Поставить cron каждый час:
crontab -e
# Добавить:
0 * * * * restic --repo /external/backups backup ~/projects

7 дней почасовых, 4 недели суточных - и у тебя всегда есть откатиться на любую точку прошлого. Стоит 0 рублей, занимает 10 минут установки.

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

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

Готовый блок для .claude/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, не в обычном терминале.

Когда стоит давать ИИ права (и когда - нет)

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

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

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

Правило:

Альтернатива - precision permissions. В .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» или «no» - агент работает быстро, ты контролируешь периметр.

Что дальше: чек-лист на 7 минут к закладке

Чек-лист «ИИ удалил - что делать»:

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

Дальше - системная защита:

• Plan Mode в Claude Code - чтобы агент строил план до деструктивной операции
• Hooks в Claude Code - готовые шаблоны блокировки опасных команд
• Как откатить изменения в Claude Code - подробный гайд по /rewind, git и 5 способам штатного отката
• Security review в Claude Code - регулярная проверка безопасности кода

Полная схема по вайб-кодингу за вечер: ИИ-клон + Второй мозг + контекст-инжиниринг. Чтобы Claude не угадывал, а работал по твоим правилам - и катастрофы не повторялись. 3 эфира, записи остаются у тебя.

Практикум по вайб-кодингу

+Твой второй мозг

3 вечера - стек, метод, первый проект

Старт 9–11 июня  ·  2 000 ₽

Записаться →