Un agente IA ha cancellato i miei dati Supabase. Cosa recupero?

Hai chiesto all'agente di ripulire qualche riga di test, o di sistemare una migrazione che non voleva passare. Ha scritto lui stesso l'SQL, l'ha eseguito contro il progetto che usa la tua app in produzione, e ti ha detto che era fatto. L'app si carica ancora. La tabella è vuota.

Quando un agente IA ha cancellato dati dal tuo database, quello che puoi recuperare era già deciso prima che partisse. I prossimi minuti decidono quanto di quello sopravvive.

Ecco il punto che quasi tutte le risposte a questa domanda sbagliano. Ti dicono di tornare indietro sul codice, o di chiedere all'agente di annullare. Nessuna delle due tocca i tuoi dati, e mentre ci provi l'unica cosa che hai ancora in mano peggiora in silenzio: quello che la tua app sta scrivendo nel database proprio adesso.

Cosa posso recuperare dopo che una IA ha cancellato i miei dati?

Quello che stava nell'ultima copia del tuo database fatta prima della cancellazione, e niente di quello che è nato dopo.

Questa è tutta la risposta, e la maggior parte si è decisa settimane fa. Qui non c'è un passaggio da periti, niente da scancellare, nessun log che aspetta dentro Supabase di essere rigiocato. Una riga tolta da un DELETE o da un DROP TABLE è sparita dal database nel momento in cui l'istruzione viene confermata. Quello che torna è una copia, e una copia o esiste o non esiste.

Quindi davanti hai due compiti. Scoprire quali copie esistono. E impedire che il divario fra la più recente e adesso costi più di quanto già costa.

Prima di tutto: ferma ciò che scrive nel database

Prima di metterti a cercare un backup, spegni tutto ciò che scrive righe nuove. Leggere non è un problema.

Le ragioni sono due, e la seconda coglie di sorpresa.

La prima è che un ripristino non è una fusione. Rimettere una copia sostituisce le tabelle che contiene con quello che quelle tabelle avevano allora, e tutto ciò che è stato scritto dopo se ne va con loro. Un cliente che si registra nell'ora che passi a leggere questo è una riga che cancellerai tu stesso, più avanti, in un passaggio che hai già deciso di fare.

La seconda è che alcune strade peggiorano mentre aspetti. Il ripristino a un momento preciso di Supabase riporta l'intero progetto a un minuto che scegli tu, quindi più l'app si allontana dall'errore, più lavoro autentico quel ritorno butta via insieme al danno.

Un'ora dietro un avviso di manutenzione costa poco. Spiegare a qualcuno che il suo ordine è stato creato e poi tolto apposta costa molto di più.

Posso chiedere all'agente di annullare?

No. Non ha mai avuto le tue righe.

L'agente ha scritto un'istruzione e il tuo database l'ha eseguita. Quello che ha adesso è la trascrizione di quella conversazione, che è una cosa diversa da una copia della tabella. Chiedigli di annullare la cancellazione e ottieni una risposta sicura di sé, dell'SQL plausibile e nessun dato.

Sul rischio conviene essere precisi, perché la richiesta sembra innocua. Rilanciare l'agente significa una seconda sessione senza sorveglianza contro un database in produzione che ha già perso qualcosa. Se decide che il modo di sistemare una tabella mancante è crearne una, adesso hai una tabella nuova e vuota dove stava la vecchia, e hai reso la perdita più difficile da descrivere a chi ti aiuterà dopo.

Toglilo dal progetto finché non sai dove sei. Lo stesso vale per la cronologia delle versioni del tuo builder: riportare il codice a stamattina ripristina le tue pagine e lascia i tuoi dati esattamente dove sono adesso, per ragioni che vale la pena capire una volta.

Dove guardare, in quest'ordine

Scendi lungo questa lista e fermati alla prima voce che esiste. È ordinata per quanti dei tuoi dati tornano indietro, che non è l'ordine di quanto sia facile.

Ogni strada che restituisce qualcosa ha lo stesso requisito, ed è quello che chiude la questione: doveva esistere prima della cancellazione. Nessuna si accende adesso e arriva all'indietro. Il piano Supabase che hai decide le prime due, e controllarlo richiede circa due minuti.

Cosa torna, e cosa cade nel divario

La copia, com'era, e niente di quello che è successo dopo.

Le righe create fra quella copia e la cancellazione non sono danneggiate e non si nascondono in qualche angolo scomodo. Non sono mai state scritte da nessuna parte se non nel database da cui sono state tolte. È la parte difficile da accettare davanti a una tabella vuota, perché di solito perdere qualcosa vuol dire che quel qualcosa è ancora da qualche parte.

Quanto è larga quella fascia dipende interamente da cosa stava facendo le copie. Un backup notturno può metterci dentro un'intera giornata di lavoro. Il ripristino a un momento preciso la stringe a un minuto, ed è quasi tutto il motivo per cui costa a parte. Un dump che hai lanciato il giorno in cui ci hai pensato ci mette dentro tutto il tempo passato da allora.

Esiste una versione di questa storia in cui il divario pesa appena, su un'app i cui dati sono soprattutto contenuti tuoi e cambiano lentamente. E ne esiste una in cui pesa moltissimo: qualsiasi cosa con ordini, messaggi o registrazioni, dove una giornata di righe è una giornata di persone che se ne accorgeranno.

L'agente ne ha cancellato una parte, non tutto

Allora hai una scelta vera da fare, e nessuna delle due risposte è pulita.

Un ripristino non rimette le righe mancanti lasciando in pace il resto. Sostituisce le tabelle della copia con quello che quelle tabelle avevano allora, per intero. Ripristinare riporta quello che l'agente ha tolto e annulla ogni riga buona scritta da allora. Non ripristinare tiene le righe buone e lascia il buco.

Quale sia giusta dipende da quanto lavoro autentico sta dopo la copia. Se la risposta è quasi niente, ripristina e vai avanti con la tua giornata. Se la risposta è tre giorni di schede clienti, di solito vince la strada lenta: esportare prima le righe sopravvissute, ripristinare, poi rimettere sopra le righe esportate. È noioso, ed è l'unico percorso che non perde niente.

È anche l'argomento per copiare il database nel suo stato rotto attuale prima di toccare qualsiasi cosa. Comunque tu decida, vuoi poter tornare allo stato da cui sei partito.

Come va la stessa ora quando una copia esiste già

Più corta, e più una decisione che una ricerca. Scegli una copia, guardi cosa conteneva e premi il pulsante.

È quello che fa Reeve Care: copie verificate del tuo database Supabase secondo un calendario, cifrate e tenute fuori dal tuo account Supabase, con dietro un ripristino in un clic. Prima che un ripristino parta, prende una copia fresca dello stato attuale, così anche il ripristino si può annullare.

I limiti stanno nella stessa frase, perché conoscerli è il modo di decidere se ti serve:

• Copia il tuo database, e i file che i tuoi utenti hanno caricato appena colleghi i tuoi bucket Storage. È facoltativo e richiede una seconda chiave.
• Oggi funziona con Supabase e con nient'altro.
• Ripristini a una copia che esiste, non a un minuto qualsiasi che nomini tu. Nel caso peggiore perdi un intervallo, cioè fino a una notte sul piano di ingresso e meno sui due sopra.
• Gli account di accesso non vengono mai toccati. Nessuno viene disconnesso, cancellato o riportato indietro.
• La chiave del database che conserva sa solo leggere, ed era la promessa quando l'hai collegata. Riscrivere dati richiede una che sappia scrivere, quindi un ripristino chiede la password del tuo database ogni volta e non ne tiene nessuna. La chiave facoltativa per i tuoi file sa scrivere, perché Supabase non ne emette una in sola lettura per Storage, e la pagina dove la consegni lo dice prima.

Cosa copre ogni piano sta sulla home page. Se preferisci non pagare per niente di tutto questo, la versione semplice della stessa protezione è un pg_dump con un calendario che rispetti davvero, tenuto in un posto che perdere il tuo account Supabase non si porterebbe via. Le tre strade e cosa sfugge a ciascuna le passa in rassegna senza discorso di vendita.

Quell'ora è illustrata, copia dopo copia, nella pagina dei backup Supabase.

Cosa fare adesso

Prima di chiudere questa scheda, apri il tuo progetto Supabase e scopri se qualcosa sta copiando il tuo database, poi annota dove vive quella copia. La checklist di sicurezza in 10 minuti lo copre insieme al resto di quello che vale la pena confermare su un'app appena lanciata.