Backup-ul nu este una dintre tehnologiile la modă despre care strigă toată lumea. Pur și simplu ar trebui să fie în orice companie serioasă, asta-i tot. Banca noastră face copii de rezervă pentru câteva mii de servere - aceasta este o muncă complexă, interesantă și aș dori să vorbesc despre unele dintre complexitățile acesteia, precum și despre concepțiile greșite tipice cu privire la backup-uri.
Lucrez la acest subiect de aproape 20 de ani, dintre care ultimii 2 ani au fost la Promsvyazbank. La începutul practicii mele, am făcut copii de rezervă aproape manual, folosind scripturi care copiau pur și simplu fișiere. Apoi au apărut instrumente convenabile în Windows: utilitarul Robocopy pentru pregătirea fișierelor și NT Backup pentru copiere. Și abia atunci a venit vremea software-ului specializat, în primul rând Veritas Backup Exec, care se numește acum Symantec Backup Exec. Așa că sunt familiarizat cu backup-urile de mult timp.
Mai simplu spus, backup înseamnă salvarea unei copii a datelor (mașini virtuale, aplicații, baze de date și fișiere) doar în cazul în care, cu o anumită regularitate. Fiecare caz se manifestă de obicei sub forma unei defecțiuni hardware sau logice și duce la pierderea datelor. Scopul unui sistem de rezervă este de a reduce pierderile din pierderea de informații. O defecțiune hardware este, de exemplu, o defecțiune a serverului sau a stocării în care se află baza de date. Logic este pierderea sau modificarea unei părți a datelor, inclusiv din cauza factorului uman: un tabel sau un fișier a fost șters accidental sau a fost lansat un script pentru a executa o curbă. Există, de asemenea, cerințe de reglementare pentru stocarea anumitor tipuri de informații pe o perioadă lungă, de exemplu, până la câțiva ani.
Cea mai obișnuită utilizare a backup-urilor este restaurarea unei copii salvate a bazelor de date pentru implementarea diferitelor sisteme de testare și clone pentru dezvoltatori.
Există mai multe mituri comune cu privire la backup, care sunt de mult așteptate pentru a fi eliminate. Iată cele mai cunoscute dintre ele.
Mitul 1. Backup-ul a fost mult timp doar o funcție minoră în cadrul sistemelor de securitate sau de stocare
Sistemele de backup rămân în continuare o clasă separată de soluții și foarte independente. Lor li s-a încredințat o sarcină prea importantă. În esență, ele sunt ultima linie de apărare când vine vorba de securitatea datelor. Deci backup-ul funcționează în propriul ritm, pe propriul program. Un raport zilnic este generat pe servere; există evenimente care acționează ca declanșatori pentru sistemul de monitorizare.
În plus, modelul de acces la sistemul de backup vă permite să delegați unele dintre puterile administratorilor sistemelor țintă pentru a gestiona backup-urile.
Mitul 2. Când există RAID, backup-ul nu mai este necesar
Fără îndoială, matricele RAID și replicarea datelor sunt o modalitate bună de a proteja sistemele de informații împotriva defecțiunilor hardware și, dacă aveți un server de așteptare, organizați rapid trecerea la acesta în cazul defecțiunii mașinii principale.
Redundanța și replicarea nu vă salvează de erorile logice făcute de utilizatorii sistemului. Iată un server de așteptare cu înregistrare întârziată - da, poate ajuta dacă este detectată o eroare înainte de sincronizare. Ce se întâmplă dacă momentul este ratat? Doar o copie de rezervă în timp util va ajuta aici. Dacă știți că datele s-au schimbat ieri, puteți restabili sistemul de alaltăieri și puteți extrage din el datele necesare. Având în vedere că erorile logice sunt cele mai frecvente, backup-ul vechi bun rămâne un instrument dovedit și necesar.
Mitul 3. Backup-ul este ceva care se face o dată pe lună.
Frecvența de rezervă este un parametru configurabil care depinde în primul rând de cerințele sistemului de rezervă. Este foarte posibil să găsiți date care aproape niciodată nu se schimbă și nu sunt deosebit de importante; pierderea lor nu va fi critică pentru companie.
Într-adevăr, se pot face copii de rezervă o dată pe lună sau chiar mai rar. Dar mai multe date critice sunt salvate mai des, în funcție de indicatorul RPO (Recovery point objrective), 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ă. Pentru noi, acestea sunt jurnalele de tranzacții din SGBD.
La punerea în funcțiune comercială a sistemelor, trebuie aprobată documentația de rezervă, care reflectă punctele principale, reglementările de actualizare, procedurile de recuperare a sistemului, procedurile de stocare de rezervă și altele asemenea.
Mitul 4. Volumul de copii este în continuă creștere și ocupă complet orice spațiu alocat
Backup-urile au o perioadă de valabilitate limitată. Nu are sens, de exemplu, să stocați toate cele 365 de copii de rezervă zilnice pe tot parcursul anului. De regulă, este permisă păstrarea copiilor zilnice timp de 2 săptămâni, după care acestea sunt înlocuite cu altele proaspete, iar pentru stocarea pe termen lung rămâne versiunea care a fost făcută prima în lună. La rândul său, este stocat și pentru un anumit timp - fiecare copie are o viață.
Există protecție împotriva pierderii datelor. Se aplică regula: înainte ca o copie de rezervă să fie ștearsă, trebuie creată următoarea. Prin urmare, datele nu vor fi șterse dacă backupul eșuează, de exemplu, din cauza indisponibilității serverului. Nu numai că sunt respectate limitele de timp, dar și numărul de copii dintr-un set este controlat. Dacă sistemul cere să existe două copii de rezervă complete, vor exista întotdeauna două dintre ele, iar cea veche va fi ștearsă numai atunci când cea de-a treia nouă este înregistrată cu succes. Deci creșterea volumului ocupat de arhiva de rezervă este asociată doar cu creșterea cantității de date protejate și nu depinde de timp.
Mitul 5. Când începe o copie de rezervă, totul se blochează
Este mai bine să spuneți acest lucru: dacă totul se blochează, înseamnă că mâinile administratorului nu cresc de acolo. În general, performanța copiei de rezervă depinde de mulți factori. De exemplu, asupra performanței sistemului de rezervă în sine: cât de rapide sunt stocarea pe disc și bibliotecile de benzi. De la performanța serverelor de sistem de backup: dacă au timp să proceseze datele, să efectueze compresie și deduplicare. Și, de asemenea, asupra vitezei liniilor de comunicație dintre client și server.
Backup-ul poate merge la unul sau mai multe fire de execuție, în funcție de faptul dacă sistemul de backup acceptă multithreading. De exemplu, Oracle DBMS vă permite să trimiteți mai multe fire de execuție, în funcție de numărul de procesoare disponibile, până când viteza de transfer atinge limita lățimii de bandă a rețelei.
Dacă încercați să faceți backup pentru un număr mare de fire, atunci există șansa de a supraîncărca sistemul care rulează, acesta va începe cu adevărat să încetinească. Prin urmare, numărul optim de fire este selectat pentru a asigura o performanță suficientă. Dacă chiar și cea mai mică scădere a performanței este critică, atunci există o opțiune excelentă atunci când backup-ul este efectuat nu de pe serverul de producție, ci de la clona acestuia - standby în terminologia bazei de date. Acest proces nu încarcă sistemul principal de lucru. Datele pot fi preluate prin mai multe fire, deoarece serverul nu este folosit pentru întreținere.
În organizațiile mari, este creată o rețea separată pentru sistemul de backup, astfel încât backupul să nu afecteze producția. În plus, traficul poate fi transmis nu prin rețea, ci prin SAN.
De asemenea, încercăm să distribuim încărcătura în timp. Backup-urile se efectuează în mare parte în timpul orelor de lucru: noaptea, în weekend. De asemenea, nu încep toate în același timp. Backup-urile mașinilor virtuale sunt un caz special. Procesul nu are practic niciun efect asupra performanței mașinii în sine, astfel încât backup-ul poate fi răspândit pe tot parcursul zilei, mai degrabă decât să amâne totul noaptea. Există multe subtilități, dacă țineți cont de totul, backup-ul nu va afecta performanța sistemului.
Mitul 6. Am lansat un sistem de rezervă - asta este toleranța la greșeală pentru tine
Nu uitați niciodată că sistemul de rezervă este ultima linie de apărare, ceea ce înseamnă că trebuie să mai existe încă cinci sisteme în fața lui care să asigure continuitatea, disponibilitatea ridicată și rezistența la dezastre a infrastructurii IT și a sistemelor informaționale ale întreprinderii.
Nu are rost să sperăm că o copie de rezervă va restabili toate datele și va restabili rapid serviciul căzut. Pierderea datelor din momentul efectuării copiei de rezervă până în momentul eșecului este garantată, iar datele pot fi încărcate pe un nou server timp de câteva ore (sau zile, în funcție de norocul tău). Prin urmare, este logic să creați sisteme complete cu toleranță la erori fără a trece totul la backup.
Mitul 7. Am creat o copie de rezervă o dată și am verificat dacă funcționează. Tot ce rămâne este să te uiți la jurnalele
Acesta este unul dintre cele mai dăunătoare mituri, a cărui falsificare îți dai seama doar în timpul incidentului. Jurnalele despre o copie de rezervă reușită nu reprezintă o garanție că totul a mers de fapt conform așteptărilor. Este important să verificați în prealabil copia salvată pentru implementare. Adică, rulați procesul de recuperare într-un mediu de testare și priviți rezultatul.
Și puțin despre munca unui administrator de sistem
Nimeni nu copiază datele manual pentru o lungă perioadă de timp. SRC-urile moderne pot face backup pentru aproape orice, trebuie doar să-l configurați corect. Dacă a fost adăugat un nou server, configurați politici: selectați conținutul pentru care se va face backup, specificați parametrii de stocare și aplicați programarea.
În același timp, există încă multă muncă datorită flotei extinse de servere, inclusiv baze de date, sisteme de poștă, clustere de mașini virtuale și resurse de fișiere atât pe Windows, cât și pe Linux/Unix. Angajații care întrețin sistemul de rezervă nu stau inactiv.
În cinstea sărbătorii, aș dori să le urez tuturor administratorilor nervi puternici, mișcări clare și spațiu nesfârșit pentru stocarea backup-urilor!
Sursa: www.habr.com