🥇Backup-ul este pregătit: distrugem miturile cu ocazia sărbătorii

Backup-ul nu face parte din tehnologiile la modă despre care se vorbește în fiecare parte. El trebuie să existe în orice companie serioasă, asta e tot. La noi în bancă, sunt backup-uite câteva mii de servere – este o muncă complexă și interesantă, despre unele nuanțe ale căreia, dar și despre miturile tipice legate de backup-uri, mi-ar plăcea să vorbesc.

Mă ocup de această temă de aproape 20 de ani, dintre care ultimii 2 ani la Promsvyazbank. La începutul activității, efectuam backup aproape manual, cu scripturi care pur și simplu copiau fișierele. Apoi, în Windows au apărut instrumente convenabile: utilitarul Robocopy pentru pregătirea fișierelor și NT Backup pentru copiere. Apoi a venit timpul software-ului specializat, în primul rând Veritas Backup Exec, care acum se numește Symantec Backup Exec. Așadar, sunt familiarizat cu backup-urile de mult timp.

Dacă vorbim simplu, backup-ul este salvarea unei copii a datelor (mașini virtuale, aplicațiilor, bazelor de date și fișierelor) din întâmplare, cu o anumită regularitate. Întâmplarea se manifestă de obicei sub forma unei defecțiuni hardware sau logice și duce la pierderi de date. Sarcina sistemului de backup este de a reduce pierderile cauzate de pierderea informațiilor. O defecțiune hardware poate fi, de exemplu, defectarea unui server sau a unui stocaj unde se află baza de date. O defecțiune logică este pierderea sau modificarea unei părți a datelor, inclusiv din cauza factorului uman: ștergerea accidentală a unei tabele, fișier, executarea unui script greșit. Există, de asemenea, cerințe ale regulatorului privind păstrarea unui anumit tip de informații pe o perioadă lungă, de exemplu, până la câțiva ani.

Cea mai tipică solicitare de backup este restaurarea unei copii salvate a bazelor de date pentru desfășurarea diferitelor sisteme de testare, clone pentru dezvoltatori.

În jurul backup-ului există câteva mituri tipice care trebuie demontate de mult. Iată cele mai cunoscute dintre ele.

Mit 1. Backup-ul este deja doar o funcție minoră în cadrul sistemelor de securitate sau stocare.

Sistemele de backup rămân în continuare o clasă separată de soluții și sunt destul de independente. Li s-a încredințat o responsabilitate prea importantă. În esență, ele reprezintă ultima linie de apărare atunci când vine vorba de integritatea datelor. Așadar, backup-ul funcționează în ritmul său, conform programului propriu. Se generează un raport zilnic pentru servere, existând evenimente care acționează ca triggeri pentru sistemul de monitorizare.

În plus, modelul de acces rolului la sistemul de backup permite delegarea unei părți a atribuțiilor administratorilor sistemelor țintă pentru gestionarea copiilor de siguranță.

Mitul 2. Când există RAID, backup-ul nu mai este necesar.

Fără îndoială, array-urile RAID și replicarea datelor sunt o modalitate bună de a proteja sistemele informaționale împotriva defecțiunilor hardware, iar în cazul existenței unui server de rezervă – de a organiza rapid trecerea pe el în cazul defectării mașinii principale.

Eroarele logice comise de utilizatorii sistemului nu sunt salvate de redundanță și replicare. Un server de rezervă cu scriere întârziată – da, poate ajuta, dacă eroarea este detectată înainte de a fi sincronizată. Dar dacă momentul este ratat? Aici poate interveni doar un backup realizat la timp. Dacă se știe că datele s-au schimbat ieri, se poate restaura sistemul la starea de alaltăieri și extrage datele dorite. Având în vedere că erorile logice sunt cele mai frecvente, backup-ul clasic rămâne o soluție testată și necesară.

Mitul 3. Backup-ul se face o dată pe lună.

Frecvența backup-ului este un parametru configurabil, care depinde în primul rând de cerințele sistemului de backup. Este destul de realist să găsești date care practic nu se schimbă niciodată și care nu sunt foarte importante; pierderea lor nu va fi critică pentru companie.
Acestea, într-adevăr, pot fi salvate o dată pe lună și chiar mai rar. Însă datele mai critice sunt salvate mai frecvent, în funcție de indicatorul RPO (Recovery Point Objective), care stabilește pierderea acceptabilă de date. Aceasta poate fi o dată pe săptămână, o dată pe zi sau chiar de câteva ori pe oră. În cazul nostru, acestea sunt jurnalele de tranzacții din SGBD.

Când sistemele sunt puse în exploatare industrială, este obligatorie aprobarea documentației privind backup-ul, care reflectă punctele esențiale, regimul de actualizare, ordinea de restaurare a sistemului, ordinea de stocare a copiilor de rezervă și altele asemenea.

Mit 4. Volumul copiilor crește neîncetat și ocupă complet orice spațiu alocat.

Copiile de rezervă au un termen limitat de păstrare. Nu are sens, de exemplu, să stocăm timp de un an toate cele 365 de backup-uri zilnice. De regulă, este permis să păstrăm copiile zilnice timp de 2 săptămâni, după care acestea sunt înlocuite cu altele noi, iar pentru păstrarea pe termen lung rămâne versiunea care a fost realizată prima în lună. Aceasta, la rândul ei, este păstrată și ea pentru o anumită perioadă - fiecare copie are un timp de viață.

Există protecție împotriva pierderii datelor. Se aplică regula: înainte ca un backup să fie șters, următorul trebuie să fie realizat. Așadar, datele nu vor fi șterse dacă backup-ul nu a fost finalizat, de exemplu, din cauza inaccesibilității serverului. Se respectă nu doar termenele limită, ci și se controlează numărul de copii din set. Dacă în sistem este stabilit că trebuie să existe două backup-uri complete, acestea vor fi întotdeauna două, iar cel vechi va fi șters doar atunci când se va scrie cu succes un nou al treilea. Așadar, creșterea volumului ocupat de arhiva backup-urilor este legată doar de creșterea cantității de date protejate și nu depinde de timp.

Mit 5. Backup-ul a început – totul s-a blocat.

Mai bine spus: dacă totul s-a blocat, înseamnă că administratorul nu știe ce face. În general, performanța backup-ului depinde de mulți factori. De exemplu, de performanța sistemului de backup: cât de rapide sunt stocările pe disc, bibliotecile de bandă. De asemenea, depinde de performanța servere sistemului de backup: dacă reușește să proceseze datele, să efectueze comprimarea și deduplicarea. De asemenea, de viteza liniilor de comunicare între client și server.

Backup-ul poate fi efectuat în unul sau mai multe fluxuri, în funcție de faptul dacă sistemul rezervat suportă multithreading. De exemplu, SGBD-ul Oracle permite utilizarea mai multor fluxuri, în funcție de numărul de procesoare disponibile, până când viteza de transfer atinge limita capacității rețelei.

Dacă se încearcă să se realizeze backup-uri cu un număr mare de fluxuri, există riscul de a suprasolicita sistemul în funcțiune, care va începe cu adevărat să încetinească. Prin urmare, se alege un număr optim de fluxuri pentru a asigura o performanță suficientă. Dacă chiar și cea mai mică scădere a performanței este critică, există o opțiune excelentă, când backup-ul se face nu de pe serverul de producție, ci de pe un clon – standby în terminologia bazelor de date. Acest proces nu încarcă sistemul de lucru principal. Datele pot fi extrase printr-un număr mai mare de fluxuri, deoarece serverul nu este folosit pentru servicii.

În organizațiile mari, pentru sistemul de backup se créează o rețea separată, astfel încât backup-ul să nu afecteze producția. În plus, traficul poate fi transmis nu prin rețea, ci prin SAN.

Încercăm să distribuim încărcătura și în funcție de timp. Backup-urile se desfășoară predominant în orele de nefuncționare: noaptea, în weekend. În plus, acestea nu sunt inițiate toate simultan. Backup-urile mașinilor virtuale sunt un caz special. Procesul afectează practic deloc performanța propriei mașini, astfel că backup-ul poate fi întins pe timpul zilei, în loc să fie amânat pentru noapte. Sunt multe subtilități, dacă se iau toate în considerare, backup-ul nu va influența performanța sistemelor.

Mitul 6. Am pornit sistemul de backup – și gata, ai redundanță.

Nu uitați niciodată că sistemul de backup este ultima linie de apărare, ceea ce înseamnă că trebuie să existe încă cinci sisteme care să asigure continuitatea, disponibilitatea ridicată și reziliența la dezastre a infrastructurii IT și a sistemelor informaționale ale întreprinderii.

Nu merită să speri că backup-ul va restaura toate datele și va reporni rapid serviciul căzut. Pierderea datelor de la momentul backup-ului până la momentul defecțiunii este garantată, iar datele pe un nou server pot fi încărcate timp de câteva ore (sau zile, cum va fi). De aceea, are sens să se creeze sisteme complete de redundanță, fără a se baza doar pe backup.

Mitul 7. Am configurat backup-ul o dată, am verificat că funcționează. Rămâne doar să urmăresc jurnalele.

Aceasta este unul dintre cele mai dăunătoare mituri, a cărui falsitate o conștientizezi doar în timpul unui incident. Jurnalele de succes ale backup-ului nu reprezintă o garanție că totul a decurs conform așteptărilor. Este esențial să verifici în prealabil copia salvată pentru redeployment. Adică, să inițiezi procesul de restaurare într-un mediu de testare și să observi rezultatul.

Și puțin despre munca administratorului de sistem

În modul manual, nimeni nu mai copiază date de mult timp. Sistemele moderne de backup pot salva aproape totul, trebuie doar să fie configurate corespunzător. Dacă a fost adăugat un nou server – trebuie să se definească politicile: să alegi conținutul care va fi salvat, să specifici parametrii de stocare și să aplici un program.

Cu toate acestea, munca este încă destul de multă datorită parcului extins de servere, care include baze de date, sisteme poștale, clustere de mașini virtuale și resurse de fișiere atât pe Windows, cât și pe Linux/Unix. Angajații care mențin funcționalitatea sistemului de backup nu stau degeaba.