# Если ИИ удалил базу данных: план действий на первые 7 минут > Пошаговый план восстановления после удаления данных ИИ-агентом: Git reflog, PostgreSQL PITR, Time Machine, AWS RDS и резервные копии. Команды, ограничения и меры защиты. Source: https://ailoot.ai/blog/ru/ai-deleted-database-recovery/ Canonical: https://ailoot.ai/blog/ru/ai-deleted-database-recovery/ Language: ru Publisher: Ailoot (https://ailoot.ai/) Translation: guide-032 Revision: sha256-efe0e6155bb4448853d311530a3349d613faab74073048e62b4cc21c1e07d9a3
Кратко ИИ-агент удалил базу, файлы или всю рабочую среду. Первые 7 минут важны: сначала остановите агента, затем зафиксируйте состояние и переходите к восстановлению. Действуйте спокойно и последовательно, сверяясь с инструкциями ниже.
[Практические материалы об Ailoot доступны в документации](https://ailoot.ai/docs/). ## Первая минута: остановите действия и не паникуйте
Кратко Немедленно остановите разрушительную запись, включая продолжающие работу потомки агента. Не перезагружайте и не завершайте посторонние процессы с открытыми удалёнными файлами. Восстановление не гарантировано: перезапись и SSD discard/TRIM способны уничтожить данные. До изменения повреждённой копии сохраните доказательства и уцелевшее на отдельном проверенном устройстве.
Первым делом прекратите работу агента. Не просите его отменить изменения и не запускайте новый запрос: дополнительные действия могут перезаписать блоки, где сохранились данные. 1. ### Остановите терминал с агентом Немедленно прервите опасную команду Ctrl+C, не ждите окончания удаления. Остановка агента не всегда останавливает потомков, удалённые задания и запросы базы. Определите настоящего писателя и отмените операцию; при продолжающемся разрушении усиливайте завершение. Сохраняйте посторонние процессы с полезными открытыми файлами. 2. ### Не перезагружайте ноутбук Удалённые данные иногда восстанавливаются, но результат определяют хранилище, поведение базы, SSD discard/TRIM и последующая запись. Минимизируйте изменения повреждённого тома, не предполагая сохранности байтов. 3. ### Не останавливайте процессы, в которых могут быть открыты удалённые файлы Сохраняйте посторонние процессы с удалёнными открытыми файлами: возможна копия через дескриптор. Это не относится к разрушительному писателю: его остановите первым. Не продолжайте удаление ради открытого дескриптора. 4. ### Запишите текущее состояние экрана Запишите точное время, пути и видимый вывод команды. Запись экрана и журналы сохраняйте на отдельном проверенном устройстве, не на повреждённом томе. До восстановления сохраните там уцелевшие отслеживаемые, неотслеживаемые, игнорируемые файлы и метаданные Git. Затем используйте оставшееся время для диагностики и восстановления. ## Минуты 2–3: точно зафиксируйте произошедшее
Кратко Перед восстановлением выясните, что именно удалено, кем и когда, а также какие команды выполнялись. Иначе можно действовать вслепую и повредить данные, которые ещё доступны. В отдельном окне терминала выполните `git status`, `git log --since` и `ps aux | grep claude`. Скопируйте каталог `~/.claude/projects/`: журнал сессий может помочь установить последовательность действий.
Откройте отдельное окно терминала, не то, в котором работал агент, и выполните команды. **1. Проверьте изменения в Git-репозитории:** ```bash git status git log --since="30 minutes ago" --all --oneline ``` Удалённый отслеживаемый файл может оставаться в индексе или коммите. До восстановления сохраните рабочую папку, включая неотслеживаемое и игнорируемое: восстановление на месте перезапишет уцелевшие правки. Изучайте и восстанавливайте отдельную копию. **2. Проверьте процессы агента:** ```bash ps aux | grep -i claude ps aux | grep -i cursor ``` Определите процесс, продолжающий опасную запись: одного совпадения имени недостаточно. Остановите писателя и проверьте остановку. Сохраняйте посторонние процессы с полезными дескрипторами. При неуспешном мягком завершении и продолжающемся разрушении может понадобиться принудительное. **3. Сохраните журнал сессии:** Claude Code хранит JSONL-сессии в `~/.claude/projects/`, а Cursor — в `~/.cursor/`. Создайте копию каталога Claude Code: ```bash cp -r ~/.claude/projects /external/incident-evidence/claude-projects ``` Замените /external/incident-evidence/ существующей папкой на отдельном проверенном смонтированном устройстве. Не пишите на повреждённый том и не затирайте доказательства. Здесь сохраняется дословный журнал агента для проверки команд и порядка. ## Минута 4: проверьте Git reflog
Кратко Reflog помогает найти коммиты, исчезнувшие из истории ветки, но не сохраняет незакоммиченные рабочие файлы. Сначала сохраните уцелевшее и Git на отдельном устройстве. Затем изучайте скопированный репозиторий и восстанавливайте проверенный коммит отдельным worktree. Не начинайте сбросом повреждённой папки.
Git reflog записывает движения локальных ссылок, пока сохраняются записи. Сроки и pruning различаются, недостижимые объекты удаляются. Это не гарантированный архив каждого коммита. Следующие действия выполняйте из сохранённой копии на отдельном устройстве. **Шаг 1. Просмотрите журнал:** ```bash git reflog --all ``` Вы увидите записи примерно такого вида: ``` 1a2b3c4 HEAD@{0}: reset: moving to HEAD~3 9z8y7x6 HEAD@{1}: commit: рабочая версия дашборда 5w4v3u2 HEAD@{2}: commit: добавил админку ``` Найдите запись, соответствующую состоянию до инцидента. Она указывает на положение ссылки в тот момент. **Шаг2. Восстановите в отдельную рабочую копию.** Сначала скопируйте репозиторий и сохранившуюся работу на отдельное устройство. Команды выполняйте из сохранённой копии. Подставьте точный SHA коммита, проверенный в reflog, и выберите свободные ветку и каталог: ```bash RECOVERY_COMMIT='replace-with-verified-commit-sha' git worktree add -b recovery-check ../recovery-check "$RECOVERY_COMMIT" ``` Изучите файлы ../recovery-check и сравните с сохранёнными незакоммиченными правками до копирования назад. Команда не сбрасывает повреждённое рабочее дерево. Связанные worktree делят хранилище объектов скопированного Git, поэтому это рабочая область восстановления, не независимая резервная копия. См. [git-worktree](https://git-scm.com/docs/git-worktree). **Если reflog очищен, например после `git gc`:** ```bash git fsck --lost-found ``` Команда ищет коммиты и объекты файлов, которые больше не связаны с ветками. Найденные объекты могут появиться в `.git/lost-found/commit/` и `.git/lost-found/other/`. Извлечь содержимое объекта можно так: ```bash git cat-file -p > recovered-file.ext ``` **Когда reflog не поможет:** - Файл находился только в рабочем каталоге и не был закоммичен или сохранён в stash: reflog его не отслеживает. - Прошло больше 90 дней, а срок хранения истёк и был запущен `git gc`. - Удалён весь репозиторий вместе с `.git`: тогда понадобится Time Machine или снимок диска. ## Минута 5: восстановите базу из резервной копии
Кратко PostgreSQL Point-In-Time Recovery (PITR) позволяет восстановить состояние базы на выбранный момент в пределах настроенного периода хранения. Возможность зависит от конфигурации провайдера и резервного копирования. PITR должен быть настроен до инцидента. Восстанавливайте данные в новый экземпляр, а не поверх рабочей базы; если PITR недоступен, проверьте последние снимки.
Если данные удалены командами `DROP DATABASE`, `DROP TABLE` или `DELETE FROM ... WHERE ...`, выясните, какие варианты восстановления доступны для вашей базы. **Шаг 1. Проверьте настройки восстановления у провайдера:** | Провайдер | Окно PITR | Способ восстановления | |----|----|----| | AWS RDS | 1–35 дней (настраивается) | `aws rds restore-db-instance-to-point-in-time --restore-time 2026-05-28T14:30:00Z` | | Yandex Cloud Managed Postgres | 7 дней (по умолчанию) | Восстановление из резервной копии в консоли с указанием времени | | Supabase Pro | 7 дней (тариф Pro+) | Интерфейс: Database → Backups → Restore | | Coolify + локальный pg_dump | Согласно расписанию cron | `pg_restore -d new_db backup.dump` | **Шаг 2. Восстановите базу в новый экземпляр:** Не перезаписывайте действующую базу резервной копией. Создайте отдельный экземпляр, проверьте его и только затем переключите приложение. Предусмотрите возможность вернуть настройки подключения к прежней базе, если возникнет проблема. **Шаг 3. Если PITR не был включён, используйте последний снимок:** ```bash # 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` и снимки диска
Кратко Если речь идёт о файлах на диске, а не о Git или базе, проверьте резервные копии и открытые дескрипторы. На macOS можно воспользоваться Time Machine. В Linux команда `sudo lsof | grep deleted` покажет удалённые файлы, которые ещё удерживаются процессом; при наличии доступа их можно скопировать из `/proc/PID/fd/N`. Для дальнейшего восстановления можно сначала создать образ раздела и затем работать с ним подходящими утилитами.
**macOS — Time Machine:** ```bash # Показать доступные резервные копии tmutil listbackups # Восстановить файл из резервной копии tmutil restore /Volumes/Backup/.../my-project/file.tsx /external/incident-evidence/my-project/file.tsx ``` Период хранения снимков зависит от конфигурации Time Machine и доступного места. Если компьютер регулярно подключался к Time Capsule или внешнему диску, проверьте, есть ли там нужная версия проекта. **Linux — файл удалён, но процесс продолжает его держать:** ```bash # Найти удалённые файлы, открытые процессами 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`:** ```bash lsof | grep deleted ``` На macOS копирование содержимого открытого файла может быть сложнее: стандартного пути `/proc/` нет. Для исследования памяти процесса иногда используют `lldb`, но адрес и размер данных нельзя подставлять наугад: ```text lldb -p 12345 (lldb) memory read --outfile recovered.txt --binary 0xADDRESS 0xSIZE ``` **Создание образа раздела в Linux:** ```bash sudo dd if=/dev/sda1 of=/external/disk-image.img bs=4M status=progress ``` Команда записывает содержимое раздела в файл образа. Сохраняйте его на другом носителе и по возможности не работайте с исходным разделом. Для анализа образа могут подойти `extundelete` или `photorec`; результат зависит от файловой системы и того, какие блоки успели перезаписаться. ## Минута 7: если резервной копии нет
Кратко Если копии нет, reflog пуст, а блоки уже перезаписаны, проверьте два последних варианта: обратитесь в поддержку облачного провайдера и выясните, доступно ли версионирование объектов в S3. Восстановление зависит от настроек аккаунта и доступности данных у провайдера.
**Вариант 1 — обратиться в поддержку провайдера:** Свяжитесь с AWS, Yandex Cloud, Google Cloud или DigitalOcean через официальный канал поддержки. Укажите время инцидента, идентификаторы ресурсов и приложите снимки экрана. Возможность восстановления зависит от сервиса, настроек хранения и времени, прошедшего после удаления; заранее считать её гарантированной нельзя. **Вариант 2 — проверить версионирование S3:** Если объекты хранились в S3 или Yandex Object Storage и версионирование было включено, проверьте список версий и маркеров удаления. ```bash # 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. ## Семь правил, которые снижают риск повторения
Кратко Риск снижают планирование, испытанные hooks выбранных опасных строк вместе с принудительными правами, отдельная роль базы, проверенные коммиты, изолированная среда, резервные копии и журналы. До доверия проверьте фактический охват каждого слоя.
**1. Используйте Plan Mode перед потенциально разрушительными действиями.** В Claude Code его можно запустить так: ```bash claude --plan ``` В этом режиме агент сначала формирует план, который можно проверить до выполнения команд. Сверяйтесь с актуальной инструкцией Anthropic по Plan Mode. Подробнее — в [руководстве по Plan Mode в Claude Code](https://ailoot.ai/blog/ru/claude-code-plan-mode/). **2. Hooks как дополнительный сигнал.** Проверенный PreToolUse читает JSON stdin и возвращает2 для обнаруженного опасного действия. Полный пример ниже покрывает Bash, Write и Edit, но пропускает косвенные операции и не создаёт границу безопасности. Ограничьте права базы и sandbox. Подробнее — в [руководстве hooks](https://ailoot.ai/blog/ru/claude-code-hooks/). **3. Выдайте агенту отдельного пользователя базы данных только для чтения.** Не предоставляйте ему привилегии изменения или удаления данных: ```sql 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`: ```json { "hooks": { "PostToolUse": [ { "matcher": "Write|Edit", "hooks": [ { "type": "command", "command": "printf '%s\\n' 'Проверьте diff и вручную закоммитьте только согласованные файлы.' >&2" } ] } ] } } ``` Этот пример только выводит напоминание; он не добавляет файлы в индекс и не создаёт коммитов. Проверьте diff и вручную закоммитьте только согласованные файлы. Reflog не сохраняет незакоммиченные изменения. **5. Экспериментируйте в изолированной среде.** Не подключайте агент к проекту с реальными клиентскими данными для проверки новых промптов, агентов или MCP-серверов. Используйте отдельный проект с тестовыми данными и ограниченными доступами. **6. Настройте регулярные снимки с помощью `restic`.** ```bash # Установить 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 для блокировки опасных команд
Кратко Ниже PreToolUse-проверка выбранных строк Bash и чувствительных путей Write/Edit. Она читает JSON stdin и отклоняет совпадения кодом2. Косвенные и маскируемые действия могут пройти: это дополнение sandbox и ограниченным ключам. Объедините с текущими настройками и испытайте до применения.
Объедините эту запись с .claude/settings.json, не заменяя существующие hooks: ```json { "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: ```python 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](https://code.claude.com/docs/en/hooks). Намеренное исключительное действие после проверки выполняйте вне агента с подходящей ограниченной учётной записью. Переменная оболочки не является документированным отключением hook; обычные команды терминала этими hooks не управляются. ## Когда предоставлять ИИ-агенту доступ, а когда ограничивать его
Кратко Не используйте `--dangerously-skip-permissions` для проектов с реальными данными: этот режим позволяет обходить подтверждения для операций, которые обычно требуют разрешения. Для экспериментов применяйте изолированную среду с тестовыми данными. В остальных случаях настройте точечные разрешения `allow` и `deny` в `.claude/settings.json` и проверьте их действие.
Anthropic описывает `--dangerously-skip-permissions` как параметр пропуска проверок разрешений для соответствующего окружения. Перед применением ознакомьтесь с актуальной документацией и оцените доступные агенту данные и команды. Работа без обычных подтверждений может привести к тому, что агент: - Запустит Bash-команды без привычного запроса подтверждения. - Запишет файлы без отдельного согласования каждого изменения. - Запустит вспомогательные процессы или агентов, если это предусмотрено используемой конфигурацией и инструментами. Проверьте, какие ограничения наследуются такими процессами в вашей версии продукта. **Правило:** | Ситуация | Допустим ли режим пропуска разрешений? | |---|---| | Эксперимент с новым MCP-сервером в изолированной папке | ✅ Да, при наличии тестовых данных | | Проверка нового промпта на тестовых данных | ✅ Да, при наличии изоляции | | Работа с реальными файлами проекта | ❌ Нет | | Команды, затрагивающие базу данных | ❌ Нет | | Развёртывание в продакшене | ❌ Нет | | Управление инфраструктурой (AWS, Yandex Cloud) | ❌ Нет | **Альтернатива — точечные разрешения.** Пример `.claude/settings.json`: ```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 минут
Кратко Сохраните порядок первых действий: остановите агента, не перезагружайте компьютер, зафиксируйте состояние, проверьте Git, резервные копии и доступные способы восстановления. После инцидента пересмотрите ограничения доступа и расписание резервного копирования.
**Чек-лист «ИИ удалил данные — что делать»:** 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](https://ailoot.ai/blog/ru/claude-code-plan-mode/) — подготовка плана до потенциально опасной операции. - [Hooks в Claude Code](https://ailoot.ai/blog/ru/claude-code-hooks/) — примеры блокировки рискованных команд. - [Как откатить изменения в Claude Code](https://ailoot.ai/blog/ru/claude-code-undo-changes/) — `/rewind`, Git и другие способы отмены изменений. - [Проверка безопасности в Claude Code](https://ailoot.ai/blog/ru/claude-code-security-review/) — регулярная оценка безопасности кода.
### Официальные источники - [Anthropic Claude Code: Hooks](https://code.claude.com/docs/en/hooks-guide) - [Anthropic Claude Code: общие рабочие процессы](https://code.claude.com/docs/en/common-workflows) - [PostgreSQL: непрерывное архивирование и восстановление на момент времени](https://www.postgresql.org/docs/current/continuous-archiving.html) - [AWS RDS: восстановление экземпляра базы данных на заданный момент](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html) - [Yandex Cloud Managed PostgreSQL: резервное копирование и восстановление](https://yandex.cloud/ru/docs/managed-postgresql/concepts/backup) - [Git: документация по reflog](https://git-scm.com/docs/git-reflog) - [Git: режим `--lost-found` команды fsck](https://git-scm.com/docs/git-fsck)
[Открыть Ailoot](https://ailoot.ai/). ## Вопросы и ответы ### Нужно ли ждать окончания текущей команды агента? Нет. Немедленно остановите разрушительного писателя и подтвердите остановку потомков, удалённых заданий и запросов базы. Сохраняйте посторонние процессы с восстанавливаемыми открытыми файлами. Остановки одного агента может не хватить. ### Можно ли начать с git reset --hard? Сначала сохраните отслеживаемые, неотслеживаемые, игнорируемые файлы и Git на отдельное устройство. Изучите копию и восстановите проверенный коммит отдельным worktree. Сброс на месте уничтожает уцелевшие незакоммиченные правки. ## Ailoot · Компания и портфель её проектов Ailoot опирается на накопленный опыт работы, большую клиентскую базу, стабильный сервис и постоянный контроль KPI. Компания и портфель её проектов: миллионы клиентов; продажи на миллиарды ежемесячно. Этот опыт Ailoot использует для API-доступа к нейросетям в продуктах клиентов, агентах, приложениях и автоматизациях.