Если ИИ удалил базу данных: план действий на первые 7 минут

Практические материалы об Ailoot доступны в документации.

Первая минута: остановите действия и не паникуйте#

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

1. Остановите терминал с агентом

Немедленно прервите опасную команду Ctrl+C, не ждите окончания удаления. Остановка агента не всегда останавливает потомков, удалённые задания и запросы базы. Определите настоящего писателя и отмените операцию; при продолжающемся разрушении усиливайте завершение. Сохраняйте посторонние процессы с полезными открытыми файлами.

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

Удалённые данные иногда восстанавливаются, но результат определяют хранилище, поведение базы, SSD discard/TRIM и последующая запись. Минимизируйте изменения повреждённого тома, не предполагая сохранности байтов.

3. Не останавливайте процессы, в которых могут быть открыты удалённые файлы

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

4. Запишите текущее состояние экрана

Запишите точное время, пути и видимый вывод команды. Запись экрана и журналы сохраняйте на отдельном проверенном устройстве, не на повреждённом томе. До восстановления сохраните там уцелевшие отслеживаемые, неотслеживаемые, игнорируемые файлы и метаданные Git.

Затем используйте оставшееся время для диагностики и восстановления.

Минуты 2–3: точно зафиксируйте произошедшее#

Откройте отдельное окно терминала, не то, в котором работал агент, и выполните команды.

1. Проверьте изменения в Git-репозитории:

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

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

2. Проверьте процессы агента:

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

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

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

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

cp -r ~/.claude/projects /external/incident-evidence/claude-projects

Замените /external/incident-evidence/ существующей папкой на отдельном проверенном смонтированном устройстве. Не пишите на повреждённый том и не затирайте доказательства. Здесь сохраняется дословный журнал агента для проверки команд и порядка.

Минута 4: проверьте Git reflog#

Git reflog записывает движения локальных ссылок, пока сохраняются записи. Сроки и pruning различаются, недостижимые объекты удаляются. Это не гарантированный архив каждого коммита. Следующие действия выполняйте из сохранённой копии на отдельном устройстве.

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

git reflog --all

Вы увидите записи примерно такого вида:

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

Найдите запись, соответствующую состоянию до инцидента. Она указывает на положение ссылки в тот момент.

Шаг2. Восстановите в отдельную рабочую копию.

Сначала скопируйте репозиторий и сохранившуюся работу на отдельное устройство. Команды выполняйте из сохранённой копии. Подставьте точный SHA коммита, проверенный в reflog, и выберите свободные ветку и каталог:

RECOVERY_COMMIT='replace-with-verified-commit-sha'
git worktree add -b recovery-check ../recovery-check "$RECOVERY_COMMIT"

Изучите файлы ../recovery-check и сравните с сохранёнными незакоммиченными правками до копирования назад. Команда не сбрасывает повреждённое рабочее дерево. Связанные worktree делят хранилище объектов скопированного Git, поэтому это рабочая область восстановления, не независимая резервная копия. См. git-worktree.

Если reflog очищен, например после git gc:

git fsck --lost-found

Команда ищет коммиты и объекты файлов, которые больше не связаны с ветками. Найденные объекты могут появиться в .git/lost-found/commit/ и .git/lost-found/other/. Извлечь содержимое объекта можно так:

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

Когда reflog не поможет:

• Файл находился только в рабочем каталоге и не был закоммичен или сохранён в stash: reflog его не отслеживает.
• Прошло больше 90 дней, а срок хранения истёк и был запущен git gc.
• Удалён весь репозиторий вместе с .git: тогда понадобится Time Machine или снимок диска.

Минута 5: восстановите базу из резервной копии#

Если данные удалены командами DROP DATABASE, DROP TABLE или DELETE FROM ... WHERE ..., выясните, какие варианты восстановления доступны для вашей базы.

Шаг 1. Проверьте настройки восстановления у провайдера:

Шаг 2. Восстановите базу в новый экземпляр:

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

Шаг 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 проверьте раздел Dashboard → Database → Backups: убедитесь, что PITR включён и доступен снимок для восстановления. Перед изменением настроек сверяйтесь с актуальной документацией Supabase.

Минута 6: проверьте Time Machine, lsof и снимки диска#

macOS — Time Machine:

# Показать доступные резервные копии
tmutil listbackups

# Восстановить файл из резервной копии
tmutil restore /Volumes/Backup/.../my-project/file.tsx /external/incident-evidence/my-project/file.tsx

Период хранения снимков зависит от конфигурации Time Machine и доступного места. Если компьютер регулярно подключался к Time Capsule или внешнему диску, проверьте, есть ли там нужная версия проекта.

Linux — файл удалён, но процесс продолжает его держать:

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

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

# Скопировать файл через дескриптор процесса
sudo cp /proc/12345/fd/24 /external/incident-evidence/recovered-file.txt

Возможность такого восстановления зависит от того, открыт ли файл и доступна ли файловая система. Приведённый способ относится к системам Linux с каталогом /proc.

macOS — поиск удалённых файлов через lsof:

lsof | grep deleted

На macOS копирование содержимого открытого файла может быть сложнее: стандартного пути /proc/ нет. Для исследования памяти процесса иногда используют lldb, но адрес и размер данных нельзя подставлять наугад:

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

Создание образа раздела в Linux:

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

Команда записывает содержимое раздела в файл образа. Сохраняйте его на другом носителе и по возможности не работайте с исходным разделом. Для анализа образа могут подойти extundelete или photorec; результат зависит от файловой системы и того, какие блоки успели перезаписаться.

Минута 7: если резервной копии нет#

Вариант 1 — обратиться в поддержку провайдера:

Свяжитесь с AWS, Yandex Cloud, Google Cloud или DigitalOcean через официальный канал поддержки. Укажите время инцидента, идентификаторы ресурсов и приложите снимки экрана. Возможность восстановления зависит от сервиса, настроек хранения и времени, прошедшего после удаления; заранее считать её гарантированной нельзя.

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

Перед выполнением команды уточните в официальной документации формат --copy-source и значения параметров для своей версии AWS CLI.

Семь правил, которые снижают риск повторения#

1. Используйте Plan Mode перед потенциально разрушительными действиями. В Claude Code его можно запустить так:

claude --plan

В этом режиме агент сначала формирует план, который можно проверить до выполнения команд. Сверяйтесь с актуальной инструкцией Anthropic по Plan Mode. Подробнее — в руководстве по Plan Mode в Claude Code.

2. Hooks как дополнительный сигнал. Проверенный PreToolUse читает JSON stdin и возвращает2 для обнаруженного опасного действия. Полный пример ниже покрывает Bash, Write и Edit, но пропускает косвенные операции и не создаёт границу безопасности. Ограничьте права базы и sandbox. Подробнее — в руководстве hooks.

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

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;

Если задаче действительно нужна запись, используйте отдельную учётную запись с необходимыми правами. Для чтения данных и подготовки отчётов может хватить пользователя с доступом только на чтение. Следуйте документации PostgreSQL по управлению ролями и паролями.

4. Сохраняйте в Git проверенные изменения. Hook PostToolUse в .claude/settings.json может выводить напоминание после операций Write и Edit:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "printf '%s\\n' 'Проверьте diff и вручную закоммитьте только согласованные файлы.' >&2"
          }
        ]
      }
    ]
  }
}

Этот пример только выводит напоминание; он не добавляет файлы в индекс и не создаёт коммитов. Проверьте diff и вручную закоммитьте только согласованные файлы. Reflog не сохраняет незакоммиченные изменения.

5. Экспериментируйте в изолированной среде. Не подключайте агент к проекту с реальными клиентскими данными для проверки новых промптов, агентов или MCP-серверов. Используйте отдельный проект с тестовыми данными и ограниченными доступами.

6. Настройте регулярные снимки с помощью restic.

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

# Создать репозиторий резервных копий
restic init --repo /external/backups

# Сохранить копию проекта
restic --repo /external/backups backup ~/projects

# Открыть crontab для настройки расписания
crontab -e
# Добавить строку:
0 * * * * restic --repo /external/backups backup ~/projects

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

7. Сохраняйте копии JSONL-сессий Claude Code. Если журнал нужен для разбора действий, настройте регулярное копирование каталога ~/.claude/projects/ на отдельный носитель. Подробности команды приведены выше.

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

Объедините эту запись с .claude/settings.json, не заменяя существующие hooks:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash|Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "python3 \"$CLAUDE_PROJECT_DIR/.claude/hooks/check-risk.py\""
          }
        ]
      }
    ]
  }
}

Создайте .claude/hooks/check-risk.py для Python3:

import json
import re
import sys
from pathlib import Path

try:
    event = json.load(sys.stdin)
    tool = event["tool_name"]
    data = event["tool_input"]
    blocked = False
    if tool == "Bash":
        command = data["command"]
        blocked = bool(re.search(
            r"drop\s+(database|table)|truncate\s+table|"
            r"delete\s+from.*where\s+1|rm\s+-rf|"
            r"git\s+reset\s+--hard|git\s+push.*(--force|-f)|"
            r"chmod\s+-R\s+777",
            command, re.IGNORECASE | re.DOTALL))
    elif tool in ("Write", "Edit"):
        path = Path(data["file_path"]).resolve()
        blocked = (".git" in path.parts or path.name.startswith(
            (".env", "credentials", "secrets")))
except (ValueError, KeyError, TypeError, OSError):
    print("BLOCKED: invalid hook input", file=sys.stderr)
    sys.exit(2)

if blocked:
    print("BLOCKED: high-risk command or sensitive path", file=sys.stderr)
    sys.exit(2)
sys.exit(0)

Hook читает документированный JSON события из stdin, проверяет tool_input.command или tool_input.file_path и возвращает2 при совпадении. Проверяются и Write, и Edit. До использования испытайте безвредные разрешённую и запрещённую фикстуры и подтвердите запуск Python и нужного скрипта.

Это лексическая проверка: она пропускает переставленные флаги, скрипты, алиасы, маскировку, другие инструменты и косвенные записи, а безвредные цитаты может запрещать. Она не меняет права ОС или базы. Держите рабочие ключи вне среды агента, используйте роль базы только для чтения, принудительный sandbox и защитите конфигурацию hook от изменений. См. вход и коды выхода hooks.

Намеренное исключительное действие после проверки выполняйте вне агента с подходящей ограниченной учётной записью. Переменная оболочки не является документированным отключением hook; обычные команды терминала этими hooks не управляются.

Когда предоставлять ИИ-агенту доступ, а когда ограничивать его#

Anthropic описывает --dangerously-skip-permissions как параметр пропуска проверок разрешений для соответствующего окружения. Перед применением ознакомьтесь с актуальной документацией и оцените доступные агенту данные и команды. Работа без обычных подтверждений может привести к тому, что агент:

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

Проверьте, какие ограничения наследуются такими процессами в вашей версии продукта.

Правило:

Альтернатива — точечные разрешения. Пример .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/*)"
    ]
  }
}

Укажите только те действия, которые действительно нужны агенту, и проверьте правила по документации для используемой версии Claude Code.

Чек-лист на первые 7 минут#

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

1. Немедленно остановите настоящего разрушительного писателя и проверьте потомков и удалённые операции.
2. Не перезагружайте; сохраняйте посторонние процессы с открытыми удалёнными файлами.
3. Запишите время и доказательства команд на отдельное проверенное устройство.
4. Скопируйте уцелевшие файлы, Git и нужные журналы сессий на то же отдельное устройство.
5. В сохранённой копии изучите git reflog --all и восстановите проверенный коммит отдельным worktree.
6. Если reflog не помог, проверьте git fsck --lost-found.
7. Для базы проверьте PITR или последний снимок.
8. Для файлов проверьте Time Machine на Mac и lsof в Linux.
9. В последнюю очередь обратитесь в поддержку провайдера и проверьте версионирование S3.
10. После восстановления настройте превентивные меры из этого руководства.

Дополнительные материалы:

• Plan Mode в Claude Code — подготовка плана до потенциально опасной операции.
• Hooks в Claude Code — примеры блокировки рискованных команд.
• Как откатить изменения в Claude Code — /rewind, Git и другие способы отмены изменений.
• Проверка безопасности в Claude Code — регулярная оценка безопасности кода.

Открыть Ailoot.