Fă backup bazei locale înainte să o modifici

O bază de date locală Supabase pare de unică folosință pentru că supabase db reset o poate reconstrui în câteva secunde. Lucrul acesta este adevărat pentru schemă și pentru datele din seed. Nu este adevărat pentru restul: rândurile inserate când vânai un bug, tabelul pe care l-ai editat în Studio marți, starea pe care un coleg a reprodus-o o dată și nu a notat-o nicăieri. Reset-ul e rapid pentru că aruncă toate acestea. Înainte de o modificare riscantă, fă un backup pe care îl poți restaura și exersează restaurarea cât timp nimic nu e stricat.

Ce face de fapt supabase db reset?

Referința CLI pentru db reset descrie comanda ca o resetare a bazei de date locale la o stare curată și cere ca stack-ul local să fie pornit. Comanda reconstruiește containerul Postgres local și reaplică fișierele de migrare din supabase/migrations, în ordine. Dacă în supabase/seed.sql există date de test, acestea se încarcă după migrări. Referința spune fără ocolișuri ce se întâmplă cu restul: "Any other data or schema changes made during local development will be discarded."

Ghidul fluxului local de lucru repetă același lucru în tabelul de comenzi: db reset „Drops everything, applies migrations, runs seed.” Este comanda care face un repository reproductibil pentru un coleg și tot ea este cea care îți șterge după-amiaza.

Două comenzi vecine se confundă ușor cu reset-ul. supabase stop nu e distructivă: pagina de început a CLI-ului spune că „Stopping doesn't reset your local database”, deci datele rezistă până la un reset. supabase stop --no-backup este excepția, iar aceeași pagină e explicită: „deletes your local schema and data changes”. Pagina recomandă să salvezi înainte de a o rula, cu supabase db diff -f pentru schema și supabase db dump --local --data-only pentru date. Acea recomandare rezumă bine tot articolul.

Reset-ul are și un mod remote. Cu --linked, aceeași comandă aplică migrările locale pe proiectul legat, iar ghidul fluxului de lucru o semnalează cu un avertisment: „Danger: db reset --linked is destructive: it erases all data in the linked remote database.” Ține cont de asta când un script trece dintr-un mediu în altul.

Care e diferența dintre un dump de schemă, un dump de date și un backup complet?

supabase db dump rulează pg_dump într-un container, cu opțiuni care exclud schemele administrate de Supabase, inclusiv auth, storage și schemele create de extensii. Cele trei rezultate pe care lumea le numește „un backup” sunt trei opțiuni diferite:

• Dump de schemă. Este varianta implicită. Referința CLI spune că dump-ul implicit „does not contain any data or custom roles”. Primești tabele, coloane, funcții, politici și grant-uri, fără niciun rând.
• Dump de date. --data-only „Dumps only data records”. Doar rânduri, fără definiții. -x exclude perechi schema.table, util când un tabel mare nu te interesează.
• Roluri. --role-only „Dumps only cluster roles”. Rolurile sunt obiecte la nivel de cluster, deci nu sunt incluse în niciunul dintre celelalte două fișiere.

Un backup logic complet al unui proiect local înseamnă toate trei fișierele, luate împreună. Comanda vizează implicit proiectul remote legat, așa că pentru lucrul local adaugă --local; -f scrie într-o cale aleasă de tine. Referința documentează și --dry-run, care afișează scriptul pg_dump în loc să îl execute, o modalitate rapidă de a vedea ce urmează să capturezi.

Merită spus clar ce nu intră în niciuna dintre ele. Un pg_dump acoperă Postgres. Fișierele urcate prin Storage nu sunt rânduri în acel dump. Supabase face aceeași distincție pentru proiectele găzduite, unde documentația despre backup spune că backup-urile bazei de date „do not include objects you store via the Storage API”. Dacă datele tale locale de test includ fișiere urcate, dump-ul bazei acoperă doar o parte din starea care te interesează.

Backup-urile găzduite sunt încă un mecanism separat. Supabase declară că face backup zilnic pentru proiectele Pro, Team și Enterprise și păstrează 7, 14 sau până la 30 de zile, în funcție de plan, iar pentru proiectele gratuite documentația recomandă exporturi regulate cu db dump și copii în afara platformei. Un stack local nu are nimic din toate acestea. Înainte să îl modifici, exportul e responsabilitatea ta.

Ce nu poate readuce un reset

Un reset reia fișierele. Reconstruiește ce este scris în supabase/migrations și supabase/seed.sql, nimic altceva. Tot ce există doar în baza de date care rulează dispare: rânduri create de aplicație într-o sesiune de test, un tabel construit manual în Studio, o politică editată acolo ca să vezi dacă ideea merge, un tabel de seed modificat ca să reproduci un raport.

Driftul de schemă este versiunea discretă a aceleiași probleme. O coloană adăugată din Studio sau printr-un prompt SQL există în baza de date și lipsește din repository. Următorul reset o elimină, iar dacă aplicația citește coloana respectivă, pică exact la interogarea care o așteaptă, posibil la câteva ecrane distanță de cauza reală. Ghidul de migrări recomandă capturarea acestor modificări cu db diff, care creează un fișier de migrare din diferență, și merită făcut cât timp schimbarea e proaspătă, nu după reset.

Același ghid notează că migrările se aplică în ordinea timestamp-ului și că push-urile simultane din mașini diferite pot intra în conflict. Pe o singură mașină varianta practică e mai simplă: dacă o modificare nu e într-o migrare, nu supraviețuiește unui reset, oricât de atent a fost construită.

De ce un backup pe care nu l-ai restaurat niciodată e o speranță, nu un plan?

Un dump nu e backup până când o restaurare nu a produs o bază de date funcțională. Până atunci ai încredere într-un fișier pe care nu i-ai citit conținutul. Trei eșecuri sunt frecvente și toate sunt tăcute în momentul capturii. Un dump implicit fără --data-only arată ca un backup și nu conține niciun rând. Un dump de date fără schemă restaurează rânduri într-o bază care nu are tabelele. Un set care omite rolurile se restaurează curat și apoi pică pe permisiuni la prima conexiune a aplicației.

Exercițiul e ieftin. Pagina de început a CLI-ului arată șirul de conexiune local implicit, postgresql://postgres:postgres@localhost:54322/postgres, și notează că poți deschide instanța locală cu psql sau cu orice alt client Postgres. Creează o bază de probă pe acea instanță, aplică fișierul de schemă, apoi pe cel de date, numără rândurile din tabelul care contează și rulează o interogare pe care ai rula-o cu adevărat în aplicație. Șterge baza de probă la final. Acum știi că fișierele se restaurează, cât durează și dacă un tabel la care te așteptai e gol.

Restaurarea nu e o operație doar de citire. Aplicarea unui dump peste o bază existentă înlocuiește ce era acolo: schema peste o schemă existentă pică pe obiecte care există deja, iar datele se scriu peste rândurile cu aceleași chei. Restaurează într-o bază de probă pentru test și fă un backup proaspăt al stării curente înainte de orice restaurare pe care vrei să o păstrezi. Dump-ul pe care îl restaurezi poate fi mai vechi decât greșeala pe care o repari.

Ce rutină funcționează înainte și după o modificare riscantă?

Secvența exactă depinde de proiect, dar forma rămâne stabilă, iar fiecare pas de mai jos folosește doar comenzi documentate de CLI.

• Pornește curat și la zi. supabase start ridică stack-ul și, conform tabelului din ghidul fluxului de lucru, aplică migrările și seed-ul.
• Capturează schema modificată manual. supabase db diff -f before_change scrie o migrare din diferență. db diff folosește implicit --local, potrivit ghidului fluxului de lucru.
• Fă dump pentru cele trei părți. supabase db dump --local -f backups/schema.sql, apoi supabase db dump --local --data-only -f backups/data.sql, apoi supabase db dump --local --role-only -f backups/roles.sql dacă ai creat roluri proprii.
• Exersează. Restaurează fișierele într-o bază de probă, verifică un număr de rânduri și rulează o interogare reală, cum am descris mai sus.
• Modifică baza de date. Rulează migrarea, SQL-ul sau refactorul și folosește supabase db reset când ai nevoie de o reconstrucție curată din migrări.
• Închide bucla. Capturează ce a funcționat ca migrare cu supabase db diff -f change_name, apoi fă commit. Fă din nou dump dacă datele rezultate merită păstrate.

Ultimul pas e cel sărit cel mai des. Un backup salvează după-amiaza curentă; o migrare salvează toate reset-urile viitoare. Fără al doilea, aceleași date se pierd din nou săptămâna viitoare, iar backup-ul ajunge singura copie a ceva ce ar fi trebuit să fie în repository.

Ce faci când modificarea merge prost?

Fă un dump proaspăt al stării stricate înainte să o atingi. S-ar putea să vrei să vezi ce a scris migrarea eșuată, iar restaurarea va trece peste ea. Apoi restaurează în baza de date de lucru, știind că tot ce e acolo acum este înlocuit:

psql "postgresql://postgres:postgres@localhost:54322/postgres" -c "drop schema public cascade; create schema public;"

psql "postgresql://postgres:postgres@localhost:54322/postgres" -f backups/schema.sql

psql "postgresql://postgres:postgres@localhost:54322/postgres" -f backups/data.sql

Prima linie este cea distructivă. Elimină schema și tot ce e în ea, de aceea dump-ul proaspăt vine primul și de aceea restaurarea pe care ai exersat-o este cea pe care ar trebui să o rulezi. Dacă restaurarea însăși eșuează pentru că fișierele sunt incomplete, supabase db reset reconstruiește totuși schema și seed-ul din repository; ce nu poate readuce sunt datele care nu au fost scrise niciodată într-un fișier.

Dacă rulezi mai multe proiecte locale, rutina manuală este locul unde un manager își câștigă utilitatea. Supabase Local Manager, un proiect independent în early access, ține o zonă de backup-uri pentru fiecare proiect: creează backup-uri cu nume, listează punctele de restaurare și restaurează unul. Restaurarea înlocuiește datele curente ale proiectului, așa că fă un backup proaspăt înainte, exact ca la psql.