La domanda ne racchiude in realtà tre, ciascuna con una risposta diversa. Una cancellazione effettuata nell’applicazione è sempre annullabile: nulla viene davvero eliminato, la riga finisce nel cestino, da cui può essere ripristinata con un semplice clic. I vostri dati escono quando volete, grazie all’export dedicato a ogni lista. Ma il database di un’applicazione deployata NON è salvato da alcun meccanismo automatico del prodotto: nella catena di deployment non è previsto alcun comando di backup, e spetta a chi la ospita, voi stessi, il vostro fornitore o noi, qualora la gestiamo noi, implementarlo. In altre parole: un clic sbagliato si risolve da solo, un database perso no. Questa pagina definisce con precisione dove passa il confine, per aiutarvi a porre le domande giuste prima di caricare dati reali.
Cancellare, nell’applicazione, non distrugge nulla
Il pulsante «Cancella» non cancella: imposta una colonna dedicata che marca la riga come eliminata. La riga scompare quindi dalle liste, dai totali e dagli indicatori, ma rimane comunque nel database. Non appena viene cancellata almeno una riga, compare una scheda «Cestino» nelle Impostazioni, con un pulsante «Ripristina». È verificabile direttamente nel codice consegnato: nessuna delle rotte generate richiama l’eliminazione definitiva dal database.
A questo si aggiunge una conferma in due passaggi, un primo clic attiva la cancellazione, un secondo la conferma, anziché la finestra di dialogo standard del browser. Il caso più frequente di tutti, ovvero il clic sbagliato alla fine della giornata, si risolve quindi in trenta secondi e senza dover chiamare nessuno. È anche l’unico dei tre livelli gestito interamente dall’applicazione in autonomia, ed è per questo che viene trattato per primo.
Estrarre i vostri dati quando volete
Ogni lista dispone di un pulsante per esportare i dati in formato CSV. L’export include esclusivamente le righe che VOI vedete, già filtrate dalla ricerca e dai filtri attivi, e l’etichetta del pulsante indica il numero esatto di righe esportate: non vengono mai trasferiti in silenzio dati che non compaiono sullo schermo. Il file è generato per aprirsi correttamente in un foglio di calcolo in italiano, senza la riga di accenti rotti che di solito affligge gli export.
Si tratta di una copia di vostra proprietà, da chiamare per quello che è: non è un backup nel senso tecnico del termine. Un file CSV non permette di ripristinare un’applicazione, non contiene né i collegamenti tra le tabelle, né la cronologia, né i dati cancellati. Serve a riprendere il controllo: aprire i vostri dati in un foglio di calcolo, inviarli al vostro commercialista, alimentare un altro strumento. È ciò che vi libera da vincoli di lock-in, non ciò che vi protegge da un guasto.
Ciò che NON viene fatto, e che dovete decidere voi
Quando la vostra applicazione viene messa in produzione, ottiene un proprio database PostgreSQL. E nella catena di deploy non è previsto alcun meccanismo di backup: il codice che esegue il deploy non contiene alcun comando di salvataggio. Non si tratta di un dimenticanza nascosta, ma di un confine ben preciso, il backup dipende infatti da dove l’applicazione gira, e quindi spetta a chi la ospita, che siate voi stessi, il vostro fornitore o noi stessi, qualora la gestiamo noi.
Tre domande bastano per superare questo confine, e vanno poste prima ancora di inserire dati reali. Chi genera la copia, e con quale frequenza? Dove viene conservata, in un luogo diverso dalla macchina che esegue l’applicazione, altrimenti un singolo guasto comprometterebbe entrambi? E soprattutto: qualcuno ha mai eseguito un RESTAURAZIONE partendo da questa copia? Quest’ultima è quella che si tende a dimenticare, ed è l’unica che dimostri qualcosa: un backup mai ripristinato non è un backup, è un’ipotesi.
Cosa cambia in base a ciò che ci inserite
Non tutto merita lo stesso livello di protezione. Per uno strumento i cui contenuti possono essere ricostruiti, ad esempio un piano settimanale o un monitoraggio leggero che si riesce a ricreare in un’ora, un export mensile archiviato da qualche parte è più che sufficiente. Per un registro invece non ricostruibile, i vostri iscritti, la cronologia degli interventi, i fascicoli in corso, il backup automatico del database è un prerequisito, non un’opzione: nessuno riscrive tre anni di storia a memoria.
La buona notizia è che non esistono ostacoli tecnici: il codice generato è Next.js e Prisma standard su database PostgreSQL, senza formati proprietari da aggirare, e il backup di un database PostgreSQL è un’operazione che qualsiasi fornitore sa eseguire. La domanda non è mai «è possibile?», ma «chi lo fa, da quanto tempo e qualcuno lo ha mai verificato?».