Backup-urile pe care le-ai restaurat cu adevărat

Un backup este o afirmație. Spune că la un moment dat datele au existat și în alt loc, într-o formă care poate fi readusă. Un restore este dovada. Majoritatea echipelor produc afirmația în fiecare noapte și nu adună niciodată dovada, așa că primul test real are loc în cea mai proastă zi posibilă, cu site-ul jos și cu cineva care întreabă cât durează. Diferența dintre cele două este locul unde echipele mici pierd weekenduri.

Care e diferența dintre un backup și un restore?

Un backup este o copie plus o promisiune despre formatul ei. Un restore este operația prin care copia redevine o bază de date funcțională, cu schema, rândurile, rolurile și permisiunile pe care le așteaptă aplicația. Primul poate raporta succes producând ceva inutil. Al doilea răspunde la întrebarea care contează: putem reveni la lucru?

Modurile de eșec sunt tăcute în momentul capturii. Un dump în format text arată ca un backup chiar și când conține doar schema. Un dump de date fără schemă restaurează rânduri într-o bază care nu are tabele. Documentația PostgreSQL spune că pg_dump acoperă o singură bază de date și lasă obiectele la nivel de cluster, cum ar fi rolurile și tablespace-urile, în sarcina pg_dumpall, așa că un set fără ele se restaurează curat și apoi pică la prima conexiune a aplicației. Aceeași pagină dă și o regulă de versiune care produce eșecuri discrete: pg_dump nu poate dumpa un server mai nou decât versiunea sa majoră. Un client vechi pe mașina de backup transformă jobul într-o eroare pe care nimeni nu o citește.

De ce dovedește atât de puțin un job de backup reușit?

Monitorizarea verifică de obicei codul de ieșire, dimensiunea și vechimea celui mai nou fișier. Niciuna nu citește conținutul. Un job care a copiat jumătate dintr-un tabel când s-a rupt conexiunea produce tot un fișier de dimensiune plauzibilă. Un snapshot care apare verde în consola furnizorului nu a fost încărcat niciodată. Manualul PostgreSQL este direct și despre limitele acestui instrument: în afară de cazurile simple, pg_dump nu este în general alegerea potrivită pentru backup-uri regulate ale bazelor de date de producție. Nu este un argument împotriva dump-urilor, ci pentru a ști ce nu acoperă mecanismul pe care te bazezi.

Furnizorii își desenează propriile granițe și le documentează. Documentația de backup a Supabase spune că backup-urile bazei de date nu includ obiectele stocate prin Storage API, că restaurarea unui backup vechi nu readuce obiectele șterse după acel backup, că backup-urile zilnice nu păstrează parolele rolurilor personalizate și că ștergerea unui proiect elimină definitiv și backup-urile lui. Sunt marginea cuvântului „backup”, iar majoritatea oamenilor o întâlnesc în timpul unui incident.

Unde ar trebui să stea un backup?

Într-un loc care pică separat de baza de date. Nu într-un alt folder pe același disc, pe un alt volum al aceleiași mașini sau în același cont cloud. O copie în object storage din contul care găzduiește baza de date dispare odată cu o compromitere de credențiale, o suspendare de facturare sau ștergerea accidentală a proiectului. Folosește un cont separat, iar pentru datele importante un al doilea furnizor.

Credențialele contează la fel de mult ca locul. Cheia care scrie backup-uri nu ar trebui să fie cea a aplicației, iar aplicația nu ar trebui să poată șterge backup-uri deloc. Dacă e compromisă, nu trebuie să poată șterge toate copiile.

Regula 3-2-1, repetată peste tot, spune trei copii, pe două tipuri de suport, dintre care una în afara locației. Este o euristică, nu un standard, fără o singură sursă autoritativă, așa că trateaz-o ca punct de plecare. Pentru un dezvoltator singur se traduce printr-un dump nocturn către object storage într-un cont separat, plus o copie săptămânală la un al doilea furnizor sau pe un disc extern criptat, ținut în altă parte. Pentru o echipă mică, la fel, plus point-in-time recovery de la furnizor dacă planul îl include.

Retenția furnizorului nu este retenția ta. Amazon RDS păstrează backup-urile automate între 0 și 35 de zile, cu o valoare implicită de o zi când instanța e creată prin API sau CLI și șapte zile prin consolă. Supabase păstrează 7 zile pe Pro, 14 pe Team și până la 30 pe Enterprise. Google Cloud SQL permite între 1 și 365 de zile pentru backup-urile automate standard, mai mult cu backup-urile extinse. Toate trei sunt limite ale produsului, nu politica ta. Două reguli de ștergere decid dacă copia furnizorului este cu adevărat a ta: RDS șterge backup-urile automate odată cu instanța dacă nu alegi să le păstrezi, în timp ce snapshot-urile manuale supraviețuiesc; Supabase elimină backup-urile când proiectul este șters.

Cât de des să ruleze backup-urile și cât timp să le păstrezi?

Obiectivul de punct de recuperare este câte date îți permiți să pierzi, în ore. Obiectivul de timp de recuperare este cât poate sta jos afacerea. Un dump nocturn dă un punct de recuperare de până la 24 de ore. Point-in-time recovery îl scurtează la minute: Supabase documentează fișiere WAL salvate aproximativ la fiecare două minute, cu un punct de recuperare de două minute în cel mai rău caz. Dacă pierderea unei zile de comenzi este inacceptabilă, un dump nocturn singur este instrumentul greșit.

Retenția ar trebui să depășească timpul în care observi o problemă, nu doar timpul de la ieri. O migrare greșită sau o corupție tăcută poate trece neobservată săptămâni întregi, iar atunci o fereastră de șapte zile a suprascris deja ultima copie bună. O formă care funcționează pentru o echipă mică este 14 copii zilnice, 8 săptămânale și 12 lunare, cu una păstrată peste un an dacă de ea depind facturi sau contracte. Șterge după un program, dar verifică faptul că jobul a păstrat copia din care te-ai restaura cu adevărat.

Cum exersezi un restore pe o copie de probă?

Nu exersa niciodată restaurând peste producție și nu exersa doar pe mașina care a produs dump-ul. Ia copia pe care ai folosi-o în realitate, de obicei cea din afara locației, și încarc-o într-o bază de date de unică folosință.

• Fă dump-ul într-un format care se poate restaura. pg_dump -Fc -d app -f app-2026-10-23.dump scrie o arhivă comprimată pe care pg_restore o poate inspecta și restaura selectiv.
• Inspectează înainte să restaurezi. pg_restore -l app-2026-10-23.dump afișează cuprinsul arhivei. Dacă tabelul care te interesează nu apare, oprește-te acolo.
• Creează o țintă goală. createdb -T template0 app_restore_check. pg_restore nu creează baza de date implicit, iar template0 evită obiectele care ar fi putut fi adăugate în template1.
• Fă erorile fatale. pg_restore --exit-on-error -d app_restore_check app-2026-10-23.dump. Implicit, pg_restore continuă după erori și afișează un număr la final, așa că o rulare care pare terminată poate să nu aibă toate tabelele.
• Măsoară timpul. Notează începutul și sfârșitul. Durata aceea este timpul tău real de recuperare, nu estimarea din documentația de procedură.

Pentru un dump în format text, echivalentul este psql -X --set ON_ERROR_STOP=on -d app_restore_check -f app.sql. Fără ON_ERROR_STOP, psql continuă după o eroare SQL, prin proiectare. Restaurarea din copia locală, comodă, dovedește mai puțin decât restaurarea din copia din afara locației, pentru că aceea este cea care supraviețuiește evenimentului pentru care te pregătești.

Pe o platformă găzduită, restaurarea se face adesea în loc: Supabase notează că proiectul este inaccesibil în timpul restaurării și că timpul de nefuncționare crește odată cu dimensiunea bazei de date. Exersează în altă parte: un proiect de probă, o instanță locală sau o copie restaurată de tine. Ghidul nostru despre backup-ul bazei locale înainte de o modificare acoperă partea locală a aceleiași rutine.

Ce verifici după un restore?

• Serverul acceptă conexiuni și aplicația pornește pe el cu utilizatorul ei normal, nu cu superuserul. Eșecurile de permisiuni apar aici.
• Numărul de rânduri pentru câteva tabele care contează. Notează numerele când faci dump-ul, ca restaurarea să fie comparată cu un număr, nu cu o impresie.
• O înregistrare cunoscută. Alege un rând pe care îl poți identifica manual și compară mai multe câmpuri, nu doar existența lui.
• Cel mai nou rând. Timestamp-ul maxim ar trebui să fie aproape de momentul dump-ului. Un restore vechi de câteva zile înseamnă că jobul de backup eșua în tăcere.
• Un insert și un delete. Adăugarea unui rând prinde secvențele care nu au fost avansate și constrângerile care nu mai corespund datelor.
• O interogare sau o pagină reală a aplicației. Un count dovedește că datele au ajuns; aplicația dovedește că sunt utilizabile.
• Lucrurile din afara bazei de date. Fișiere urcate, object storage, indexuri de căutare, cozi. Excluderea obiectelor Storage API la Supabase este exemplul documentat, iar majoritatea furnizorilor trag o linie similară.

Notează rezultatul pe măsură ce lucrezi. Un exercițiu care eșuează este un succes, pentru că a eșuat într-o după-amiază de marți, nu în timpul unui incident.

Cum notezi un exercițiu de restaurare?

O linie pentru fiecare rulare, într-un fișier care stă lângă notele de operare ale proiectului, nu în memoria cuiva: data exercițiului, momentul backup-ului folosit, de unde a venit copia, numele fișierului de dump și checksum-ul, baza de date țintă, durata restaurării, verificările trecute și eșuate și cine a rulat. Păstrează și eșecurile. După trei sau patru rulări ai un timp de recuperare realist și o listă de lucruri care se strică repetat, iar acesta este rezultatul concret al exercițiului.

Pune următorul exercițiu în calendar înainte să-l termini pe cel curent: trimestrial pentru o echipă mică, lunar dacă datele se schimbă constant. După ce rutina manuală rezistă câteva trimestre, automatizează partea plictisitoare. Un job programat poate restaura ultimul dump într-o bază de probă, poate rula numărătorile și interogarea pe înregistrarea cunoscută și poate publica rezultatul. Automatizează doar ce ai făcut deja manual.

Listă de verificare

• Backup-urile se scriu în alt loc decât gazda bazei de date, într-un cont sau la un furnizor separat.
• Credențialele de backup nu pot fi folosite de aplicație, iar aplicația nu poate șterge backup-uri.
• Cel puțin o copie este criptată, iar cheia este păstrată în afara contului de backup.
• Retenția este scrisă undeva și depășește timpul în care ai observa o problemă.
• Un restore a fost făcut în ultimul trimestru, din copia din afara locației, într-o bază de probă.
• Numărul de rânduri, o înregistrare cunoscută și o interogare a aplicației au fost verificate, iar rezultatele au fost notate cu dată.
• Durata restaurării este cunoscută și comparată cu timpul de nefuncționare pe care îl suporți.
• Nota exercițiului spune cine l-a rulat și ce a eșuat.

Autoevaluare într-o după-amiază

Rezervă două ore și nu repara nimic până nu ai scris ce ai găsit.

• Găsește ultimul backup. Poți spune, fără să deschizi consola furnizorului, când a rulat și ce conține?
• Descarcă-l pe o mașină care nu este serverul bazei de date.
• Pornește o instanță PostgreSQL goală, local sau într-un container, cu o versiune cel puțin la fel de nouă ca serverul care a produs dump-ul.
• Restaurează-l și cronometrează de la prima comandă la ultima.
• Rulează numărătorile și interogarea pe înregistrarea cunoscută, apoi încearcă un insert.
• Pornește aplicația pe el, măcar pe un laptop, și deschide pagina care citește cel mai important tabel.
• Scrie nota. Dacă un pas a cerut o parolă pe care a trebuit să o ceri cuiva, și asta este o constatare.

Dacă tot exercițiul a durat mai puțin de o oră, ești în formă bună. Dacă nu ai găsit backup-ul sau restaurarea a eșuat, tocmai ai aflat cel mai util lucru din luna asta, iar nimeni nu a fost jos cât timp l-ai aflat. Un backup pe care l-ai restaurat o dată valorează mai mult decât trei pe care nu le-ai atins niciodată.