Il database ha perso i dati: backup e migration spiegati senza piangere

La paura primordiale del freelancer

Sono le 4 del pomeriggio. Hai mandato in produzione una migration. Refresh della dashboard del cliente e vedi: 0 utenti, 0 ordini, 0 prodotti. Un secondo prima erano 4.200.

Tre cose possono essere successe. Per ognuna, c'è una strategia di backup che ti salva.

Scenario 1 — Migration sbagliata

Hai fatto drizzle-kit push o prisma migrate deploy con uno schema che dropava una tabella. Il framework non ti ha avvisato. La tabella è andata.

Strategia di backup:

• Mai usare db push in produzione: solo migrate con file SQL versionati.
• Su Supabase/Neon: snapshot manuale prima di ogni migration importante. Sono 30 secondi.
• Su Postgres self-hosted: pg_dump automatico ogni notte + retention 30 giorni.

Scenario 2 — DELETE senza WHERE

Hai aperto un client SQL, scritto DELETE FROM users WHERE email = 'test@x.com', hai cancellato il WHERE per editarlo, hai premuto invio per sbaglio. Tutti gli utenti cancellati.

Strategia di backup:

• Soft delete sempre: invece di DELETE, usa UPDATE ... SET deleted_at = NOW(). Recuperabile in 1 secondo.
• Backup giornaliero point-in-time. Su Neon è incluso, su Supabase è incluso nel piano Pro.
• In SQL client: configura "Read-only mode" per la connessione di produzione. Per scrivere devi disattivarlo esplicitamente.

Scenario 3 — Il provider ha avuto un downtime

Supabase/Neon sono down per 4 ore. Tu non hai backup esterni. Il cliente ti chiama.

Strategia di backup:

• Backup off-site settimanale su S3/Backblaze. Sono 2€ al mese.
• Cron job pg_dump | gzip | aws s3 cp - su un VPS Aruba qualsiasi.
• Test di restore mensile. Un backup mai testato non è un backup.

La regola d'oro: 3-2-1

3 copie dei dati (produzione + 2 backup), su 2 sistemi diversi (DB + cloud storage), 1 copia off-site (in una region/provider differente).

Come parlarne a Claude