Skip to main content
Înapoi la blog

Cum verificăm backup-urile: retenție, exerciții de restaurare și dovezi

Valentin Zsigmond
Valentin Zsigmond18 iunie 20265 min de citit

Avem o frază pe care o repetăm între noi ori de câte ori vine vorba de backup-uri: un backup devine real abia după ce a fost restaurat undeva. Până în acel moment e un fișier despre care speri că e complet, produs de un proces despre care speri că a rulat, așezat pe un spațiu de stocare despre care speri că e sănătos. Speranța nu e o strategie pe care să o vindem cu inima împăcată, așa că rutina noastră de backup e construită să înlocuiască fiecare dintre aceste speranțe cu ceva ce am văzut cu ochii noștri că funcționează.

Articolul de față parcurge rutina asta: cum funcționează programul automat, de ce păstrăm backup-uri pe niveluri zilnice, săptămânale și lunare, și partea pe care o considerăm cea mai importantă, exercițiile de restaurare. Nimic din toate acestea nu e spectaculos. Toate la un loc fac diferența dintre un incident care costă o oră și unul care lasă o afacere fără întreaga ei istorie.

Programul pe care nu trebuie să îl țină minte nimeni

Pe platforma noastră, backup-urile rulează după un program automat. Nu le declanșează nimeni, nu trebuie să și le amintească nimeni și niciun client nu e pus vreodată să se gândească la ele. Asta contează mai mult decât pare. Orice rutină care depinde de memoria unui om dă la un moment dat peste un concediu, o săptămână aglomerată sau o predare de ștafetă, și exact atunci cedează. Așa că programul face parte din platforma de găzduire, la fel cum certificatele TLS se reînnoiesc singure și actualizările de securitate se aplică pe toate site-urile pe care le găzduim. Rulează indiferent dacă săptămâna e liniștită sau haotică, iar monitorizarea noastră deschide un incident dacă un backup programat nu apare, pentru că un backup care lipsește pe tăcute e cel mai periculos fel de backup.

Fiecare backup acoperă tot ce îi trebuie unui site ca să revină: baza de date, fișierele încărcate și configurația care le leagă. Un export de bază de date fără fișiere înseamnă un site plin de imagini sparte. Fișierele fără baza de date sunt un folder de orfani. Le tratăm ca pe un tot pentru că și o restaurare le tratează ca pe un tot.

De ce păstrăm backup-urile pe niveluri

Păstrăm backup-uri zilnice, săptămânale și lunare, iar motivul e simplu: probleme diferite ies la iveală după intervale diferite.

Greșeala de ieri e cazul ușor. Un editor șterge pagina greșită, un import o ia razna, o actualizare în masă atinge mai mult conținut decât trebuia. Cineva observă repede, iar cel mai recent backup zilnic conține tot ce era înainte de greșeală. Ăsta e scenariul la care se gândesc cei mai mulți când aud de backup-uri, și e și cel mai puțin pretențios.

Cazul mai greu e problema pe care nu a observat-o nimeni săptămâni întregi. Un formular care a încetat pe tăcute să mai salveze răspunsurile. Conținut suprascris la o curățenie, a cărui lipsă s-a observat abia când cineva a mers să îl caute. Până iese la suprafață o astfel de problemă, toate backup-urile zilnice o conțin deja. Pentru asta există nivelurile săptămânale și lunare: ne permit să ne întoarcem în timp dincolo de momentul în care a început paguba și să recuperăm ce era bun înainte. Nu păstrăm backup-uri pe niveluri ca să adunăm date de dragul lor, ci ca să acoperim cât durează, realist, până descoperi că ceva a mers prost.

O bifă verde nu e o dovadă

Orice sistem de backup din lume îți va arăta bucuros o bifă verde. Procesul a rulat, fișierul există, dimensiunea pare plauzibilă. Le urmărim și noi, și sunt utile ca să prinzi un proces care a picat de tot. Dar o bifă nu îți poate spune dacă exportul bazei de date chiar se va importa, dacă arhiva de fișiere e completă sau dacă instantaneul a prins din întâmplare site-ul în mijlocul unei actualizări, într-o stare din care nu mai revine curat.

Singurul test care răspunde la aceste întrebări e o restaurare. Nu există scurtătură, nu există verificare ingenioasă care să o înlocuiască, și orice echipă care operează backup-uri cu seriozitate ajunge mai devreme sau mai târziu la aceeași concluzie. Preferăm să ajungem la ea într-o după-amiază liniștită decât în timpul unei căderi. Așa că, în loc să ne încredem în bifă, exersăm.

Cum arată un exercițiu de restaurare

Un exercițiu de restaurare e exact ce spune numele. Luăm un backup real al unui site real și îl readucem la viață într-un mediu izolat, la fel cum am face dacă originalul s-ar fi pierdut. Baza de date e încărcată, fișierele sunt puse la locul lor, configurația e aplicată, iar apoi un om, nu un script, deschide site-ul și îl verifică. Se încarcă paginile, merge autentificarea, conținutul recent e acolo, fișierele încărcate se deschid.

Dintr-un exercițiu ies două lucruri, pe lângă încredere. Primul e un număr: cât durează efectiv o restaurare, de la decizie până la un site funcțional. Când se întâmplă un incident real, numărul acela e răspunsul onest la singura întrebare pe care o pune un client, și anume "când revenim online?". Al doilea sunt piedicile descoperite pe timp de pace. Un pas care lipsește din procedura scrisă, o parolă pe care o știa un singur om, o arhivă care se descarcă mai greu decât te aștepți. Fiecare se repară ieftin într-o zi obișnuită și costă scump când o descoperi sub presiune, și tocmai ăsta e rostul exercițiului.

Pentru că rulăm local aceeași platformă de producție care rulează și pe serverele noastre, mediul în care exersăm restaurarea unui backup se comportă ca cel în care l-am restaura pe bune. Un exercițiu trecut cu bine e o dovadă, nu o aproximare.

Restaurarea ca instrument de zi cu zi

Ceva ce am învățat pe parcurs: când restaurările devin rutină, nu mai sunt o abilitate scoasă doar la urgențe. Aducem regulat în mediile de dezvoltare copii ale bazelor de date de producție, curățate de date personale, ca parte firească din munca la funcționalități noi, așa că traseul de restaurare e bătătorit constant, nu din când în când. Aceeași mașinărie stă în spatele pachetelor noastre de predare: orice client poate cere un export complet al site-ului său, care se restaurează cu o singură comandă, ca ceva standard în felul în care lucrăm, nu ca subiect de negociere. Putem promite asta liniștiți pentru că restaurăm tot timpul, nu scoatem procedura de la naftalină într-o criză.

Ce înseamnă asta pentru tine ca proprietar de site

Dacă ai un site, la noi sau oriunde altundeva, ce merită să reții e o listă scurtă de întrebări. Backup-urile sunt automate sau trebuie să și le amintească cineva? Acoperă fișierele și baza de date împreună? Cât de departe în urmă poți ajunge, și e destul pentru cât ar putea dura până observi o problemă tăcută? Și întrebarea care contează cel mai mult: când a fost restaurat ultima dată un backup, și cât a durat?

Oricine are grijă de site-ul tău ar trebui să poată răspunde la toate astea fără să caute. Noi ne-am construit rutina așa încât să putem, și te încurajăm să ceri același lucru indiferent unde ți-e găzduit site-ul. Un backup pe care l-ai văzut revenind la viață valorează mai mult decât orice panou de control plin de bife verzi.

Distribuie articolul
Valentin Zsigmond
Scris de
Valentin Zsigmond
Fondator și inginer principal

Arhitect Drupal full-stack cu aproape două decenii de experiență în conducerea unor echipe mari în medii enterprise. A fondat Tilizy Digital pentru a aduce expertiză de nivel senior direct organizațiilor care au nevoie de ea. Mentor pentru zeci de dezvoltatori Drupal și creatorul SDX, o extensie Drupal pentru construirea de interfețe moderne cu React și Vue.

Ți-a plăcut articolul?

Dacă te-ai regăsit în articol, imaginează-ți ce am putea face împreună pe site-ul tău Drupal.