L’IA ha cancellato il database: un piano di recupero di 7 minuti

Le informazioni pratiche su come lavorare con Ailoot sono disponibili nella documentazione.

Cosa fare nel primo minuto: FERMA, niente panico#

Quando succede, la prima cosa da fare è fermare l’agente. Non cercare di annullare da solo le sue azioni, non dirgli di «ripristinare tutto» e non eseguire nuovi prompt. Ogni azione successiva dell’agente potrebbe sovrascrivere i blocchi del disco in cui i tuoi dati potrebbero essere ancora memorizzati.

1. Chiudi il terminale dell’agente

   Interrompi subito il comando pericoloso con Ctrl+C senza aspettare che finisca la cancellazione. Fermare l’agente non ferma necessariamente figli, job remoti o query. Identifica chi scrive e interrompi o annulla quell’operazione, aumentando il livello di terminazione se continua a distruggere dati. Mantieni attivi i processi estranei con file aperti recuperabili.

2. NON riavviare il laptop

   I dati cancellati possono essere recuperabili, ma dipende da storage, database, discard/TRIM e scritture successive. Riduci le scritture sul volume interessato senza presumere che i byte esistano ancora.

3. NON chiudere i processi aperti

   Conserva i processi estranei che tengono aperti file cancellati: il recupero attraverso i descrittori può essere possibile. Non vale per chi sta distruggendo dati, che va fermato per primo. Non mantenere una cancellazione attiva solo per conservare un descrittore.

4. Avvia la registrazione dello schermo

   Registra ora esatta, percorsi interessati e output visibile. Salva registrazioni o log su un dispositivo separato verificato, non sul volume danneggiato. Conserva su quel dispositivo file tracciati, non tracciati, ignorati e metadati Git sopravvissuti prima del recupero.

Poi hai 6 minuti per recuperare. Andiamo.

Minuti 2–3: documenta esattamente cosa è andato storto#

Apri una nuova finestra del terminale. Non quella in cui è in esecuzione l’agente: un’altra. Esegui questi tre comandi in sequenza.

1. Registra esattamente cosa è cambiato nel repository git:

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

Un file tracciato cancellato può essere nell’indice o in un commit. Prima di ripristinare conserva l’albero attuale, inclusi file non tracciati e ignorati: il ripristino sul posto può sovrascrivere modifiche sopravvissute. Esamina e recupera in una copia separata.

2. Controlla quali processi dell’agente sono in esecuzione:

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

Identifica il processo che sta ancora scrivendo pericolosamente: il solo nome non basta. Fermalo e verifica l’arresto. Conserva processi estranei con file aperti utili; se la terminazione ordinaria fallisce e la distruzione continua, può servire forzarla.

3. Salva il registro della sessione dell’agente:

Claude Code salva le sessioni JSONL in ~/.claude/projects/. Cursor le salva in ~/.cursor/. Fanne subito una copia:

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

Sostituisci /external/incident-evidence/ con una directory di prove esistente su un dispositivo montato separato e verificato. Non scrivere il backup sul volume interessato né sovrascrivere prove esistenti. Questa cartella contiene la conversazione integrale con l’agente: i comandi che ha eseguito, le sue risposte e l’ordine in cui sono avvenute. È la fonte principale per indagare sull’incidente e potenzialmente recuperare i file cancellati dal contesto dell’agente (vedi il passaggio 4).

Minuto 4: git reflog, la tua migliore possibilità#

Reflog registra movimenti locali dei riferimenti finché le voci sono conservate. Scadenza e pulizia variano e gli oggetti irraggiungibili possono essere rimossi: non è un archivio garantito di ogni commit passato. Esegui il recupero dalla copia conservata sul dispositivo separato.

Passaggio 1. Visualizza il registro:

git reflog --all

Vedrai un elenco simile a questo:

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

Cerca il punto precedente al danno causato dall’agente. Ogni voce è uno «snapshot» dello stato del repository in quel momento.

Passaggio 2. Recupera in un albero separato:

Dopo aver copiato repository e lavoro sopravvissuto su un dispositivo separato, esegui dalla copia conservata. Sostituisci il valore con lo SHA esatto verificato in reflog e scegli branch e destinazione inutilizzati:

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

Esamina i file in ../recovery-check e confrontali con quelli non registrati conservati prima di riportare dati indietro. Il comando estrae quel commit separatamente senza resettare l’albero danneggiato. I worktree collegati condividono gli oggetti Git della copia: è un workspace di recupero, non un backup indipendente. Consulta la documentazione ufficiale git-worktree.

Se anche reflog è stato ripulito (l’agente è riuscito a eseguire git gc):

git fsck --lost-found

Questo comando trova i commit e i blob (oggetti file) «perduti» che non sono più collegati ad alcun branch. Compariranno in .git/lost-found/commit/ e .git/lost-found/other/. Per ripristinare un file da lì:

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

Quando git reflog NON è utile:

• Il file era solo nell’albero di lavoro, senza commit né stash → reflog non può trovarlo
• Sono passati più di 90 giorni (il valore standard di gc.reflogExpire) ed è stato eseguito git gc
• L’intero repository è stato cancellato (rm -rf .git): in questo caso serve Time Machine o uno snapshot

Minuto 5: ripristina il database da un backup#

Il database è stato cancellato con DROP DATABASE, DROP TABLE o DELETE FROM ... WHERE ... (senza clausola WHERE). Cosa dovresti fare?

Passaggio 1. Scopri se il tuo provider offre PITR:

Passaggio 2. Ripristina su una nuova istanza, non su quella vecchia:

Non ripristinare mai sopra un database attivo. Crea una nuova istanza dal backup, poi reindirizza l’applicazione su di essa. Se qualcosa va storto, puoi reindirizzare di nuovo il DNS.

Passaggio 3. Se PITR non era abilitato, usa lo snapshot più recente:

# AWS RDS, elenca gli snapshot:
aws rds describe-db-snapshots --db-instance-identifier my-db

# Ripristina da uno 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

Nota su Supabase, che ha colto molti di sorpresa nel 2026: quando PITR è abilitato, i backup giornalieri smettono di essere creati. Un comportamento controintuitivo: potresti ritrovarti senza alcun backup. Controlla Dashboard → Database → Backups per assicurarti che PITR sia attivo E che ci sia uno snapshot da ripristinare.

Minuto 6: Time Machine, lsof e snapshot del disco#

macOS—Time Machine:

# Elenca gli snapshot:
tmutil listbackups

# Ripristina un file dall’ultimo backup:
tmutil restore /Volumes/Backup/.../my-project/file.tsx ~/projects/my-project/file.tsx

Time Machine crea snapshot ogni ora, conserva quelli orari per un giorno, quelli giornalieri per una settimana e quelli settimanali a tempo indeterminato. Se il laptop è collegato a una Time Capsule o a un’unità esterna, il tuo progetto è disponibile con granularità oraria.

Linux—il file è stato cancellato, ma un processo lo tiene ancora aperto:

# Trova tutti i file «cancellati» che un processo tiene ancora aperti:
sudo lsof | grep deleted

# Vedrai righe simili a questa:
# node 12345 user 24w REG 8,1 4096 1234567 /path/to/deleted/file.txt (deleted)

# Copia il file direttamente da /proc/PID/fd/N:
sudo cp /proc/12345/fd/24 ~/recovered-file.txt

La probabilità di successo è ~95% se il processo non è stato chiuso. Funziona su ext4, xfs, btrfs.

macOS—equivalente con lsof:

lsof | grep deleted

Copiare il file è più difficile (non c’è /proc/), ma puoi farlo con lldb:

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

Snapshot dell’intero disco (Linux, ultima risorsa):

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

Questo salva l’intera partizione in un’immagine. Poi recupera i dati con extundelete o photorec. La probabilità di recupero dipende da quanto è stato scritto sul disco dopo la cancellazione. Se non è stato scritto nulla, è dell’80–90%. Se il sistema è già in funzione da un’ora, è del 20–30%.

Minuto 7: cosa fare se non hai backup#

Opzione 1—assistenza del provider:

AWS, Yandex Cloud, Google Cloud e DigitalOcean recuperano periodicamente dati dal proprio storage interno, anche dopo un disastro lato cliente, soprattutto con i piani a pagamento. Apri un ticket di assistenza, indica l’ora esatta dell’incidente e allega screenshot dello stato. Questo funziona più spesso con i grandi provider che conservano backup automatici. La probabilità è del 40–60%; la finestra di risposta è di 24–72 ore.

Opzione 2—versionamento S3:

Se i file erano in S3 (o Yandex Object Storage) e il versionamento era abilitato, tutte le versioni esistono fisicamente; sono semplicemente contrassegnate come «cancellate».

# AWS—elenca le versioni:
aws s3api list-object-versions --bucket my-bucket --prefix files/

# Ripristina una versione:
aws s3api copy-object \
  --bucket my-bucket \
  --copy-source my-bucket/files/data.json?versionId=ABC123 \
  --key files/data.json

Avvertenza fondamentale: Claude Code non conserva le sessioni per sempre: i vecchi file JSONL vengono eliminati automaticamente dopo alcune settimane. Per assicurarti di avere un mese di cronologia JSONL in caso di disastro, copia ~/.claude/projects/ su un’unità esterna una volta alla settimana con un semplice processo cron:

# In crontab, ogni domenica alle 03:00:
0 3 * * 0 rsync -av ~/.claude/projects/ /external/claude-history-backup/

È gratuito e ti salva quando «è tutto sparito, non c’è alcun backup e reflog è vuoto».

7 regole per assicurarti che non succeda mai più#

1. Plan Mode prima di qualsiasi operazione distruttiva. In Claude Code:

claude --plan

L’agente prepara un piano prima di agire. Lo leggi, vedi DROP TABLE users e annulli. Senza Plan Mode, l’agente decide da solo ed esegue in millisecondi. Scopri di più nella guida a Plan Mode in Claude Code.

2. Hook come controllo aggiuntivo. Usa PreToolUse verificato che legge JSON da stdin ed esce con 2 per un’azione ad alto rischio rilevata. L’esempio completo sotto copre Bash, Write ed Edit: non è un confine di sicurezza e può perdere operazioni indirette. Mantieni ristretti privilegi database e sandbox.

Avvertenza fondamentale: gli hook con exit code 1 NON bloccano l’esecuzione. Serve esattamente exit 2 oppure JSON con permissionDecision: "deny". È documentato nella documentazione ufficiale degli hook, ma il 90% degli esempi online usa exit 1 e non funziona.

Scopri di più sulla configurazione nella guida 2026 agli hook di Claude Code.

3. Utente DB in sola lettura per l’agente. Crea un utente separato per l’agente che non disponga dei permessi DROP, TRUNCATE o 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 l’agente deve davvero scrivere, passa manualmente a un utente diverso. Un utente in sola lettura è sufficiente per le attività quotidiane (analisi dei dati, report, dashboard).

4. Salva in Git le modifiche verificate. Un hook PostToolUse in .claude/settings.json può mostrare un promemoria dopo Write ed Edit:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "printf '%s\\n' 'Controlla il diff e crea manualmente un commit solo con i file concordati.' >&2"
          }
        ]
      }
    ]
  }
}

Questo esempio mostra solo un promemoria; non aggiunge file allo staging e non crea commit. Controlla il diff e crea manualmente un commit solo con i file concordati. Il reflog non salva le modifiche non registrate in un commit e non sostituisce un backup indipendente.

5. Progetto sandbox per gli esperimenti. Non lasciare mai che l’agente lavori in un progetto con dati reali dei clienti. Crea una cartella separata ~/sandbox-projects/ con una copia del progetto e dati sintetici. Usala per provare un nuovo prompt, agente o server MCP. Se qualcosa si rompe, non ci saranno conseguenze.

6. Snapshot del disco con restic ogni ora.

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

# Crea il repository:
restic init --repo /external/backups

# Esegui il backup del progetto corrente:
restic --repo /external/backups backup ~/projects

# Pianifica cron ogni ora:
crontab -e
# Aggiungi:
0 * * * * restic --repo /external/backups backup ~/projects

Sette giorni di backup orari, quattro settimane di backup giornalieri, e puoi sempre tornare a qualsiasi momento del passato. È gratuito e richiede 10 minuti per la configurazione.

7. Archivia le sessioni JSONL di Claude Code. Ne abbiamo già parlato sopra, ma lo ripetiamo come regola separata: pianifica un rsync settimanale di ~/.claude/projects/ su un’unità esterna. È gratuito e basta una riga in crontab.

Hook già pronti per bloccare i comandi pericolosi#

Unisci questa voce a .claude/settings.json senza sostituire gli hook esistenti:

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

Crea .claude/hooks/check-risk.py con questo 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)

Legge l’evento documentato da stdin, controlla tool_input.command o tool_input.file_path ed esce con 2 in caso di corrispondenza. Copre Write ed Edit. Prima di fidarti, prova fixture innocue consentite e bloccate e verifica avvio di Python e script.

È un controllo lessicale: può perdere flag riordinati, script, alias, offuscamento, altri strumenti e scritture indirette, oppure bloccare innocui esempi tra virgolette. Non concede o rimuove permessi OS/database. Conserva credenziali di produzione fuori dall’ambiente, usa un ruolo database di sola lettura e sandbox forzata e proteggi la configurazione dell’hook. Consulta il riferimento ufficiale di input e codici.

Per un’operazione eccezionale intenzionale, rivedila ed eseguila fuori dall’agente con l’account ristretto appropriato. Una variabile shell non è un’interfaccia documentata per disabilitare gli hook, che non governano i comandi ordinari del terminale.

Quando concedere permessi all’IA (e quando no)#

Anthropic descrive il flag --dangerously-skip-permissions (noto anche come modalità YOLO) come un’opzione per «ambienti fidati». Nella realtà del 2026, è una via diretta al disastro. Quando un agente non deve chiedere, può:

• Eseguire qualsiasi comando Bash senza conferma
• Scrivere file senza chiedere
• Richiamare un subagente, che eredita YOLO senza possibilità di annullarlo

Il terzo punto è il più insidioso. Se avvii l’agente principale con YOLO, anche i suoi subagenti sono in modalità YOLO e non puoi sovrascrivere questa impostazione. Un solo prompt e una cascata di 10 agenti paralleli può fare qualsiasi cosa al tuo sistema.

Regola:

Alternativa: permessi precisi. In .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/*)"
    ]
  }
}

L’agente vede cosa è consentito e cosa no. Non devi fare clic su «sì» o «no» ogni volta: l’agente lavora rapidamente e tu controlli il perimetro.

Prossimo: una lista di controllo di 7 minuti da salvare#

Lista di controllo: «L’IA ha cancellato i dati: cosa faccio?»

1. Ferma immediatamente chi sta distruggendo i dati e verifica l’arresto di figli e operazioni remote
2. Non riavviare; conserva i processi estranei che tengono aperti file cancellati
3. Registra ora dell’incidente e prove dei comandi su un dispositivo separato verificato
4. Copia file sopravvissuti, metadati Git e log pertinenti su quel dispositivo separato
5. Nella copia conservata esamina git reflog --all e recupera un commit verificato in un worktree separato
6. Se git non è stato d’aiuto: git fsck --lost-found
7. Database: PITR (AWS/Yandex/Supabase) o snapshot più recente
8. File: Time Machine su Mac, lsof su Linux
9. Ultima risorsa: assistenza del provider + versionamento S3
10. Dopo il recupero, configura le 7 regole preventive di questa guida

Prossimo passo: protezione sistematica:

• Plan Mode in Claude Code: così l’agente prepara un piano prima di un’operazione distruttiva
• Hook in Claude Code: modelli pronti all’uso per bloccare i comandi pericolosi
• Come annullare le modifiche in Claude Code: guida dettagliata a /rewind, a git e ai 5 metodi standard di rollback
• Revisione della sicurezza in Claude Code: controlli regolari della sicurezza del codice

Apri Ailoot.