Tänasel päeval toimetame rõõmuga teile kasulikke näpunäiteid minu kolleegilt Jevgeni Ivanovilt, Veeami tehnilise toe meeskonna meeskonnajuhilt. Seekord jagas Ženja soovitusi varukoopiate ja replika kasutamiseks. Loodan, et need aitavad teil vältida levinud vigu ning teie replikad ja varukoopiad ei muutu kunagi taastamise protsessis nõrgaks kohaks, kui seda peaks vajadus tekkima.

Nii et tere tulemast alla.

Minu eelnevas artiklis oleme käsitlenud, kuidas optimeerida varukoopiate infrastruktuuri komponente, ja vaadanud üle tavalised konfiguratsioonivead. Liigume edasi teise olulise teema juurde – õige taastamise ettevalmistamine ja teostamine. Seda käsitleme samuti tõeliste näidete kaudu, millega tehnilise toe meeskond on kokku puutunud.

Varukoopia ilma restitutsioonita — raha tuulde

Meie poole pöörduvad regulaarselt kasutajad, kes on sattunud sarnastesse keerulistesse olukordadesse: on vaja taastada varukoopia, kuid selle tegemise katsetel satuvad inimesed lahendamatutesse probleemidesse. Ja see probleem ei seisne sugugi varukoopia puudumises, CryptoLockeri tegevuses või muus sarnases. See on 'ainult' piisava tähelepanu puudumine varukoopiate ja replikate taastamisvõimekuse kontrollimisele. Paljud keskenduvad sageli ainult varukoopia loomise protsessile, unustades, et lihtsalt varukoopia olemasolu ei ole imerohi võimalike õnnetuste eest. Tuleb mõista, et taastamine on täiesti eriline protsess, millel on oma eripärad, ja mida peab kindlasti kontrollima ja testima enne tootmisesse viimist. Siin on mõned õpetlikud näited:

Kasutaja kriitilise 20 TB suuruse virtuaalse masina rike ei olnud vastuvõetav. Seisakud on iseenesestmõistetavalt lubamatud, seetõttu alustab administraator kiire taastamise protsessi (VM instant recovery) – 5 minuti pärast on masin taas töökorras. Kuid me peame meeles pidama, et selline masina seisund võib olla ajutine – see tuleb kindlasti migreerida tootmisdatastoorile (datastore). Selles näites, nagu selgus, ei võimaldanud infrastruktuuri võimalused 20 TB andmete kopeerimist mõistliku aja jooksul. Instant recovery seadistustes oli valitud muudatuste salvestamine kettale. C: Veeam Backup & Replication serverites (erinevalt vSphere'i snapshot'ist) – seetõttu täitus loomulikult kettaruumi kiiresti. Hetkel, kui kasutaja toetas, esines VM-il muudatusi, mida ei saanud ignoreerida. See tähendab, et meil on olukord, kus kriitilise masina kiire taastamisprotsess ei ole võimalik – kuidas andmeid päästa?
Pean, aastat tagasi ei mäleta ma kõiki lõpu üksikasju, kuid mäletan, et lõpuks ei leidnud me midagi geniaalset. Klientide poolel lahendati probleem kuidagi, laiendades C: ketast varudest, kopeerides kõige olulisemad failid ja seejärel lülitades VM-i välja ning nii toimus migratsioon. Lõppkokkuvõttes ei toimunud mingit imet.
Kliendi infrastruktuuris töötas üks domeenikontroller ja kõik Veeam Backup & Replication komponendid olid seadistatud DNS-i kasutades. Just nii, te ei kuulnud valesti. Situatsioonide variantide arv oli vähemalt sada, kuid tegelikkus kujunes nii: inimesed plaanisid hooldustöid ja otsustasid lülituda oma domeenikontrolleri koopiale. Nad kasutasid plaanitud lülitust, mis on soovitatav sarnastes olukordades. Esimesel etapil läks kõik hästi, kuid teisel lülitati algne VM lühikeseks ajaks välja, et üle kanda andmeid. Loomulikult lõpetati lülitamise ülesanne kohe veaga, kuna DNS lõpetas töötamise.
Õnneks saime siin olukorraga hakkama, lülitades replika käsitsi sisse vSphere'is (seda operatsiooni ei soovitata iseseisvalt teha, nagu näete järgmises näites). Kuid nagu te mõistate, oli hoolduskäik katkenud ja edasi lükatud. Lisaks pidime käsitsi lisama hostinimede fail C:WindowsSystem32driversetchosts Veeam Backup & Replication serverisse, et tagada korrektne tagasipöördumine.
Teisel kliendil oli kogu varundusinfostruktuur üles ehitatud magnetlintide ümber, samas kui kettale salvestati vaid lühikesed failiahelad. Kui nad soovisid taastada mitmeid faile suurelt failiserverilt, selgus, et ühtegi masinat ei saa kasutada abirepo taastamiseks lintidelt, kuna ühelgi ei olnud piisavalt vaba ruumi. (Magnetlintidelt taastamise ja abirepo kasutamise kohta saate lugeda siit (praegu inglise keeles)).

Arvan, et kõikides kolmes näites olid kasutajad, ütleme nii, illusioonide küüs, arvates, et kui varukoopia on edukalt lõpule viidud, siis ka taastamisega ei teki probleeme. Kuid nagu te mõistate, ei ole see kaugeltki alati nii, mistõttu tuleb taastamiseks valmistuda sama põhjalikult kui varukoopia tegemiseks. Alustuseks tasub tutvuda kasutaja juhendiga, kus on üsna üksikasjalik teave erinevat tüüpi taastamise kohta. Igas lõigus on loetletud nõuded, ettevalmistavad meetmed ja võimalikud piirangud. Teavet magnetlintidelt või riistvaraliste koopiafailide taastamise kohta leiate dokumentatsiooni ja meie artiklite Khabres. Lisaks on rakenduste objektide taastamise ettevalmistamise tegevused Veeami Explorers'i tööriistade abil kirjeldatud jaotises „Planning and preparation“ (planeerimine ja ettevalmistamine) juhenditest , mis on saadaval iga tööriista jaoks. Soovitan nendega hoolikalt tutvuda – see aitab teil süsteemi õigesti taastamiseks ette valmistada, kui see on vajalik. Venekeelsed juhised SQL Serveri andmebaasi taastamiseks on toodud siit.

Miks ei tohi töötada vSphere'i konsoolist replikatega?

Teoreetiliselt on Veeami replikad tavalised virtuaalmajad, millega näiliselt oleks loogiline töötada, kasutades vSphere'i tööriistu, sealhulgas vSphere'i klienti. Siiski, me ei soovita seda teha ja siin on miks: replikale ülemineku protsess Veeami varunduse ja replikatsiooni sees on piisavalt keeruline, nõudes sammude ranget järjekorda (et vajadusel saaks tagasi minna) ja õigeid lõpetavaid toiminguid – vaadake ainult pilti, mis illustreerib protsessi:

Kui te otsustate replikat vSphere'i kliendist aktiveerida, siis ootavad teid tõenäoliselt mitmed probleemid:

Veeami varunduse ja replikatsiooni üleminekumehhanism (näidatud skeemil) ei tööta selle masina jaoks enam.
Andmed Veeami varunduse andmebaasis ei vasta tegelikule virtuaalmasina olekule. Halvimal juhul tuleb andmebaasi parandamiseks redigeerida.
Andmete kaotus on võimalik, nagu sellises näites: kasutaja aktiveeris vSphere client’is replika käsitsi ja otsustas edasi töötada. Mõne aja pärast märkas ta, et replika kuvati endiselt Veeam Backup & Replication konsoolis, ja otsustas selle eemaldada, kuna see polnud enam vajalik. Ta klõpsas sellele hiire parema nupuga ja andis käsu „Kustuta kettalt“. Veeam Backup & Replication kustutas kohe kettalt replikat, mis, olgem ausad, oli juba aktiivselt kasutusel tavalisena VM-ina ning sisaldas vajalikke ja kasulikke andmeid.

Ilmselt on olukordi, kus tuleb siiski replika vSphere client’is aktiveerida – tavaliselt juhtub see siis, kui Veeami server on välja lülitatud ja replika tuleb sisse lülitada viivitusega. Aga kui Veeami serveriga on kõik korras, siis tuleb töötada replikatega just tema konsoolist.

Samuti ei tohiks replikaid eemaldada vSphere client’i kasutades. Veeam Backup & Replication jääb selliste muudatuste osas teadmatusse, mis võib põhjustada vigu ja aegunud andmeid. Kui replika pole enam vajalik, kustutage see Veeami konsooli kaudu, mitte nagu VM vSphere client’ist. Nii on teil alati ajakohane nimekiri replikatest.

„Oh“ — ettevaatust, uuendused!

Siin mõtleme muidugi hüperviisorite ja erinevate rakenduste uuendusi, mida varundatakse Veeamiga. Kui neid vaadata Veeam Backup & Replication'i tööriistadest lähtuvalt, saab uuendusi tinglikult jagada kahte kategooriasse: suured, olulised, mis toovad kaasa palju muudatusi – ja väiksemad.

Alustame esmalt esimesest kategooriast.

Kõige olulisemad uuendused on need, mis on mõeldud hüperviisori jaoks. Enne sellise uuenduse installimist tuleb kindlasti veenduda, et see on Veeam Backup & Replication'i poolt toetatud. Tällised uuendused toovad kaasa palju muudatusi Veeam Backup & Replication'i kasutatavatest raamistike ja API-de teekidest, seetõttu on nende ametlikuks toetamiseks vajalik Veeam Backup & Replication'i koodi uuendada ja põhjalikult testida.

Tuleb arvestada, et näiteks VMware ei paku tarkvaraarendajatele juurdepääsu uusimatele vSphere versioonidele, mistõttu saavad Veeam arendajad ja testijad uue versiooni koos kogu muu moodsa inimkonnaga – seetõttu möödub tavaliselt teatud aeg VMware väljaande ja ametlikult kuulutatud toe vahel. Muudatuste arv ja mitmekesisus on nii suur, et lihtne hotfix ei mahuta neid tõenäoliselt – ametlik toetus kuulutatakse tavaliselt koos Veeam Backup & Replication väljaandmisega.

Tulemusena tekib toona ebamugav olukord, kui pärast uue vSphere versiooni väljalaskmist suureneb tehnilise toe taotluste arv järsult, kuna kasutajad tormavad uue versiooni installimise kallale ning nende varukoopiad lõpetavad kohe toimimise. Meie – Veeami tehniline tugi – peame kasutajatele selgitama, mida nad valesti tegid, paluma neil tagasi pöörduda (kui see on võimalik) või välja mõtlema keerukaid teid ummikust välja pääsemiseks. Seetõttu kontrollige tõsise uuenduse installimise eel alati selle ühilduvust teie kasutatava tarkvaraga, palun!

Kõik eelnevalt öeldu kehtib ka rakenduste kohta, mida te varundate ja lootsite Veeamiga taastada. Veeam Explorers tööriistade seerial on ka toega rakenduste versioonide nimekiri, mis täieneb iga Veeam Backup & Replication'i väljaandega. Seetõttu lugeda vastavat osa uuendatud versiooni installimise eel - olgu selleks Exchange, Oracle või SharePoint - kindlasti üle. Veeam Explorers dokumentatsioonist.

Teise kategooria, st väikeste värskenduste alla kuuluvad näiteks VMware Toolsi uued versioonid, Exchange'i kumulatiivsed värskendused, vSphere'i turvavärskendused jne. Üldiselt ei too need endaga kaasa tõsiseid muudatusi ja enamikul juhtudest ei esine Veeam Backup & Replication'il nendega probleeme. (Seetõttu ei tehakse nende kohta ka ametlikke toote tugiteateid.) Küll aga on meie praktikas olnud juhtumeid, kus isegi sellised värskendused muutsid tavapärase töökorralduse nii oluliselt, et see viis Veeam Backup & Replication'i tõrgeteni. Sellistes olukordades, pärast probleemi kinnitamist, püüavad Veeami insenerid kiiresti välja anda hotfix'i.

Neile, kes valdavad tehnilist inglise keeltKui soovite olla kursis sellega, millega insenerid tegelevad ja millega süsteemiarhitektid ning tugiteenuste spetsialistid silmitsi seisavad, soovitan liituda meie foorumitega. Igast nädalast saadetakse selle tellijatele uudiskiri „Word from Gostev“, autoriks TheRealGostev. Antud vestluses räägib Anton Gostev, tootejuhtimise osakonna juht, hiljuti leitud probleemidest (ja mitte ainult Veeami poolel), tuleviku versioonide plaanidest ja IT-maailma uudistest. Kui soovite rohkem teavet, rääkige foorumi teemadest – kui mõnel kliendil on toote tööga seoses probleem pärast värskendust, on tõenäoliselt keegi sellest foorumil juba kirjutanud.

Kuidas te mõistate, võivad plaastrid ja värskendused tekitada probleeme mitte ainult varundusega, vaid ka rakendustega, mille jaoks need varukoopiad tehakse. Ja siin tulevad appi virtuaallaborid – Veeam DataLabs. Olete tõenäoliselt kuulnud funktsionaalsusest SureBackup, mis on mõeldud varukoopiate kontrollimiseks. See põhineb just DataLabsi kasutamisel, luues isoleeritud keskkonna, kus saab näiteks testida värskendusi enne nende tootmisse paigaldamist. Soovitan seda kindlasti teha – säästate end paljude närvirakkude arvelt. Ja kui keegi ei tea veel SureBackupist, soovitan lugeda. dokumentatsiooni.

Täna on mul kõik, aitäh tähelepanu eest!