Danes z veseljem predstavljam koristne nasvete mojega kolega Evgenija Ivanova, vodje tehnične podporne ekipe Veeam. Tokrat je Ženja delil priporočila za delo z varnostnimi kopijami in replikami. Upam, da vam bodo v pomoč, da se izognete tipičnim napakam, in da vaši replikam in varnostnim kopijam nikoli ne bodo 'šibka točka' v procesu obnove, če bo to potrebno.

Torej, dobrodošli pod kat.

V prejšnjem članku članku smo se ukvarjali z optimizacijo obremenitve infrastructure za varovanje podatkov in preučevali tipične napake pri konfiguraciji. Sedaj se selimo na drugo pomembno temo – ustrezno pripravo in izvedbo obnove. Tudi to bomo obravnavali na realnih primerih, s katerimi se je ekipa tehnične podpore srečala.

Varnostna kopija brez preizkusa – denar stran

Redno nas kontaktirajo uporabniki, ki so se znašli v podobnih težavah: potrebno je izvesti obnovo iz varnostne kopije, vendar se ob poskusu naletijo na nerešljiv problem. In ta problem ni pomanjkanje varnostne kopije, delovanje CryptoLockerja ali kaj podobnega. Gre le za nezadostno pozornost pri preverjanju varnostnih kopij in replik z vidika možnosti obnove. Mnogi se pogosto osredotočajo izključno na proces ustvarjanja varnostne kopije, pozabljajo pa, da samo to, da imamo varnostno kopijo, ni rešitev za vse težave. Treba je razumeti, da je obnova povsem drug proces, ki ima svoje posebnosti in ga je nujno potrebno nadzorovati in testirati pred uporabo v produkciji. Tukaj je nekaj prikaznih primerov:

Uporabniku je odpovedal delovanje kritične virtualne naprave velikosti 20 TB. Zaustavitve so, seveda, nedopustne, in administrator prične proces takojšnje obnove (VM instant recovery) – po 5 minutah je naprava zagnana. A ne pozabimo, da je takšno stanje naprave mogoče uporabljati le začasno – nujno jo je treba migrirati na produkcijski podatkovni prostor (datastore). V tem primeru pa se je izkazalo, da infrastruktura ni mogla skopirati 20 TB podatkov v razumnem času. V nastavitvah procesa instant recovery je bilo izbrano shranjevanje sprememb na disk. Iz: Veeam Backup & Replication servers (unlike the vSphere snapshot) – as a result, of course, the free disk space quickly filled up. By the time the user contacted support, the VM had changes that could not be ignored. That is to say, we have a situation where it is impossible to quickly finalize the process of instant recovery of a critical machine – how to save the data here?
To be honest, I can’t recall all the details of the conclusion after so many years, but I remember that in the end, we didn’t come up with anything genius. The clients on their side managed to solve this problem, expanding the C: drive from reserves, copied the most important files, and only then turned off the VM and migrated it. In short, there was no miracle.
In the user’s infrastructure, there was one domain controller, and all components of Veeam Backup & Replication were configured using DNS. Yes, yes, you heard that right. There were a hundred potential scenarios, at least, but in reality, it all went like this: people scheduled maintenance and decided to switch to a replica of their domain controller. They initiated the planned switch, which is generally recommended in such situations. At the first stage, everything went smoothly, but at the second, the original VM was briefly powered off to transfer the remaining data. Naturally, the switch task immediately failed due to DNS stopping working.
Fortunately, we managed to handle the situation by starting the replica manually from vSphere (actually, this operation is not recommended to perform on your own, as you will see from the next example). But, as you understand, the maintenance process was interrupted and postponed. Additionally, we had to manually add the host names to the file C:WindowsSystem32driversetchosts on the Veeam Backup & Replication server to ensure correctness during the reverse switch.
Pri enem iz naših strank je bila celotna infrastruktura varnostnega kopiranja zgrajena okoli magnetnih trakov, na diskih pa so bile shranjene le kratke verige datotek. Ko so potrebovali obnoviti vrsto datotek z velikega datotečnega strežnika, se je izkazalo, da nobenega računalnika ni bilo mogoče uporabiti kot pomožni repozitorij za obnovitev iz trakov, ker na nobeni ni bilo dovolj prostega prostora. (O obnovitvi z magnetnih trakov neposredno in z uporabo pomožnega repozitorija lahko preberete ovde (zaenkrat v angleščini)).

Menim, da so bili uporabniki v vseh treh primerih nekako ujeti v iluzijo – predpostavljali so, da če je varnostno kopiranje potekalo uspešno, tudi pri obnovitvi ne bo težav. A kot razumete, to nikakor ni vedno res, zato se je na obnovitev treba pripraviti prav tako skrbno kot na varnostno kopiranje. Najprej je smiselno preučiti uporabniški priročnik, kjer je navedeno dokaj podrobne informacije o različnih vrstah obnovitve. V začetku vsakogar odstavka so navedene zahteve, pripravljalni postopki in morebitne omejitve. Opis obnovitve iz magnetnih trakov ali iz strojnih posnetkov SHD lahko najdete v razdelkih dokumentacije in na naših člančkih na Habré. Poleg tega so postopki za pripravo obnovitve objektov aplikacij z orodji Veeam Explorers opisani v razdelku „Načrtovanje in priprava“. navodila za vsako od orodij. Priporočam, da se z njimi natančno seznanite – to vam bo pomagalo pravilno pripraviti sistem za obnovitev v primeru potrebe. V ruščini so navodila za obnovitev baze podatkov SQL Server navedena ovde.

Zakaj ne bi smeli delati z replikami iz vmesnika vSphere?

Po ideji, replikami Veeam predstavljajo običajne virtualne stroje, s katerimi bi se zdelo smiselno delati, pri čemer se uporabljajo orodja vSphere, zlasti vSphere client. Vendar tega ne priporočamo, in to je razlog: preklop na replikacijo v Veeam Backup & Replication je precej zapleten postopek, ki zahteva strogo zaporedno izvajanje korakov (da, v primeru težav, lahko nazaj korak) in pravilno zaključna dejanja – samo poglejte sliko, ki ponazarja postopek:

Če se odločite aktivirati replikacijo iz vSphere klienta, vas najverjetneje čaka vrsta težav:

Mehanizem preklapljanja na replikacijo iz Veeam Backup & replication (prikazan na shemi) za to napravo ne bo več deloval.
Podatki v Veeam Backup bazi ne bodo ustrezali dejanskemu stanju VM. V najslabšem primeru bo potrebno urediti bazo.
Možna je celo izguba podatkov, kot v tem primeru: uporabnik je ročno aktiviral replikacijo v vSphere klientu in se odločil, da nadaljuje z njo. Čez nekaj časa je opazil, da se replikacija še vedno prikazuje v Veeam Backup & Replication konzoli in se je odločil, da jo odstrani, ker je ni več potreboval. Kliknil je nanjo z desnim gumbom in dal ukaz «Izbriši z disk». Veeam Backup & Replication je takoj izbrisal replikacijo z diska, ki je bila, mimogrede, že v polni uporabi kot običajen VM in je vsebovala potrebne in uporabne podatke.

Seveda obstajajo situacije, ko je le potrebno aktivirati replikacijo iz vSphere klienta – ponavadi gre za primere, ko je Veeam strežnik izključen, replikacijo pa je potrebna aktivirati s zamudo. Toda če je z Veeam strežnikom vse v redu, je treba z replikacijami delati prav iz njegove konzole.

Prav tako ne smete odstranjevati replikacij s pomočjo vSphere klienta. Veeam Backup & Replication bo ostal v nevednosti glede takega spremembe, kar lahko privede do napak in zastare podatkov. Če replikacija ni več potrebna, jo odstranite s pomočjo Veeam konzole in ne kot VM iz vSphere klienta. Tako boste vedno imeli aktualen seznam replikacij.

«O» – pozor, posodobitve!

Tukaj imamo seveda v mislih posodobitve za hiper-vizorje in različne aplikacije, ki se varnostno kopirajo s pomočjo Veeam. Če jih gledamo z vidika dela z Veeam Backup & Replication, jih lahko pogojno razdelimo na 2 kategoriji: velike, resne, ki prinašajo ogromno sprememb – in manjše.

Najprej si oglejmo prvo kategorijo.

Najpomembnejša posodobitev so tiste, ki so namenjene hipervizorju. Pred namestitvijo take posodobitve se je nujno prepričati, da jo podpira Veeam Backup & Replication. Takšne posodobitve prinašajo številne spremembe v knjižnicah in API vmesnikih, ki jih uporablja Veeam Backup & Replication, zato je za uradno potrditev njihovega delovanja potrebno posodobiti kodo Veeam Backup & Replication ter opraviti temeljito testiranje.

Treba je tudi upoštevati, da VMware ne zagotavlja predhodnega dostopa do najnovejših različic vSphere za proizvajalce programske opreme, zato razvijalci in testniki Veeam dobijo novo različico hkrati s celotnim naprednim človeštvom – zato običajno mine določen čas med izidom VMware in uradno objavljeno podporo. Število in raznolikost potrebnih sprememb je takšna, da je malo verjetno, da bi jih lahko vključili v enostavno popravilo – in uradna podpora se običajno objavi skupaj z izidom različice Veeam Backup & Replication.

Posledično se zgodi tisti neroden trenutek, ko po izidu nove različice vSphere število zahtevkov za tehnično podporo nenadoma naraste, saj uporabniki z obratno glavo hitijo namestiti novo različico, in njihovi varnostni kopiji se seveda takoj prenehajo delovati. Mi – tehnična podpora Veeam – moramo uporabnikom pojasniti, kaj natančno so naredili narobe, jih prositi, naj se vrnejo nazaj (če je to možno), ali pa izmišljati zapletene poti za izhod iz zagate. Zato pred namestitvijo resne posodobitve nujno preverite njeno združljivost z delujočo programsko opremo, vas zelo prosim!

Vse zgoraj navedeno velja tudi za aplikacije, ki jih varnostno kopirate in upate, da jih boste obnovili s pomočjo Veeam. Linija orodij Veeam Explorers ima prav tako seznam podprtih različic ustreznih aplikacij, ki se dopolnjuje z vsakim izidom Veeam Backup & Replication. Zato pred namestitvijo nove različice vaše aplikacije – naj bo to Exchange, Oracle ali SharePoint — obvezno preberite ustrezen razdelek dokumentacije Veeam Explorers.

V drugo kategorijo, torej k manjšim posodobitvam, spadajo, na primer, nove različice VMware Tools, kumulativne posodobitve Exchange, posodobitve varnosti vSphere itd. Običajno ne prinašajo resnih sprememb in v večini primerov Veeam Backup & Replication z njimi nima težav. (Zato za njih tudi ni javnih napovedi o uradni podpori v produktu.) Vendar smo v naši praksi naleteli na primere, ko so take posodobitve tako pomembno spremenile ustaljen potek stvari, da so povzročile napake pri delovanju Veeam Backup & Replication. V takih situacijah inženirji Veeam po potrditvi težave hitro poskušajo izvesti popravek.

Tistim, ki obvladajo tehnični angleški jezikČe želite biti na tekočem s tem, na čem delajo inženirji ter s čem se srečujejo sistemski arhitekti in strokovnjaki za tehnično podporo, priporočam, da se naročite na naša forum. Vsak teden za njegove naročnike izide e-novičnik "Word from Gostev" avtorstva TheRealGostev. V njem Anton Gostev, ki vodi oddelek za upravljanje produktov, poroča o nedavno odkritih težavah (in ne le na strani Veeam), načrtih za nove različice in novicah iz sveta IT. Če potrebujete več informacij, lahko preberete teme foruma – če ima kdo od strank težave z delovanjem produkta po kakšni posodobitvi, je verjetno že napisal o tem na forumu.

Kot razumete, lahko popravki in posodobitve povzročijo težave ne le z varnostnimi kopijami, temveč tudi z aplikacijami, za katere se te varnostne kopije ustvarjajo. In tu vam lahko pomagajo virtualne laboratorije — Veeam DataLabs. Verjetno ste slišali za funkcionalnost SureBackup, ki je namenjena preverjanju varnostnih kopij. Ta temelji prav na uporabi DataLabs, s ustvarjanjem izoliranega okolja, v katerem je mogoče, med drugim, testirati posodobitve pred njihovo namestitvijo v produkcijo. Priporočam, da tako naredite – prihranili si boste ogromno živcev. Če pa kdo še ne ve za SureBackup, priporočam, da prebere dokumentacijo.

Verjetno je to za danes vse, hvala za pozornost!