Reeve Backups
La cronologia delle versioni non è un backup dei tuoi dati.
Lovable e Bolt tengono una cronologia delle versioni del codice. Il tuo database è un servizio a parte, e tornare indietro non ti restituisce i dati.
In breve
- La cronologia delle versioni ripristina il codice. Non tocca mai il database, che è dove stanno i tuoi utenti, i loro contenuti e i loro ordini.
- Una tabella cancellata, una riga sovrascritta o una migrazione andata storta sopravvivono intatte a un ritorno indietro.
- Il tuo codice ha un annulla incorporato. I tuoi dati ne hanno uno solo se ce lo metti tu.
Qualcosa si è rotto, così hai fatto la cosa sensata. Hai aperto la cronologia delle versioni in Lovable o Bolt, hai cercato la versione di stamattina e hai premuto ripristina. L'app è tornata esattamente com'era.
I dati no.
Ecco il punto su cui la gente inciampa: il tuo codice e i tuoi dati sono due sistemi separati, e solo uno dei due ha un pulsante annulla. Il tuo builder conserva i disegni della tua app. Il tuo database contiene quello che ci sta dentro. La cronologia delle versioni ricostruisce i disegni alla perfezione, fino all'ultimo dettaglio, e ti restituisce un edificio identico e vuoto.
La cronologia delle versioni del builder fa il backup del mio database?
No. Salva il tuo codice, e i tuoi dati stanno da tutt'altra parte.
Lovable, Bolt, v0, Replit, Cursor e gli altri tengono tutti una cronologia dei file del progetto: le tue pagine, i tuoi componenti, la tua logica, il tuo aspetto. Quelli sono i disegni. Ripristinare una versione riscrive quei file com'erano il giorno che hai scelto.
Il tuo database è un servizio diverso, quasi sempre Supabase, su un account tutto suo. Niente nella cronologia del progetto ci entra. Il ripristino non ha un'opinione sui tuoi dati perché non riesce a vederli.
Perché codice e dati stanno in due posti diversi
Perché i tuoi dati devono sopravvivere a quello che il tuo codice fa di continuo, cioè cambiare.
Il tuo codice viene ricostruito ogni volta che pubblichi. Se gli ordini dei tuoi utenti stessero lì dentro, sparirebbero ogni volta che sistemi un pulsante. Per questo i due vengono tenuti separati, di proposito: il codice è sostituibile e i dati no, ed è per questo che a versionarli sono strumenti diversi.
Il prezzo di quella separazione è il tema di questo articolo. Ogni strumento che versiona uno dei due è cieco rispetto all'altro. Il tuo builder non può recuperare una tabella, e il tuo database non può recuperare una pagina rotta.
Cosa succede davvero quando torni indietro
Le tue schermate tornano com'erano. I tuoi dati non si spostano di un millimetro.
| Cosa | Tornando indietro con il codice |
|---|---|
| Pagine, componenti, aspetto | Ripristinato |
| La logica della tua app e le sue correzioni | Ripristinato |
| Una tabella che qualcuno ha cancellato | Resta cancellata |
| Righe sovrascritte da uno script | Restano sovrascritte |
| Una colonna tolta da una migrazione | Resta tolta |
| I file caricati dai tuoi utenti | Immutati in entrambe le direzioni |
La riga della migrazione è quella che sorprende di più. Una migrazione che hai lanciato contro il tuo database è già avvenuta: vive nel database, non nel tuo repository, e disfare il file che la descriveva non cambia nulla.
Dove morde davvero
Nei dieci minuti dopo un errore, quando vai a cercare l'annulla e scopri che non esiste.
Le forme che prende sono del tutto ordinarie:
- Una cancellazione nell'editor delle tabelle di Supabase che ha preso più righe del previsto.
- Una migrazione assistita dall'IA che ha tolto una colonna per far sparire un errore di tipo.
- Uno script di popolamento o di reset puntato sul progetto in produzione invece che su uno di prova.
- Una ripulita di quelli che sembravano dati di prova ed erano l'account vero di qualcuno.
Nessuna di queste cose tocca una sola riga del tuo codice. Ognuna sopravvive intatta a un ritorno indietro, ed è per questo che il ritorno indietro sembra non aver fatto niente. Ha fatto esattamente quello che fa.
A cosa serve davvero la cronologia delle versioni
A parecchio, e vale la pena dirlo chiaramente, perché la risposta non è «a niente».
È un annulla vero per problemi veri: un cambio di grafica di cui ti penti, una pubblicazione che ha rotto una pagina, una modifica dell'IA che ha riscritto in peggio una schermata che funzionava, una funzione che alla fine ha reso l'app più difficile da usare. Tutto questo vive nel tuo codice, e per queste cose funziona esattamente come promette.
Il problema è il presupposto silenzioso che il suo compito copra tutto. Quel presupposto non lo fa nessuno apposta: è quello con cui resti quando nessuno ti dice che i sistemi sono due.
Come ottenere un annulla vero per i tuoi dati
Devi mettercelo tu. Cioè una copia del database, presa secondo un calendario, tenuta in un posto che perdere l'account non si porterebbe via.
Ci sono tre modi di farlo, costano cifre e attenzioni diverse, e a ciascuno sfugge qualcosa che gli altri coprono. Tre modi per fare il backup di un database Supabase li percorre tutti e tre, compreso quello che quasi tutti dovrebbero attivare per primo e il motivo per cui da solo non basta.
È anche a questo che serve Reeve Care: copie programmate del tuo database Supabase, tenute fuori dal tuo account Supabase e controllate prima di contare come fatte. Collega i tuoi bucket Storage e i file caricati dai tuoi utenti viaggiano insieme, così un ripristino rimette le righe e le immagini a cui puntano.
Che cosa contiene una di quelle copie, e che cosa fa davvero il pulsante, è nella pagina dei backup Supabase.
Cosa fare questa settimana
Cosa fare
- Scopri se in questo momento qualcosa sta facendo il backup del tuo database. Non del tuo codice: del tuo database. Se la risposta ci mette più di un minuto ad arrivare, la risposta è no.
- Attiva il backup incluso nel tuo piano Supabase. Ti protegge dai tuoi stessi errori, che sono esattamente il guasto di cui parla questo articolo.
- Tieni anche una copia da un'altra parte, perché un backup che vive dentro l'account non ti aiuta se perdi l'account.
- Fai il backup dei file caricati separatamente. Non stanno né nel tuo codice né nel tuo database.
- Ripristina una copia in un progetto usa e getta, così la prima volta che leggi quel file non è il giorno in cui ti serve.
Prima di chiudere questa scheda, apri il tuo progetto Supabase e guarda se i backup sono attivi. Quel singolo controllo è tutto il lavoro di oggi. La checklist di sicurezza in 10 minuti lo copre insieme al resto di ciò che vale la pena confermare in un'app appena lanciata, e la guida alla sicurezza di Supabase ripassa cos'altro resta comunemente aperto.
FAQ
Ho cancellato una tabella per sbaglio. Posso recuperarla?
Solo da un backup fatto prima della cancellazione, quindi la prima cosa da scoprire è se ne esiste uno. Tornare indietro con il codice non basta, e nemmeno il tuo builder. Su un piano Supabase a pagamento ci sono backup giornalieri, e il ripristino a un momento preciso se lo hai aggiunto. Sul piano gratuito non c'è nulla di automatico. Controlla cosa hai prima di cambiare qualsiasi altra cosa, perché alcune strade di ritorno si complicano appena inizi a scrivere dati nuovi sopra il buco.
Lovable fa il backup del mio database Supabase?
Il tuo builder tiene le versioni dei file del progetto. Il tuo database è un servizio separato sul tuo account Supabase, e niente nella cronologia del progetto ci entra. I builder aggiungono funzioni, quindi guarda la documentazione del tuo invece di dare per scontato in un senso o nell'altro, ma parti dal presupposto che la risposta sia no finché non hai letto che è sì.
La mia cronologia Git è un backup?
No, esattamente per lo stesso motivo per cui non lo è la cronologia delle versioni. Git segue i file da cui viene costruita la tua app. Non ha mai visto una sola riga dei tuoi dati e non può rimetterne nessuna. Un repository e un database sono due cose diverse che si chiamano entrambe «il tuo progetto».
I miei dati ci sono ancora tutti. Devo fare qualcosa oggi?
Oggi è il giorno più economico in cui metterai in piedi questa cosa, perché i dati sono pochi e quello che conta è che l'abitudine esista prima che serva. Le perdite che fanno male sono raramente drammatiche: sono un comando digitato male durante una riparazione notturna, su un progetto con appena abbastanza utenti veri da rendere impossibile ricominciare da zero.