Supabase storage backup: la copia del database non ha nessun file

Hai impostato i backup per la tua app Lovable o Bolt, o paghi il piano Supabase che li esegue, e la parola ha fatto il suo lavoro: hai smesso di preoccuparti. Poi un ripristino, o un trasloco in un progetto nuovo, e la app torna con una immagine rotta dove prima c'era ogni foto profilo. Ogni tabella e ogni riga ci sono. Le foto no, e con loro ogni fattura, ogni export e ogni allegato che un utente abbia mai caricato.

Ecco la parte che la parola backup nasconde: un Supabase storage backup è un lavoro a parte, perché un backup del database contiene una riga per ogni file che i tuoi utenti hanno caricato e nessuno dei file. La riga è nel tuo database. Il file è in Storage, un servizio separato, e nessuna copia del database, su nessun piano, ci entra. Questo articolo spiega come prendere quella seconda copia, e in che ordine le due metà tornano indietro, che è la parte che va storta anche quando le hai entrambe.

Aiuta pensare a una biblioteca. Il catalogo è un cassetto di schede, una per ogni libro, e ciascuna dice su quale scaffale sta il libro. I libri stanno sugli scaffali. Un backup del database copia il cassetto.

Supabase fa il backup dei miei file Storage?

No, su nessun piano. La documentazione dei backup di Supabase dice che i backup non contengono i file salvati attraverso la Storage API, solo i loro metadati nel database, e il point-in-time recovery è una funzione del database, quindi la stessa frase copre anche quello.

Quello che ogni backup contiene davvero è la lista. Supabase tiene nel tuo database Postgres una tabella chiamata storage.objects, con una riga per file in ogni bucket: in quale bucket sta, il suo percorso, chi lo ha caricato, quanto è grande e quando è arrivato. Quella tabella viene copiata insieme a tutto il resto, ed è esattamente per questo che un progetto ripristinato sembra così completo. Ogni scheda è nel cassetto.

I byte di ogni file stanno da un'altra parte. Vivono nello storage a oggetti, un servizio separato accanto al tuo database, e uno strumento che copia un database non lo legge mai. Il piano gratuito non esegue alcun backup automatico, quindi lì la domanda nemmeno si pone; da Pro in su la copia giornaliera ha le tue righe e nessuno dei tuoi upload.

Dove Supabase tiene i tuoi file

In due posti, e un backup del database ne raggiunge uno.

Quando un utente carica un avatar, la tua app consegna il file a Storage. Storage scrive i byte nello storage a oggetti sotto il nome del bucket e il percorso, e nella stessa operazione scrive una riga in storage.objects che lo descrive. La tua app tiene poi quel percorso in una delle sue tabelle, diciamo una riga di profiles con una colonna avatar_url, e ci costruisce un link ogni volta che serve l'immagine.

Quindi una immagine caricata è tre cose: i byte nello storage a oggetti, la riga in storage.objects che Storage mantiene, e il percorso nella tua tabella. Un backup del database porta con sé le ultime due. Ripristinalo e la tua app ha ogni percorso e Storage ha ogni riga, e il link che costruiscono insieme punta a un posto dove non c'è niente.

È anche per questo che il guasto è così silenzioso. Ogni riga concorda con ogni altra riga, ogni conteggio torna, e ogni controllo che legge il database passa, compreso il passaggio di verifica della maggior parte degli strumenti di backup, perché i file non sono mai stati dentro la cosa che veniva controllata.

Come si presenta un ripristino con solo metà

Un progetto che passa ogni controllo e mostra una immagine rotta ovunque dovrebbe comparire un file.

Il ripristino riporta un successo perché ha fatto quello che gli era stato chiesto: le tabelle sono tornate e i conteggi delle righe corrispondono. Apri la dashboard e Storage elenca ogni bucket e ogni file al suo interno, con dimensioni e date, perché quella lista viene letta dalla tabella che il ripristino ha rimesso a posto. La stessa guida di Supabase per ripristinare un backup della dashboard in un progetto nuovo descrive esattamente questo stato: i bucket e i metadati dei file compaiono, e gli oggetti dietro di loro no.

Il modo in cui lo scopri è ordinario. La pagina del team mostra una fila di icone di immagine rotta dove c'erano gli avatar. Un cliente risponde alla mail con la fattura del mese scorso per dire che il link apre un errore. Qualcuno clicca un file nel browser di Storage e il download fallisce. La scheda dice scaffale quattro, terzo da sinistra, e lo scaffale quattro è vuoto.

Niente ti avverte prima di quel momento, perché ogni avviso che hai è collegato al database. Come ripristinare un backup Supabase passa in rassegna i cinque modi in cui un ripristino torna rotto, e i file sono la riga di quella tabella senza rimedio, a meno che tu non ne abbia fatto una copia.

Già che hai aperta la pagina di Storage, vale la pena sapere cosa mostra a uno sconosciuto. La nostra scansione gratuita legge la tua app dal vivo, dall'esterno, e chiede a ogni bucket la sua lista di file usando nient'altro che la chiave già presente nel codice della tua app. Nell'agosto 2026 ha ottenuto una lista da 792 delle 27.269 app che ha potuto controllare, una cifra della nostra ricerca. Legge nomi e non scarica mai un file, richiede circa 20 secondi e non serve nessun account: scansiona la tua app.

Come faccio il backup di un bucket Supabase Storage?

Attraverso l'endpoint compatibile S3, con un solo comando che copia un bucket intero in una cartella che tieni tu.

Supabase Storage parla il protocollo S3, il che significa che gli strumenti ordinari costruiti per lo storage di Amazon funzionano con il tuo. Questo è l'unico passaggio di questo articolo che avviene su una riga di comando, e vale la pena farlo una volta a mano, così sai di cosa è fatta la copia.

1. Nella tua dashboard Supabase, apri le impostazioni di Storage e attiva il protocollo S3. La stessa pagina mostra l'URL dell'endpoint e la regione del tuo progetto; copiali da lì e non da qui.
2. Su quella pagina, crea una coppia di chiavi di accesso S3. Il segreto viene mostrato una sola volta, quindi mettilo in un gestore di password prima di chiudere la finestra.
3. Installa la riga di comando AWS, dalle le due chiavi come profilo, ed esegui una sincronizzazione per bucket:

aws s3 sync s3://avatars ./supabase-files/avatars \
  --endpoint-url https://<project-ref>.storage.supabase.co/storage/v1/s3 \
  --region <region>

Eseguilo di nuovo domani e copierà solo quello che è cambiato. rclone fa lo stesso lavoro se lo preferisci; su un bucket grande, la nota di risoluzione dei problemi di Supabase dice di passare --s3-list-version 2, altrimenti l'elenco può fermarsi in anticipo.

Due cose su quella chiave. La pagina di autenticazione S3 di Supabase dice che una chiave di accesso S3 ha accesso completo a ogni bucket e aggira Row Level Security, quindi il suo posto è un server o la tua macchina, e mai la tua app. E può scrivere oltre che leggere, perché Supabase non emette nessuna chiave di sola lettura per Storage; chiunque la tenga può cancellare file con la stessa facilità con cui li copia. Trattala come tratteresti la tua chiave service_role.

Poi metti la cartella da qualche parte fuori dal tuo account Supabase, per la stessa ragione per cui una copia del database dovrebbe vivere fuori: un progetto sospeso o un accesso perduto si porta via ogni copia conservata dentro quell'account.

Prima i file, o prima le righe?

Prima il database, poi i file, e i file tornano attraverso Storage in modo che sia Storage a scrivere le righe.

Ogni upload che passa da Storage, dalla tua app, dall'endpoint S3 o dalla CLI di Supabase, fa due cose in una sola operazione: salva i byte e scrive la riga di storage.objects che li descrive. Il libro viene messo sullo scaffale e la scheda la scrive la stessa mano. Rimetti i file per quella strada e le righe arrivano con loro, e le due cose non possono divergere.

L'altra direzione non ha nessun meccanismo del genere. Ricopiare le righe di storage.objects con uno strumento per database scrive schede e non mette niente sugli scaffali. Complica anche il passaggio successivo: per impostazione predefinita Storage rifiuta un upload verso un percorso che ha già una riga, con un errore che dice che la risorsa esiste già, e la guida agli upload di Supabase dice che lo si supera attivando la sovrascrittura. Quindi quando il ripristino del database ha già riportato le righe, che è quello che la stessa guida di migrazione di Supabase ti fa fare, la copia dei file che segue deve poter sovrascrivere.

L'ordine, quindi:

1. Ripristina il database, come descrive quell'articolo.
2. Ricopia i file attraverso Storage, con aws s3 sync eseguito al contrario (prima la cartella, poi il bucket) o con supabase storage cp -r, e con la sovrascrittura attiva. Un bucket che non esiste più va creato prima, con lo stesso nome e la stessa impostazione pubblica.
3. Apri un file, e poi parecchi altri.

La versione più pulita di tutto questo salta del tutto la riproduzione di storage.objects nel passaggio del database e lascia che gli upload scrivano ogni riga da zero, così non c'è mai niente da sovrascrivere. È così che fa il nostro ripristino. Richiede di filtrare la copia prima di riprodurla, che è un passaggio per lo strumento che esegue il ripristino.

Come verificare di avere entrambe le cose

Aprendo file, perché ogni lista che puoi tirare fuori viene letta dalla tabella.

Il browser dei file della dashboard, una query su storage.objects e il conteggio delle righe in un report di backup descrivono tutti il cassetto, e dopo un ripristino del solo database il cassetto è perfetto. L'unica richiesta che tocca lo scaffale è una richiesta del file stesso.

Quindi dopo un ripristino, e dopo la prima copia che fai, apri dei file. Prendine una manciata da ogni bucket, compresi i più vecchi, e aprili attraverso la app come farebbe un utente. Un file che si apre è tornato. Un file che dà errore non c'è mai stato, qualunque cosa dica la lista.

Cosa fare questa settimana

Dove si colloca Reeve Care

Care copia i file insieme al database, nell'ordine che questo articolo descrive, e li rimette a posto allo stesso modo.

• Anche i file caricati dai tuoi utenti vengono copiati, non appena colleghi i bucket Storage della tua app Supabase. È una seconda chiave, chiesta a parte, perché la chiave che Supabase emette per Storage può scrivere oltre che leggere, e preferiamo chiederla piuttosto che fonderla con la chiave del database, che non può.
• La copia dei file parte dopo che la copia del database è stata riletta e verificata, mai in parallelo, così un punto di ripristino non rivendica mai file che non ha copiato. Una copia rimasta senza tempo viene segnata come parziale, con i conteggi reali.
• Ogni punto di ripristino registra quale percorso conteneva quale file. Un database riportato a martedì riceve i file di martedì, e un file ancora al suo posto viene lasciato in pace.
• Il ripristino rimette i file attraverso Storage, così ogni riga viene scritta dall'upload che porta il file. Niente di ciò che esiste oggi viene sovrascritto o cancellato, il che significa che premere il pulsante nel panico non può distruggere la cosa che stavi cercando di salvare.
• Il ripristino è un pulsante, e scatta una istantanea dello stato attuale prima di partire, così il ripristino stesso ha un annulla.

Care parte da €49 al mese per una app. È un prezzo di listino, e la pagina dei prezzi a volte sta sotto la cifra qui e mai sopra.

Come una copia viene fatta, controllata e rimessa a posto, file compresi, è disegnato passo per passo sulla pagina dei backup Supabase.

Prima di chiudere questa scheda, apri Storage nella tua dashboard e conta i bucket. Ognuno è un insieme di file che nessun backup eseguito da Supabase conterrà mai, e il comando di sincronizzazione qui sopra è tutto quello che serve per cambiare le cose. Se un bucket è risultato anche elencabile, cosa ottiene uno sconosciuto da quella lista è la prossima cosa da leggere.