Perché nel tuo dump Supabase non ci sono utenti

Hai fatto la cosa giusta. Hai cercato come fare il backup di un database Supabase, hai lanciato il comando che hai trovato e hai messo il file in un posto sicuro.

Poi un giorno ti serve. Rigiochi il file in un progetto nuovo e il ripristino finisce senza un solo errore. Ogni tabella che hai mai creato è lì, e ognuna di esse è vuota. I tuoi utenti stanno anche peggio: la parte del database in cui vivono, uno schema chiamato auth, non ha mai raggiunto il file.

Ecco la parte che quasi ogni guida salta: supabase db dump da solo non è una copia dei tuoi dati. Senza altri flag scrive la forma del tuo database e niente del suo contenuto, e auth lo lascia fuori perfino da quello. Supabase pubblica il backup come tre comandi, e i tuoi account viaggiano nel terzo.

Aiuta pensare a un albergo. Le tue tabelle sono le stanze e tutto quello che ci sta dentro. Il registro alla reception, quello con il nome di ogni ospite, è dell'albergo. E una pianta ti mostra ogni stanza dell'edificio senza metterci dentro un solo ospite.

Un backup di Supabase contiene i miei utenti?

Dipende da quale comando ha scritto il file, e il comando che lanciano quasi tutti non li contiene.

I tuoi utenti non sono righe di una delle tue tabelle. Supabase li tiene in un cassetto a parte dello stesso database, lo schema auth, insieme alle loro password hashate, ai provider con cui hanno fatto accesso e alle sessioni che hanno aperte. Le tue tabelle stanno in un cassetto chiamato public, e ogni colonna user_id che c'è dentro è un riferimento verso auth.

Uno schema è esattamente questo: un cassetto con un nome dentro un database. public è tuo. auth è di Supabase, e lo è anche storage, che tiene la riga che descrive ogni file caricato. La documentazione di Supabase chiama questi i suoi schemi gestiti e dice che di norma non serve scaricarli a meno che tu non li abbia modificati, ed è il motivo per cui gli strumenti li trattano diversamente dalle tue tabelle.

Questa divisione è ciò che permette a un comando di produrre due file che si somigliano e contengono cose del tutto diverse.

Cosa scrive il comando di dump da solo

La pianta. Nessuna riga, e niente da auth.

La pagina di riferimento di Supabase per il comando lo dice in due frasi. Lancia pg_dump con flag aggiuntivi per escludere gli schemi gestiti da Supabase, e tra quelli ignorati ci sono auth, storage e quelli creati dalle estensioni. La stessa pagina dice poi che il dump predefinito non contiene dati né ruoli personalizzati, e che li ottieni chiedendoli con --data-only e --role-only.

Quindi questo, che è quello che hai probabilmente lanciato:

supabase db dump --db-url "postgresql://…your connection string…" -f backup.sql

produce un file pieno di istruzioni CREATE TABLE. Ogni colonna, ogni indice, ogni policy che hai scritto sulle tue tabelle, e nemmeno una riga di niente.

Il motivo per cui questo è peggio di un file palesemente vuoto è che funziona. Non sembra nemmeno piccolo: ogni definizione di tabella, ogni indice e ogni policy che hai mai scritto stanno lì dentro, e per una app vera è un sacco di testo. Un backup vuoto si annuncia da solo. Questo si ripristina pulito, e la prima cosa che ti dice il contrario è una pagina di accesso che nessun account riesce a superare.

Come controllo il dump che ho già?

Aprilo in un editor di testo e cerca auth. Quello che salta fuori mette il tuo file in uno di tre gruppi.

1. Nessuna corrispondenza. Lo schema auth non è in questo file in nessuna forma. È quello che scrive un supabase db dump nudo.
2. Corrispondenze, ma solo in righe che iniziano con CREATE, ALTER o GRANT. Hai il disegno del registro e nessuno dentro.
3. Una riga COPY "auth"."users" oppure COPY auth.users, con righe di dati sotto fino a una riga che contiene \. Oppure una sequenza di righe che iniziano con INSERT INTO "auth"."users". I tuoi account ci sono.

Se preferisci farlo da riga di comando, due grep rispondono alla stessa domanda:

grep -c 'auth.*users' backup.sql
grep -n 'COPY .*auth.*users\|INSERT INTO .*auth.*users' backup.sql

Il primo dice se lo schema ha raggiunto il file. Il secondo dice se ci sono arrivate le persone. Uno zero da entrambi, su un file su cui contavi, è meglio scoprirlo oggi che la mattina in cui ti serve.

Cerca anche storage già che ci sei, e leggi con attenzione quello che trovi. Quelle righe sono la lista dei tuoi file caricati, che è una cosa diversa dai file, e nessun backup di database su nessun piano contiene quelli.

Come esporto gli utenti auth di Supabase?

Con il comando dei dati, che è un comando diverso da quello che scrive lo schema.

La guida a backup e ripristino di Supabase pubblica il backup come tre file, e vale la pena vederli insieme perché la forma è la risposta:

supabase db dump --db-url "postgresql://…" -f roles.sql --role-only
supabase db dump --db-url "postgresql://…" -f schema.sql
supabase db dump --db-url "postgresql://…" -f data.sql --use-copy --data-only \
  -x "storage.buckets_vectors" -x "storage.vector_indexes"

La seconda riga è quella che viene lanciata da sola. La terza è quella con dentro i tuoi utenti.

Questi due fatti sembrano una contraddizione e non lo sono. La frase sulla pagina di riferimento di Supabase riguardo all'esclusione di auth descrive il dump dello schema, e il dump dei dati percorre anche quello schema.

Se vuoi solo gli account, nomina lo schema e ottieni quel cassetto da solo:

supabase db dump --db-url "postgresql://…" -f users.sql --data-only --use-copy --schema auth

Prima di fidarti di uno qualsiasi di questi, aggiungi --dry-run e leggi quello che torna. Stampa il comando pg_dump che lo strumento sta per lanciare senza lanciarlo, così vedi con i tuoi occhi quali schemi sono inclusi e quali esclusi sulla versione che hai installato. Leggi quell'output una volta e non dovrai più credere a questo articolo, né a nessun altro, il che conta perché i flag si spostano davvero tra le release e il file ha lo stesso aspetto in entrambi i casi.

C'è anche la via diretta, ed è a questo che serve un pg_dump semplice: nomina i cassetti che vuoi e se li prende.

pg_dump "postgresql://…" --schema public --schema auth --schema storage \
  --no-owner --file backup.sql

Una cosa da notare sul file di schema, perché spiega perché tutto questo è diviso. Un progetto Supabase nuovo arriva con uno schema auth già costruito, nella versione che il servizio di accesso fa girare oggi. Rigiocarci sopra la versione del tuo vecchio progetto metterebbe un disegno più vecchio sopra uno che funziona. Quello che vuoi portare dall'altra parte è il contenuto del registro, ed è quello che tiene il file di dati.

Cosa si rompe quando rimetti dentro gli utenti

Due cose, e Supabase le documenta entrambe.

I trigger, che possono cifrare una colonna due volte. Il comando di ripristino della guida di Supabase ha in mezzo un'istruzione facile da leggere come riempitivo:

psql \
  --single-transaction \
  --variable ON_ERROR_STOP=1 \
  --file roles.sql \
  --file schema.sql \
  --command 'SET session_replication_role = replica' \
  --file data.sql \
  --dbname "postgresql://…"

Quella riga in mezzo spegne i trigger per tutta la durata, e la guida dice che sta lì per impedire che le colonne vengano cifrate una seconda volta mentre entrano. Rigioca un file di dati senza di lei e le password arrivano già mescolate da un processo che era già stato applicato, e niente dopo lo disfa.

Proprietà e permessi, che fermano il rigioco. Un dump preso da un progetto Supabase porta righe che si riferiscono a ruoli che il progetto nuovo non ti lascia toccare. Le note di risoluzione dei problemi della stessa guida dicono di commentare qualsiasi riga che contenga ALTER ... OWNER TO "supabase_admin" in schema.sql, e una riga precisa GRANT "postgres" TO "cli_login_postgres" in roles.sql. Entrambe sono una modifica di testo prima di partire, ed entrambe fermano il rigioco con la riga su cui si è inceppato stampata sullo schermo.

I miei utenti devono rifare il login?

Le loro password passano. Le loro sessioni no, a meno che tu non porti con loro una cosa in più.

Supabase dice che puoi migrare ogni tabella dello schema auth, utenti e loro password hashate compresi, quindi nessuno deve reimpostare una password che aveva già. Nessuna password è leggibile in nessun momento di tutto questo; quello che si sposta è il suo hash.

Una sessione è un'altra cosa. È provata da un token firmato con il segreto JWT del tuo progetto, e ogni progetto ha il suo. Supabase dice che se il progetto nuovo firma con un altro segreto, ogni token già presente nel browser di qualcuno diventa invalido e a quella persona viene chiesto di accedere di nuovo. Puoi evitarlo mettendo il segreto del vecchio progetto su quello nuovo, e sulla stessa pagina c'è scritto il prezzo: cambiare il segreto JWT rigenera le chiavi anon e service_role di quel progetto, quindi alla tua app vanno date quelle nuove prima che possa parlare con qualcosa. Quale chiave è quale, e quale di loro può stare nella tua app, è la cosa su cui essere sicuro prima di incollarne una.

Quindi la versione onesta è che un ripristino di solito chiede a tutti di accedere una volta. Quella è una mail al supporto. Non è un account perso, e la differenza tra le due cose è se lo schema auth era nel tuo file.

Tre cose continuano a non esserci, qualunque cosa tu faccia con i flag. I tuoi file caricati, perché Storage tiene i byte fuori dal database e nessun dump su nessun piano li raggiunge. Le tue edge function, che sono un download a parte e le cui import map, nota Supabase, non vengono prese automaticamente. E le impostazioni del tuo progetto, che sono configurazione e non dati e si riscrivono a mano.

Cosa fare questa settimana

Farlo una volta a mano vale la pena comunque tu finisca per fare i backup, perché finché non hai aperto un dump hai avuto solo la parola backup. Se continuare a mano è un'altra domanda, e le tre vie e quanto costa ciascuna è il posto in cui si risponde.

Dove si colloca Reeve Care

Care prende la copia secondo un calendario, e il registro è dentro.

• I tuoi account sono nella copia. Lo schema auth viaggia con le tue tabelle, perché una copia di una app Supabase senza i suoi utenti è una copia della metà. Le righe storage che descrivono i tuoi file vengono anche loro, e i file stessi appena colleghi una credenziale Storage.
• Il pulsante di ripristino rimette le tue tabelle e lascia stare gli account. Rigiocare auth.users su un progetto vivo scollega tutti e riporta indietro account che qualcuno aveva cancellato apposta, quindi quella resta una richiesta con una persona sopra. Così premere il pulsante nel panico non può scollegare i clienti che stavi cercando di aiutare.
• La copia viene riletta prima di contare come presa. La data sulla tua dashboard è l'ultima volta che una copia è stata aperta e verificata, mai il momento in cui un lavoro è partito o un file è atterrato.
• Il ripristino prende prima un'istantanea dello stato attuale, 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 presa, controllata e rimessa è disegnato passo per passo sulla pagina dei backup Supabase.

Prima di chiudere questa scheda, apri il tuo dump più recente e cercaci dentro auth. È il modo più veloce per scoprire se quello che stavi chiamando backup ti restituirebbe i tuoi clienti, e se la risposta è no, ripristinarne uno come si deve è la prossima cosa da leggere.