A IA eliminou a base de dados: plano de recuperação em 7 minutos

Encontra informações práticas sobre como trabalhar com Ailoot na documentação.

O que fazer no primeiro minuto: PARE, não entre em pânico#

Quando isto lhe acontecer, a primeira coisa a fazer é parar o agente. Não tente desfazer as ações por iniciativa própria, não lhe diga «restaura tudo» e não lhe dê novas instruções. Cada ação subsequente do agente pode substituir os blocos do disco onde os seus dados ainda poderão estar armazenados.

1. Feche o terminal do agente

   Interrompa imediatamente o comando perigoso com Ctrl+C; não espere que a eliminação termine. Parar o agente pode não parar comandos filhos, tarefas remotas ou consultas de base de dados. Identifique e pare ou cancele o escritor real; intensifique a terminação se continuar a destruir dados. Mantenha processos alheios com ficheiros abertos potencialmente recuperáveis.

2. NÃO reinicie o computador portátil

   Dados eliminados podem ser recuperáveis, mas isso depende do armazenamento, da base de dados, de descarte/TRIM em SSD e de escritas posteriores. Minimize escritas no volume afetado; não assuma que os bytes ainda existem.

3. NÃO feche processos abertos

   Preserve processos alheios que mantenham ficheiros eliminados abertos, pois pode haver recuperação pelos descritores. Isto não se aplica ao escritor destrutivo: pare-o primeiro. Não mantenha uma eliminação ativa para preservar um descritor.

4. Inicie a gravação do ecrã

   Registe hora exata, caminhos afetados e saída visível do comando. Grave ou copie registos para um dispositivo separado verificado, não para o volume danificado. Preserve aí ficheiros controlados, não controlados e ignorados sobreviventes e metadados Git antes da recuperação.

A seguir, tem 6 minutos para recuperar. Vamos a isso.

Minutos 2–3: documente exatamente o que correu mal#

Abra uma nova janela de terminal. Não a janela onde o agente está a funcionar — outra. Execute estes três comandos pela ordem indicada.

1. Registe exatamente o que mudou no repositório git:

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

Um ficheiro controlado eliminado pode continuar no índice ou num commit. Preserve a árvore atual, incluindo ficheiros não controlados e ignorados, antes de restaurar; restaurar no local pode sobrepor edições sobreviventes. Inspecione e recupere numa cópia separada.

2. Verifique que processos de agente estão em execução:

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

Identifique que processo continua a fazer as escritas perigosas; uma correspondência de nome não basta. Pare-o e confirme a paragem. Preserve processos alheios com ficheiros abertos úteis; se a terminação normal falhar e a destruição continuar, pode ser necessária terminação forçada.

3. Guarde o registo da sessão do agente:

O Claude Code guarda as sessões JSONL em ~/.claude/projects/. O Cursor guarda-as em ~/.cursor/. Faça uma cópia agora mesmo:

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

Substitua /external/incident-evidence/ por uma pasta de evidência existente num dispositivo montado separado e verificado. Não copie para o volume afetado nem sobreponha evidência existente. Esta pasta contém a conversa integral com o agente — os comandos que executou, as respostas que deu e a ordem em que tudo aconteceu. É a sua principal fonte para investigar o incidente e, potencialmente, recuperar ficheiros eliminados a partir do contexto do agente (ver passo 4).

Minuto 4: git reflog — a sua melhor hipótese#

git reflog regista movimentos de referências locais enquanto as entradas forem retidas. Expiração e limpeza variam, e objetos inacessíveis podem ser removidos; não é um arquivo garantido de todos os commits. Execute os passos abaixo a partir da cópia preservada noutro dispositivo.

Passo 1. Consulte o registo:

git reflog --all

Vai obter uma lista semelhante a esta:

1a2b3c4 HEAD@{0}: reset: moving to HEAD~3
9z8y7x6 HEAD@{1}: commit: working version of the dashboard
5w4v3u2 HEAD@{2}: commit: added admin panel

Procure o ponto anterior ao momento em que o agente causou os danos. Cada entrada é um «snapshot» do estado do repositório naquele momento.

Passo 2. Recupere numa árvore de trabalho separada:

Depois de copiar repositório e trabalho sobrevivente para outro dispositivo, execute a partir dessa cópia. Substitua o valor pelo SHA exato verificado no reflog e escolha branch e destino ainda não usados:

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

Inspecione ../recovery-check e compare com os ficheiros preservados sem commit antes de copiar de volta. O comando extrai o commit separadamente, sem repor a árvore danificada. Worktrees ligados partilham os objetos Git da cópia; é um espaço de recuperação, não cópia independente. Consulte a documentação oficial git-worktree.

Se o reflog também tiver sido limpo (o agente conseguiu executar git gc):

git fsck --lost-found

Este comando encontra commits «perdidos» e blobs (objetos de ficheiro) que já não estão associados a nenhuma branch. Aparecerão em .git/lost-found/commit/ e .git/lost-found/other/. Para restaurar um ficheiro a partir daí:

git cat-file -p <SHA1-blob> > recovered-file.ext

Quando o git reflog NÃO ajuda:

• O ficheiro estava apenas na árvore de trabalho, sem commit nem stash → o reflog não o consegue encontrar
• Passaram mais de 90 dias (o valor predefinido de gc.reflogExpire) e foi executado git gc
• Todo o repositório foi eliminado (rm -rf .git) — nesse caso, precisa do Time Machine ou de um snapshot

Minuto 5: restaure a base de dados a partir de uma cópia de segurança#

A base de dados foi eliminada com DROP DATABASE, DROP TABLE ou DELETE FROM ... WHERE ... (sem uma cláusula WHERE). O que deve fazer?

Passo 1. Verifique se o seu fornecedor disponibiliza PITR:

Passo 2. Restaure para uma nova instância, não para a antiga:

Nunca restaure por cima de uma base de dados em funcionamento. Crie uma nova instância a partir da cópia de segurança e, em seguida, mude a aplicação para essa instância. Se algo correr mal, pode reverter o DNS.

Passo 3. Se a PITR não estava ativada, use o snapshot mais recente:

# AWS RDS, listar snapshots:
aws rds describe-db-snapshots --db-instance-identifier my-db

# Restaurar a partir de um snapshot:
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

Aviso sobre o Supabase, que apanhou muita gente desprevenida em 2026: quando a PITR está ativada, as cópias de segurança diárias deixam de ser criadas. É um comportamento contraintuitivo; pode acabar sem cópias de segurança. Consulte Dashboard → Database → Backups para confirmar que a PITR está ativa E que tem um snapshot para restaurar.

Minuto 6: Time Machine, lsof e snapshots do disco#

macOS — Time Machine:

# Listar snapshots:
tmutil listbackups

# Restaurar um ficheiro a partir da cópia de segurança mais recente:
tmutil restore /Volumes/Backup/.../my-project/file.tsx ~/projects/my-project/file.tsx

O Time Machine cria snapshots de hora a hora, mantém os snapshots horários durante um dia, os diários durante uma semana e os semanais indefinidamente. Se o seu computador portátil estiver ligado a uma Time Capsule ou a uma unidade externa, o seu projeto estará lá com granularidade horária.

Linux — o ficheiro foi eliminado, mas um processo ainda o tem aberto:

# Encontrar todos os ficheiros “eliminados” que um processo ainda tem abertos:
sudo lsof | grep deleted

# Vai obter linhas como:
# node 12345 user 24w REG 8,1 4096 1234567 /path/to/deleted/file.txt (deleted)

# Copiar o ficheiro diretamente de /proc/PID/fd/N:
sudo cp /proc/12345/fd/24 ~/recovered-file.txt

A probabilidade de sucesso é de ~95% se o processo não tiver sido fechado. Funciona em ext4, xfs e btrfs.

macOS — equivalente com lsof:

lsof | grep deleted

É mais difícil copiar o ficheiro (não existe /proc/), mas pode fazê-lo com lldb:

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

Snapshot do disco inteiro (Linux, último recurso):

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

Isto guarda toda a partição como uma imagem. Em seguida, recupere os dados com extundelete ou photorec. A probabilidade de recuperação depende da quantidade de dados escritos no disco desde a eliminação. Se não tiver sido escrito nada, é de 80–90%. Se o sistema já esteve em funcionamento durante uma hora, é de 20–30%.

Minuto 7: e se não houver cópia de segurança#

Opção 1 — suporte do fornecedor:

AWS, Yandex Cloud, Google Cloud e DigitalOcean recuperam periodicamente dados do respetivo armazenamento interno, mesmo depois de um desastre do lado do cliente, sobretudo nos planos pagos. Abra um pedido de suporte, indique a hora exata do incidente e inclua capturas de ecrã do estado. Isto resulta mais frequentemente com grandes fornecedores que mantêm cópias de segurança automáticas do seu lado. A probabilidade é de 40–60%; o prazo de resposta é de 24–72 horas.

Opção 2 — versionamento do S3:

Se os ficheiros estavam no S3 (ou no Yandex Object Storage) e o versionamento estava ativado, todas as versões existem fisicamente; estão simplesmente marcadas como «eliminadas».

# AWS — listar versões:
aws s3api list-object-versions --bucket my-bucket --prefix files/

# Restaurar uma versão:
aws s3api copy-object \
  --bucket my-bucket \
  --copy-source my-bucket/files/data.json?versionId=ABC123 \
  --key files/data.json

Aviso crítico: o Claude Code não guarda as sessões para sempre — os ficheiros JSONL antigos são eliminados automaticamente ao fim de várias semanas. Para garantir que tem um mês de histórico JSONL em caso de desastre, copie ~/.claude/projects/ para uma unidade externa uma vez por semana com uma tarefa cron simples:

# No crontab, todos os domingos às 03:00:
0 3 * * 0 rsync -av ~/.claude/projects/ /external/claude-history-backup/

É gratuito e salva-o quando «desapareceu tudo, não há cópia de segurança e o reflog está vazio».

7 regras para garantir que isto nunca volta a acontecer#

1. Plan Mode antes de qualquer operação destrutiva. No Claude Code:

claude --plan

O agente cria um plano antes de agir. Lê-o, vê DROP TABLE users e cancela. Sem o Plan Mode, o agente decide por si e executa em milissegundos. Saiba mais no guia do Plan Mode no Claude Code.

2. Hooks como alarme adicional. Use um PreToolUse testado que leia JSON de stdin e devolva 2 para ações de alto risco reconhecidas. O exemplo completo abaixo cobre Bash, Write e Edit; não é um limite de segurança e pode falhar operações indiretas. Mantenha restritos os privilégios da base de dados e o sandbox.

3. Utilizador de base de dados só de leitura para o agente. Crie um utilizador separado para o agente, sem permissões DROP, TRUNCATE ou 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;

Quando o agente precisar realmente de escrever, mude manualmente para outro utilizador. Um utilizador só de leitura é suficiente para as tarefas diárias (análise de dados, relatórios, dashboards).

4. Guarde no Git as alterações revistas. Um hook PostToolUse em .claude/settings.json pode mostrar um lembrete após Write e Edit:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "printf '%s\\n' 'Reveja o diff e crie manualmente um commit apenas com os ficheiros acordados.' >&2"
          }
        ]
      }
    ]
  }
}

Este exemplo mostra apenas um lembrete; não adiciona ficheiros à área de preparação nem cria commits. Reveja o diff e crie manualmente um commit apenas com os ficheiros acordados. O reflog não guarda alterações que não tenham sido incluídas num commit.

5. Projeto sandbox para experiências. Nunca deixe o agente trabalhar num projeto que contenha dados reais de clientes. Crie uma pasta separada ~/sandbox-projects/, com uma cópia do projeto e dados sintéticos. Use-a para experimentar uma nova instrução, um agente ou um servidor MCP. Se algo se estragar, não há consequências.

6. Snapshots do disco com restic de hora a hora.

# Instalar:
brew install restic  # macOS
sudo apt install restic  # Linux

# Criar repositório:
restic init --repo /external/backups

# Criar cópia de segurança do projeto atual:
restic --repo /external/backups backup ~/projects

# Agendar cron de hora a hora:
crontab -e
# Adicionar:
0 * * * * restic --repo /external/backups backup ~/projects

Sete dias de cópias de segurança horárias, quatro semanas de cópias diárias — e pode sempre reverter para qualquer momento do passado. É gratuito e demora 10 minutos a configurar.

7. Arquive as sessões JSONL do Claude Code. Já foi referido acima, mas fica aqui como regra separada: agende um rsync semanal de ~/.claude/projects/ para uma unidade externa. É gratuito e basta uma linha no crontab.

Hooks prontos a usar para bloquear comandos perigosos#

Integre esta entrada em .claude/settings.json sem substituir hooks existentes:

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

Crie .claude/hooks/check-risk.py com este script Python 3:

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)

O hook lê o evento JSON documentado de stdin, verifica tool_input.command ou tool_input.file_path e devolve 2 nas correspondências. Verifica Write e Edit. Teste um exemplo inofensivo permitido e um bloqueado e confirme que Python e o script configurado arrancam.

É um alarme lexical: pode falhar opções reordenadas, scripts, aliases, comandos dissimulados, outras ferramentas ou escritas indiretas e rejeitar exemplos citados inofensivos. Não altera permissões do sistema ou base de dados. Mantenha credenciais de produção fora do ambiente, uma função de base só de leitura e sandbox imposto e proteja a configuração do hook contra alterações. Consulte a referência oficial de entrada e códigos de saída.

Para uma operação excecional intencional, reveja-a e execute-a fora do agente com a conta restrita adequada. Uma variável de ambiente da shell não é interface documentada para desativar hooks, e estes não controlam comandos normais de terminal.

Quando dar permissões à IA (e quando não dar)#

A Anthropic documenta a opção --dangerously-skip-permissions (também conhecida como modo YOLO) como uma opção para «ambientes de confiança». Na realidade de 2026, é um caminho direto para o desastre. Quando um agente não tem de pedir autorização:

• Executa qualquer comando Bash sem confirmação
• Escreve ficheiros sem perguntar
• Pode invocar um subagente, que herda o modo YOLO e não há forma de o reverter

O terceiro ponto é o mais traiçoeiro. Se iniciar o agente principal em modo YOLO, os subagentes também ficam em modo YOLO e não pode substituir essa configuração. Uma instrução — e uma cascata de 10 agentes em paralelo pode fazer qualquer coisa no seu sistema.

Regra:

Alternativa — permissões precisas. Em .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/*)"
    ]
  }
}

O agente vê o que está e não está autorizado a fazer. Não tem de clicar em «sim» ou «não» sempre que isso acontece — o agente trabalha rapidamente e o perímetro fica sob o seu controlo.

A seguir: uma lista de verificação de 7 minutos para guardar nos favoritos#

Lista de verificação: «A IA apagou os dados — o que faço?»

1. Pare imediatamente o escritor destrutivo real e confirme a paragem de operações filhas ou remotas
2. Não reinicie; preserve processos alheios com ficheiros eliminados abertos
3. Registe hora e evidência dos comandos noutro dispositivo verificado
4. Copie ficheiros sobreviventes, metadados Git e registos de sessões pertinentes para esse dispositivo
5. Na cópia preservada, examine git reflog --all e recupere um commit verificado num worktree separado
6. Se o git não ajudou — git fsck --lost-found
7. Base de dados: PITR (AWS/Yandex/Supabase) ou o snapshot mais recente
8. Ficheiros: Time Machine no Mac, lsof no Linux
9. Último recurso: suporte do fornecedor + versionamento do S3
10. Após a recuperação, configure as 7 regras de prevenção deste guia

A seguir — proteção sistemática:

• Plan Mode no Claude Code — para que o agente crie um plano antes de uma operação destrutiva
• Hooks no Claude Code — modelos prontos a usar para bloquear comandos perigosos
• Como reverter alterações no Claude Code — um guia detalhado sobre /rewind, git e 5 métodos padrão de reversão
• Revisão de segurança no Claude Code — verificações regulares de segurança do código

Abra o Ailoot.