Astăzi, cu plăcere, vă prezint din nou sfaturile utile ale colegului meu Evgeny Ivanov, liderul echipei de suport tehnic Veeam. De data aceasta, Zhenia a împărtășit recomandări pentru lucrul cu backup-urile și replicile. Sper că acestea vă vor ajuta să evitați greșelile tipice și ca replicile și backup-urile dumneavoastră să nu fie niciodată „punctul slab” în procesul de recuperare, dacă va fi necesar.

Așadar, bun venit sub cat.

În anteriorul meu pe care l-ați citit am analizat modul de optimizare a încărcării pe componentele infrastructurii de backup și am discutat greșelile comune de configurare. Trecem la o altă temă importantă – pregătirea și realizarea corectă a recuperării. Aceasta o vom analiza și prin exemple reale cu care s-a confruntat echipa de suport tehnic.

Backup fără restaurant – bani aruncați pe fereastră

Utilizatorii se adresează regulat la noi, fiind în situații dificile asemănătoare: este necesară recuperarea dintr-un backup, dar, la încercarea de a face acest lucru, oamenii se confruntă cu o problemă imposibil de rezolvat pentru ei. Iar această problemă nu este lipsa unei copii de rezervă, activitatea CryptoLocker sau ceva similar. Este „doar” lipsa de atenție suficientă la verificarea backup-urilor și replicilor pentru posibilitatea de recuperare. Mulți se concentrează exclusiv pe procesul de creare a unui backup, uitând că simpla existență a unei copii de rezervă nu este o panacee pentru eventualele probleme. Trebuie să înțelegem că recuperarea este un proces complet diferit, cu propriile sale caracteristici, care necesită control și testare înainte de implementarea în producție. Iată câteva exemple sugestive:

Un utilizator a experimentat o defecțiune a unei mașini virtuale critice de 20 TB. Timpul de nefuncționare, evident, este inacceptabil, iar administratorul inițiază procesul de recuperare instantanee a mașinii virtuale (VM instant recovery) – în 5 minute, mașina este repusă în funcțiune. Însă, ne amintim că această stare a mașinii poate fi utilizată temporar – trebuie să fie migrată pe datastore de producție. Iar în acest exemplu, s-a constatat că infrastructura nu permitea copierea celor 20 TB de date într-un timp rezonabil. Însă în setările procesului de recuperare instantanee, a fost ales să se păstreze modificările pe disc. S: Serverele Veeam Backup & Replication (spre deosebire de snapshot-ul vSphere) – astfel, desigur, spațiul liber pe disc s-a umplut rapid. Până în momentul în care utilizatorul a contactat suportul, VM-urile au suferit modificări care nu puteau fi ignorate. Deci, avem o situație în care nu este posibil să finalizăm rapid procesul de recuperare instantanee a unei mașini critice – cum putem salva datele?
Trebuie să recunosc că, din cauza trecerii timpului, nu-mi amintesc toate detaliile finale, dar îmi amintesc că, în cele din urmă, nu am găsit nimic genial. Clienții și-au rezolvat problema într-un fel sau altul, extinzând discul C: din rezerve, copiază cele mai importante fișiere și apoi au oprit VM-ul pe care l-au migrat. Așadar, nu a avut loc nicio minune.
În infrastructura utilizatorului, a funcționat un singur controller de domeniu, și toate componentele Veeam Backup & Replication au fost configurate folosind DNS. Da, ați auzit bine. Au existat sute de posibile evoluții, dar realitatea este că: oamenii au planificat o intervenție tehnică și au decis să comute pe replica controller-ului de domeniu. Au folosit comutarea planificată, ceea ce este recomandat în astfel de situații. În prima etapă, totul a decurs bine, iar în a doua, VM-ul inițial a fost oprit temporar pentru a transfera restul datelor. Desigur, sarcina de comutare s-a încheiat imediat cu o eroare, deoarece DNS-ul a încetat să mai funcționeze.
Din fericire, am reușit să gestionăm situația aici, activând replica manual din vSphere (de fapt, această operațiune nu este recomandat să fie efectuată singuri, așa cum veți vedea în următorul exemplu). Dar, așa cum înțelegeți, procesul de întreținere a fost întrerupt și amânat. În plus, a trebuit să introducem manual numele gazdelor în fișierul C:WindowsSystem32driversetchosts pe serverul Veeam Backup & Replication, pentru a asigura corectitudinea la comutarea inversă.
Un alt client a avut întreaga infrastructură de backup construită în jurul unităților cu bandă magnetică, iar pe disc erau stocate doar scurte lanțuri de fișiere. Când a fost necesar să recupereze câteva fișiere de pe un server de fișiere mare, s-a dovedit că nicio mașină nu putea fi folosită ca repositar auxiliar pentru restaurarea de pe bandă, deoarece niciuna nu avea suficient spațiu liber. (Despre restaurarea de pe bandă magnetică, atât direct, cât și folosind un repositar auxiliar, se poate citi aici (deocamdată în engleză)).

Cred că în toate cele trei exemple, utilizatorii, așa-zicând, erau prizonieri ai iluziei – ei au presupus că dacă backup-ul a fost realizat cu succes, atunci nu vor fi probleme cu restaurarea. Dar, după cum înțelegeți, acest lucru nu este întotdeauna adevărat, iar prin urmare, trebuie să ne pregătim pentru restaurare la fel de riguros ca și pentru backup. În primul rând, este bine să studiem manualul utilizatorului, unde se găsește informații destul de detaliate despre diferitele tipuri de restaurare. La începutul fiecărui paragraf sunt enumerate cerințele, acțiunile pregătitoare și posibilele limitări. Descrierea restaurării de pe benzi magnetice sau din instantanee hardware ale stocării poate fi găsită în secțiunile documentației și în articole de pe Habr. În plus, acțiunile de pregătire pentru restaurarea obiectelor aplicațiilor folosind instrumentele Veeam Explorers sunt descrise în secțiunea „Planificare și pregătire” ghid pentru fiecare dintre instrumente. Îți recomand să te familiarizezi cu ele – acest lucru te va ajuta să pregătești corect sistemul pentru restaurare în caz de necesitate. În limba română, instrucțiunile pentru restaurarea bazei de date SQL Server sunt prezentate aici.

De ce nu trebuie să lucrăm cu replicile din consola vSphere?

Teoretic, replicile Veeam reprezintă mașini virtuale obișnuite, cu care, părea logic, să lucrăm folosind instrumentele vSphere, în special clientul vSphere. Cu toate acestea, nu recomandăm acest lucru, și iată de ce: comutarea pe replica în Veeam Backup & Replication este un proces destul de complicat, care necesită o execuție strict secvențială a pașilor (pentru a putea reveni la un pas anterior în caz de ceva) și acțiuni finale corecte – uită-te doar la imaginea care ilustrează procesul:

Dacă încercați să activați replica din clientul vSphere, este foarte probabil să întâlniți o serie de probleme ulterior:

Mecanismul de comutare la replica din Veeam Backup & Replication (prezentat în diagramă) nu va mai funcționa pentru această mașină.
Datele din baza Veeam Backup nu vor corespunde stării reale a VM-ului. În cel mai rău caz, va trebui să editați baza pentru a o remedia.
Este posibil chiar să pierdeți date, așa cum se întâmplă în acest exemplu: utilizatorul a activat manual replica în clientul vSphere și a decis să continue să lucreze cu aceasta. După un timp, a observat că replica este încă vizibilă în consola Veeam Backup & Replication și a decis să o elimine, deoarece nu mai avea nevoie de ea. A făcut clic pe ea cu butonul din dreapta și a dat comanda „Șterge de pe disc”. Veeam Backup & Replication a șters imediat replica de pe disc, care, ca un mic detaliu, era folosită ca un VM obișnuit și conținea date necesare și utile.

Desigur, există situații în care este necesar totuși să activați replica din clientul vSphere – de obicei, acestea sunt cazuri în care serverul Veeam este oprit, iar replica trebuie activată cu întârziere. Dar dacă serverul Veeam funcționează corect, atunci trebuie să lucrați cu replicile exclusiv din consola acestuia.

De asemenea, nu ar trebui să ștergeți replicile folosind clientul vSphere. Veeam Backup & Replication va rămâne în necunoștință despre o astfel de modificare, ceea ce poate provoca erori și date învechite. Dacă nu mai aveți nevoie de replică, ștergeți-o prin intermediul consolei Veeam, și nu ca un VM din clientul vSphere. Așa veți avea întotdeauna o listă actualizată a replicilor.

„A” — atenție, actualizări!

Aici ne referim, desigur, la actualizările pentru hyper-vizori și diverse aplicații care sunt backup-uite cu ajutorul Veeam. Dacă le privim prin prisma funcționării Veeam Backup & Replication, actualizările pot fi împărțite, în mod condiționat, în două categorii: majore, serioase, care aduc multe modificări – și minore.

Să analizăm mai întâi prima categorie.

Cele mai importante actualizări sunt cele destinate hypervizorului. Înainte de a instala o astfel de actualizare, este absolut necesar să vă asigurați că aceasta este acceptată de Veeam Backup & Replication. Aceste actualizări aduc numeroase modificări bibliotecilor și interfețelor API utilizate de Veeam Backup & Replication, prin urmare, pentru a anunța oficial suportul pentru acestea, este nevoie să actualizați codul Veeam Backup & Replication și să efectuați teste riguroase.

De asemenea, trebuie să țineți cont că, de exemplu, VMware nu oferă acces anticipat la cele mai recente versiuni de vSphere pentru dezvoltatorii de software, așa că dezvoltatorii și testerii Veeam primesc noua versiune simultan cu întreaga comunitate progresivă – astfel, între lansarea VMware și anunțarea oficială a suportului de obicei trece un anumit timp. Cantitatea și diversitatea modificărilor necesare sunt atât de mari, încât este puțin probabil să se încadreze într-un simplu hotfix – iar suportul oficial este, de obicei, anunțat împreună cu lansarea versiunii Veeam Backup & Replication.

În consecință, există acel moment stânjenitor când, după lansarea unei noi versiuni de vSphere, numărul solicitărilor de suport tehnic crește brusc, deoarece utilizatorii se grăbesc să instaleze noua versiune, iar backup-urile lor, desigur, încetează imediat să funcționeze. Noi, echipa de suport Veeam, suntem nevoiți să le explicăm utilizatorilor ce anume au făcut greșit, să îi rugăm să revină la versiunea anterioară (dacă este posibil) sau să găsim soluții elaborate pentru a ieși din impas. Prin urmare, înainte de a instala o actualizare serioasă, vă rog să verificați compatibilitatea acesteia cu software-ul pe care îl utilizați!

Tot ce a fost spus mai sus se aplică și aplicațiilor pe care le salvați și pe care intenționați să le restaurați cu ajutorul Veeam. Gama de instrumente Veeam Explorers are, de asemenea, o listă de versiuni acceptate ale aplicațiilor corespunzătoare, care este completată cu fiecare lansare a Veeam Backup & Replication. Așadar, înainte de a instala noua versiune a aplicației dumneavoastră – fie că este vorba despre Exchange, Oracle sau SharePoint – citiți cu siguranță secțiunea relevantă a documentației Veeam Explorers.

La a doua categorie, adică actualizările mai mici, includ, de exemplu, noi versiuni ale VMware Tools, actualizări cumulative pentru Exchange, actualizări de securitate pentru vSphere etc. De obicei, acestea nu aduc modificări semnificative și, în majoritatea cazurilor, Veeam Backup & Replication nu întâmpină probleme cu acestea. (De aceea nu există anunțuri publice despre suportul oficial în produs.) Totuși, în practica noastră, au existat cazuri în care aceste actualizări au schimbat atât de mult modul obișnuit de funcționare încât au dus la erori în Veeam Backup & Replication. În astfel de situații, după confirmarea problemei, inginerii Veeam se străduiesc să emită rapid un hotfix.

Pentru cei care stăpânesc engleza tehnicăDacă doriți să fiți la curent cu ceea ce lucrează inginerii și cu provocările cu care se confruntă arhitecții de sistem și specialiștii în suport tehnic, vă recomand să vă abonați la forumurile noastre. În fiecare săptămână, pentru abonați, apare un newsletter intitulat „Word from Gostev”, scris de TheRealGostev. În acesta, Anton Gostev, șeful departamentului de management al produselor, vorbește despre problemele recente întâlnite (nu doar pe partea Veeam), planurile pentru noile versiuni și noutăți din lumea IT. Dacă aveți nevoie de mai multe informații, puteți consulta subiectele forumului - dacă un client descoperă o problemă cu funcționarea produsului după o actualizare, cel mai probabil a scris deja despre aceasta pe forum.

După cum vă închipuiți, patch-urile și actualizările pot cauza probleme nu doar cu backup-urile, ci și cu aplicațiile pentru care se fac aceste backup-uri. Aici vă pot ajuta laboratoarele virtuale - Veeam DataLabs. Probabil ați auzit despre funcționalitatea SureBackup, destinat verificării backup-urilor. Aceasta se bazează tocmai pe utilizarea DataLabs, creând un mediu izolat în care puteți testa, în special, actualizările înainte de a le aplica în producție. Vă recomand cu tărie să faceți astfel - veți economisi multe neuroni. Iar dacă cineva nu știe despre SureBackup, recomand să citiți documentație.

Ei bine, astăzi am terminat, mulțumesc pentru atenție!