Cum faci backup la baza de date a aplicației (și cum o restaurezi efectiv)

Pentru a face backup la baza de date a aplicației, exportă-o periodic într-un fișier (pentru Postgres, instrumentul standard este pg_dump), păstrează copiile în alt loc decât baza de date și restaurează regulat una într-o bază de date goală, ca să dovedești că funcționează. Fă un backup suplimentar chiar înainte de orice schimbare riscantă. Backup-ul codului, fie că e un depozit GitHub sau un export, nu include datele tale.

Acest ghid este pentru cei care rulează o aplicație mică și vor să nu mai se teamă că o vor pierde. Folosește Postgres în exemple, pentru că majoritatea aplicațiilor construite cu AI îl folosesc, dar principiile se aplică oricărei baze de date.

Ce trebuie să acopere un backup

O aplicație înseamnă mai mult decât baza ei de date. Știi ce parte protejează fiecare backup.

Datele sunt partea pe care nu o poți recrea. Codul poate fi rescris, iar setările pot fi reintroduse; comenzile clienților tăi nu pot.

Pasul 1: Decide cât poți pierde

Două întrebări îți stabilesc planul de backup:

• Cât de multe date recente poți să pierzi? Dacă faci backup o dată pe zi și baza de date cade seara, pierzi modificările din ziua respectivă. Pentru o aplicație de hobby e în regulă. Pentru o aplicație care primește comenzi, poate nu.
• Cât timp poate fi aplicația oprită cât restaurezi? O bază de date mică se restaurează în câteva minute. Una mare poate dura mult mai mult, iar tu vrei să știi asta înainte să ai nevoie.

Pentru majoritatea aplicațiilor mici, un backup automat zilnic plus unul manual înainte de schimbările riscante este un start rezonabil. Aplicațiile care implică bani sau date medicale merită backup-uri mai dese sau o bază de date gestionată, cu recuperare punct-în-timp (posibilitatea de a restaura la orice moment, nu doar la ultimul backup).

Pasul 2: Verifică ce face deja gazda ta

Mulți furnizori de baze de date gestionate fac singuri backup-uri automate. Află:

• Sunt backup-urile active în planul tău și cât de des rulează?
• Cât timp sunt păstrate?
• Poți restaura la un moment exact, sau doar la un instantaneu zilnic?
• Poți descărca un backup, sau doar îl poți restaura în sistemul lor?

Backup-urile furnizorului sunt utile, dar au un singur punct comun de cedare cu baza de date: contul. Dacă contul este închis, suspendat sau proiectul șters, backup-urile pot dispărea odată cu el. De aceea vrei și propria copie.

Pasul 3: Fă un dump cu pg_dump

pg_dump exportă o bază de date Postgres într-un fișier. Citește un instantaneu consistent, deci aplicația poate rula în continuare cât timp el lucrează.

O comandă tipică, folosind șirul de conectare pe care aplicația îl are deja într-o variabilă de mediu:

pg_dump "$DATABASE_URL" --format=custom --no-owner --file=backup-2026-09-29.dump

Ce fac opțiunile:

• --format=custom scrie un fișier comprimat, pe care îl poate citi pg_restore și care îți permite să restaurezi ulterior tabele individuale. Folosește --format=plain dacă vrei în schimb un fișier .sql citibil.
• --no-owner lasă afară comenzile de proprietate, ceea ce simplifică restaurarea într-o altă bază de date.
• Data din numele fișierului ține backup-urile separate.

Versiunea lui pg_dump ar trebui să fie aceeași cu versiunea Postgres a bazei tale sau mai nouă. Un pg_dump mai vechi poate refuza să ruleze.

Dacă construiești cu AI și nu vrei să lucrezi în linia de comandă, poți cere:

Fă un backup al bazei de date a aplicației folosind pg_dump în format custom, cu data de azi în numele fișierului. Nu afișa șirul de conectare sau vreun secret. Spune-mi numele fișierului și dimensiunea lui când termini.

Pasul 4: Automatizează

Backup-urile manuale se uită. Automatizează-le cu ce permite configurația ta:

• Backup-urile programate ale furnizorului bazei de date, dacă le oferă.
• O sarcină programată pe un server sau un serviciu CI, care rulează pg_dump și încarcă fișierul în stocare.
• Un serviciu de backup găzduit, care se conectează la baza ta de date.

Indiferent ce alegi, fă-l să te anunțe când un backup eșuează. O sarcină de backup care a eșuat liniștit trei luni este povestea de groază clasică.

Pasul 5: Păstrează copii în alt loc

Regula generală se numește 3-2-1: trei copii ale datelor, pe două tipuri diferite de stocare, cu una în afara locației principale. Pentru o aplicație mică, o variantă practică este:

• Baza de date live
• Backup-urile automate ale furnizorului
• Dump-urile tale, în stocare separată, cum ar fi un bucket de stocare de obiecte într-un alt cont

De asemenea:

• Restricționează accesul. Un backup conține datele tuturor utilizatorilor. Tratează-l ca pe baza de date live.
• Stabilește o politică de retenție. De exemplu, backup-uri zilnice timp de două săptămâni și lunare timp de un an. Șterge backup-urile vechi intenționat și ține minte că legile privind confidențialitatea pot cere să ștergi datele personale la cerere.
• Nu pune niciodată backup-uri în Git. Un dump într-un depozit este o scurgere de date care așteaptă să se întâmple.

Pasul 6: Testează o restaurare

Un backup valorează cât ultima restaurare reușită. Cel puțin la fiecare câteva luni și după orice schimbare a procesului de backup:

1. Creează o bază de date nouă, goală. Nu restaura niciodată peste cea live ca test.
2. Restaurează ultimul backup în ea:

pg_restore --no-owner --dbname="$TEST_DATABASE_URL" backup-2026-09-29.dump

Pentru un fișier .sql simplu, folosește în schimb psql "$TEST_DATABASE_URL" -f backup.sql.

1. Verifică dacă există fiecare tabelă, compară numărul de rânduri cu baza de date live și uită-te la câteva înregistrări recente.
2. Pornește o copie a aplicației pe ea și autentifică-te, dacă poți.
3. Notează cât a durat restaurarea. Acela este timpul tău real de recuperare.

Pasul 7: Fă backup înainte de schimbările riscante

Fă un backup proaspăt chiar înainte de:

• Rularea unei migrări a bazei de date care șterge sau redenumește coloane
• Importul de date în bloc
• Lăsarea unui agent AI să facă schimbări mari în modelul de date
• Ștergerea înregistrărilor vechi

Într-o aplicație construită cu AI, agentul poate schimba structura tabelelor ca parte a unei funcționalități. Checkpoint-urile și controlul versiunilor îți restaurează codul, dar nu recuperează rândurile șterse. Un backup de treizeci de secunde înainte de o schimbare mare este o asigurare ieftină.

Greșeli frecvente

• Presupunerea că Git sau un export de cod este un backup. Conține codul, nu datele.
• Să nu testezi niciodată o restaurare. Multe backup-uri se dovedesc goale, parțiale sau ilizibile exact când sunt nevoie.
• Să ții backup-urile în același cont cu baza de date. Un cont compromis sau închis pierde pe amândouă.
• Uitarea fișierelor încărcate. Baza de date stochează calea fișierului; imaginea în sine trăiește în stocare.
• Lăsarea secretelor în scripturile de backup. Citește șirul de conectare dintr-o variabilă de mediu, niciodată din textul scriptului. Vezi cum să păstrezi în siguranță cheile API.

Backup-uri și Mythex

Proiectele Mythex pot avea o bază de date Postgres dedicată, iar detaliile ei de conectare sunt injectate în spațiul de lucru și în aplicația publicată. Documentația Mythex nu descrie o funcție de backup sau restaurare a bazei de date, așa că planifică-ți propriul: cere agentului să facă un dump, descarcă-l și păstrează-l în siguranță, mai ales înainte de schimbări mari. Un export de proiect (Pro) conține codul tău, fără secrete și fără node_modules; nu conține rândurile din baza de date. Vezi Baza de date și Proprietatea datelor în documentație. Pentru mai multe despre baza de date în sine, citește ce este Postgres.

Lista de verificare pentru backup

• Ai decis cât de multe date poți pierde și cât timp poți fi oprit
• Ai verificat ce backup-uri automate oferă gazda bazei de date
• Dump-ul tău rulează programat, iar eșecurile te anunță
• Copiile sunt păstrate separat de baza de date, cu acces restricționat
• Politica de retenție este scrisă
• Fișierele încărcate sunt incluse în backup, alături de baza de date
• Restaurarea a fost testată într-o bază de date goală, iar numărul de rânduri a fost verificat
• Ai făcut un backup înainte de fiecare schimbare riscantă

Întrebări