Ma ismét örömmel mutatom be nektek a hasznos tippeket kollégámtól, Jevgenyij Ivanovtól, a Veeam műszaki támogatásának csapatvezetőjétől. Ezúttal Jevgenyij megosztotta az ajánlásait a biztonsági mentésekkel és replikákkal való munkához. Remélem, segítenek elkerülni a tipikus hibákat, és a replikák és biztonsági mentések soha nem jelentenek "gyenge pontot" a helyreállítási folyamat során, ha szükség lenne rá.

Tehát, üdvözlöm a cikkben.

Az előző írásomban a Spotify döntéshozatali módszertanáról. Egyre több felhasználó preferálja a zenehallgatást mobilon a streaming szolgáltatásban, de a cégnél túlnyomórészt webprogramozók dolgoznak. A Spotify elemezte ezt a helyzetet, és úgy döntött, hogy több mobilfejlesztőt vesz fel, valamint átnevezi a webes szakembereket új irányba: azzal foglalkoztunk, hogyan optimalizáljuk a biztonsági mentési infrastruktúra komponenseinek terhelését, és áttekintettük a tipikus konfigurációs hibákat. Most egy másik fontos témára térünk rá – a helyreállítás helyes előkészítésére és végrehajtására. Ezt is valós példákon fogjuk elemezni, amelyekkel a műszaki támogatás csapata találkozott.

Biztonsági mentés étterem nélkül – pénzkidobás

Rendszeresen fordulnak hozzánk olyan felhasználók, akik hasonló nehéz helyzetekbe kerültek: szükséges biztonsági mentésből helyreállítást végezni, de a folyamat során olyan megoldhatatlan problémákba ütköznek, amelyekkel nem bírnak. És ez a probléma nem más, mint a biztonsági mentések és replikák helyreállíthatóságának ellenőrzésére fordított figyelem hiánya. Sokan gyakran kizárólag a biztonsági mentés létrehozására összpontosítanak, elfeledkezve arról, hogy a biztonsági másolat puszta léte nem gyógymód a lehetséges problémákra. Fontos megérteni, hogy a helyreállítás egy teljesen más folyamat, amelynek saját sajátosságai vannak, és amelyet mindenképpen ellenőrizni és tesztelni kell a termelésbe való indítás előtt. Íme néhány figyelemre méltó példa:

Felhasználónál egy 20 TB-os kritikus virtuális gép hibásodott meg. Az állásidő természetesen nem elfogadható, ezért az adminisztrátor megkezdi az azonnali helyreállítási folyamatot (VM instant recovery) – 5 percen belül a gép újra üzemel. De emlékezzünk, hogy az ilyen gépállapotot csak átmenetileg lehet alkalmazni – azt mindenképpen át kell migrálni a termelési adattárolóba (datastore). Ebben a példában kiderült, hogy az infrastruktúra lehetőségei nem tették lehetővé 20 TB adat ésszerű időn belüli másolását. Az azonnali helyreállítási folyamat beállításaiban pedig úgy lett megadva, hogy a módosításokat a lemezen kell tárolni. A: A Veeam Backup & Replication szerverek (ellentétben a vSphere pillanatképeivel) miatt az eredmény természetesen gyorsan feltöltötte a lemezen lévő szabad helyet. Mire a felhasználó a támogatásra fordult, a virtuális gépnek olyan változásai voltak, amelyeket nem lehetett figyelmen kívül hagyni. Tehát olyan helyzet állt elő, amikor lehetetlen volt gyorsan befejezni egy kritikus gép azonnali helyreállítási folyamatát – hogyan lehetne megmenteni az adatokat?
Bevallom, mivel már régóta eltelt az idő, nem emlékszem minden részletére a befejezésnek, de tudom, hogy végül nem találtunk semmi zseniálisat. Az ügyfelek a saját oldalukon többé-kevésbé megoldották ezt a problémát, a C: meghajtót kiterjesztve a tartalékokból, átmásolták a legfontosabb fájlokat, és csak utána állították le a virtuális gépet, és így migráltak. Összességében nem történt csoda.
A felhasználó infrastruktúrájában egyetlen tartományvezérlő működött, és az összes Veeam Backup & Replication komponens DNS használatával lett beállítva. Igen, jól hallottad. Számtalan forgatókönyv volt, de a valóság a következőképpen alakult: az emberek karbantartást terveztek, és úgy döntöttek, hogy átállnak a tartományvezérlőjük replikájára. Ütemezett átkapcsolást használtak, ami a hasonló helyzetekben javasolt. Az első fázisban minden rendben ment, a második fázisban pedig az eredeti virtuális gépet rövid időre leállították, hogy áthelyezzék az adatok maradékát. Természetesen az átkapcsolási feladat azonnal hibával fejeződött be, mivel a DNS megállt.
Szerencsére itt sikerült kezelni a helyzetet, amikor manuálisan elindítottuk a replikát a vSphere-ből (ezt az eljárást önállóan elvégezni nem ajánlott, ahogy a következő példából is látható lesz). De ahogy érted, a karbantartási folyamat megszakadt és elhalasztásra került. Ráadásul kézzel kellett bevinni a gépek neveit a fájlba C:WindowsSystem32driversetchosts a Veeam Backup & Replication szerveren, hogy biztosítsuk a helyes működést az visszaállás során.
Egy másik ügyfélnél a biztonsági mentési infrastruktúra mágneslemezek köré épült, míg a merevlemezen csak rövid fájcsoportok tárolódtak. Amikor fájlokat kellett helyreállítani egy nagy fájlszerverről, kiderült, hogy egyetlen gép sem használható segédtárolóként a szalagról való helyreállításhoz, mivel egyiken sem volt elég szabad hely. (A mágneslemezről való helyreállításról közvetlenül és segédtároló használatával olvashat) itt (jelenleg csak angol nyelven).

Úgy gondolom, hogy mindhárom példa esetében a felhasználók, mondhatni, illúziók fogságában voltak – azt feltételezték, hogy ha a biztonsági mentés sikeres volt, akkor a helyreállítással sem lesz probléma. De, ahogy tudjuk, ez nem mindig van így, ezért a helyreállítást ugyanolyan gondossággal kell megtervezni, mint a biztonsági mentést. Először is érdemes tanulmányozni a felhasználói kézikönyvet, amely részletes információt tartalmaz a különböző helyreállítási módszerekről. Minden bekezdés elején felsorolják a követelményeket, a felkészítő lépéseket és a lehetséges korlátozásokat. A mágneslemezről vagy a tárolórendszerek hardveres pillanatképeiből való helyreállítás leírását a dokumentáció szakaszaiban, valamint a mi cikkekben blogunkban a Habr-n találja. Ezenkívül az alkalmazásobjektumok helyreállításának előkészítő lépései a Veeam Explorers eszközeivel a "Tervezés és előkészítés" (Planning and preparation) szakaszban találhatók, A kulcs feltöréséhez szükséges inicializáló vektorok száma nem korlátozott. Ez azért van, mert egyes vektorok gyengébbek és több információt veszítenek a kulcsról, mint mások. Általában az inicializáló vektorok keverednek erősebbekkel. Tehát, ha luck van, a kulcsot már 20 000 inicializáló vektorral feltörheti. Azonban gyakran ez sem elegendő, minden eszköz számára. Ajánlom, hogy alaposan tanulmányozza át őket – ez segít Önnek megfelelően felkészíteni a rendszert a helyreállításra, ha szükséges. Orosz nyelven a SQL Server adatbázis helyreállítási útmutatásai találhatók. itt.

Miért ne dolgozzunk a vSphere konzolból a replikákkal?

Elvileg a Veeam replikái normál virtuális gépek, amelyekkel logikusan úgy tűnik, hogy a vSphere eszközökkel kellene dolgozni, különösen a vSphere klienssel. Azonban ezt nem ajánljuk, és ennek okai a következők: a Veeam Backup & Replication replikájára való áttérés egy meglehetősen bonyolult folyamat, amely szigorú lépésről-lépésre történő végrehajtást igényel (annak érdekében, hogy bármikor vissza lehessen lépni) és megfelelő befejező lépéseket – csak nézze meg azt a képet, amely szemlélteti a folyamatot:

Ha mégis úgy dönt, hogy bekapcsolja a replikát a vSphere kliensből, akkor a jövőben valószínűleg számos probléma vár önre:

A Veeam Backup & Replication (a diagramon bemutatva) replikára való váltási mechanizmus ennél a gépnél már nem fog működni.
Az adatok a Veeam Backup adatbázisában nem fognak megfelelni a VM valós állapotának. A legrosszabb esetben a javításhoz az adatbázis szerkesztése szükséges.
Adatvesztés is bekövetkezhet, mint ebben az esetben: a felhasználó manuálisan bekapcsolta a replikát a vSphere kliensben, és úgy döntött, hogy továbbra is dolgozik vele. Néhány idő múlva észrevette, hogy a replikát továbbra is látható a Veeam Backup & Replication konzolban, és úgy döntött, hogy eltávolítja a feleslegesség miatt. Jobb kattintással rákattintott és kiadta a parancsot „Delete from disk”. A Veeam Backup & Replication azonnal eltávolította a lemezről a replikát, amely, mondanom sem kell, már aktívan használt, mint egy normál VM, és szükséges, hasznos adatokat tartalmazott.

Természetesen vannak olyan helyzetek, amikor mindenképpen bekapcsolni kell a replikát a vSphere kliensből – általában ezek olyan esetek, amikor a Veeam szerver ki van kapcsolva, és a replikát késleltetéssel kell bekapcsolni. De ha a Veeam szerver rendben van, akkor a replikákkal a konzoljából kell dolgozni.

Az sem javasolt, hogy a replikákat az vSphere kliens használatával töröljük. A Veeam Backup & Replication nem lesz tisztában ezzel a változással, ami hibákhoz és elavult adatokhoz vezethet. Ha a replikára már nincs szüksége, a Veeam konzolján keresztül törölje, és ne mint VM-t az vSphere kliensből. Így mindig aktuális replikák listájával rendelkezik.

„O” – óvatosan, frissítések!

Itt természetesen a hipervizorok és a különböző alkalmazások frissítéseire gondolunk, amelyeket a Veeam segítségével készítenek. Ha a Veeam Backup & Replication szempontjából nézzük őket, a frissítéseket két kategóriába sorolhatjuk: nagy, komoly, sok változást hozó – és kisebb frissítések.

Kezdjük az első kategóriával.

A legfontosabb frissítések azok, amelyek a hypervisorhoz készültek. Mielőtt ilyen frissítést telepítene, mindenképpen győződjön meg róla, hogy azt támogatja a Veeam Backup & Replication. Ilyen frissítések sok változást hoznak a Veeam Backup & Replication által használt könyvtárak és API-k interfészeiben, ezért a támogatás hivatalos bejelentéséhez szükséges a Veeam Backup & Replication kódjának frissítése és alapos tesztelés elvégzése.

Továbbá érdemes figyelembe venni, hogy például a VMware nem biztosít előzetes hozzáférést a legújabb vSphere verziókhoz a szoftverfejlesztők számára, így a Veeam fejlesztői és tesztelői új verziót egyszerre kapnak a többi előfizetővel – ezért a VMware kiadása és a hivatalosan bejelentett támogatás között általában eltelik egy kis idő. A szükséges módosítások mennyisége és sokfélesége olyan nagy, hogy egy egyszerű hotfix alig tudja mindezt magában foglalni – és a hivatalos támogatást jellemzően a Veeam Backup & Replication kiadásával egy időben jelentik be.

Végül előfordul az a kínos helyzet, amikor egy új vSphere verzió megjelenése után a támogatási kérelmek száma hirtelen megnövekszik, mert a felhasználók sietve telepítik az új verziót, és a biztonsági mentéseik természetesen azonnal működésképtelenné válnak. A Veeam technikai támogatásának tisztáznia kell a felhasználók számára, hogy mit csináltak rosszul, kérniük kell őket, hogy térjenek vissza az előző verzióra (ha lehetséges), vagy bonyolult megoldásokat kell kidolgozniuk a zsákutcából való kijutásra. Ezért telepítés előtt mindenképpen ellenőrizze a frissítés kompatibilitását a használt szoftverével, kérlek, ne feledkezzen meg róla!

Mindez vonatkozik az alkalmazásokra is, amelyeket biztonsági másolatként használ és a Veeam segítségével szeretne visszaállítani. A Veeam Explorers eszközeihez is tartozik egy lista a támogatott alkalmazásverziókról, amely minden Veeam Backup & Replication kiadással bővül. Ezért a legújabb verzió telepítése előtt – legyen szó Exchange, Oracle vagy SharePoint alkalmazásról – mindenképpen olvassa el a megfelelő fejezetet. a Veeam Explorers dokumentációjában..

A második kategóriába, azaz a kisebb frissítések közé tartoznak például a VMware Tools új verziói, az Exchange kumulatív frissítései, a vSphere biztonsági frissítései stb. Általában ezek nem jelentenek komoly módosításokat, és a legtöbb esetben a Veeam Backup & Replication nem tapasztal problémákat velük. (Ezért nem is szoktak publikusan bejelentéseket tenni a hivatalos támogatásról a termékben.) Azonban tapasztalataink alapján előfordultak olyan esetek, amikor ezek a frissítések olyan jelentősen megváltoztatták a megszokott dolgokat, hogy hibákat okoztak a Veeam Backup & Replication működésében. Ilyen helyzetekben a Veeam mérnökei igyekeznek gyorsan hotfixet kiadni a probléma megerősítése után.

A technikai angolt beszélőknekHa szeretne tájékozott lenni arról, mivel foglalkoznak a mérnökök, és mivel szembesülnek a rendszermodellezők és a támogatási szakemberek, javaslom, hogy iratkozzon fel a forumainkra. Minden héten megjelenik egy "Word from Gostev" hírlevél, amelyet TheRealGostev. Anton Gostev, a termékkezelési részleg vezetője abban beszél a nemrégiben felfedezett problémákról (nemcsak a Veeam oldalán), az új verziók terveiről és az IT világ híreiről. Ha további információra van szüksége, át kell lapoznia a fórumtémákat – ha valamelyik ügyfél problémát tapasztal a termék működésében egy frissítés után, valószínűleg már írta róla a fórumon.

Ahogy mondtam, a javítók és frissítések nemcsak a biztonsági mentésekkel, hanem azokkal az alkalmazásokkal is problémákat okozhatnak, amelyekhez ezek a biztonsági mentések készülnek. Ebben segítenek a virtuális laboratóriumok — a Veeam DataLabs. Valószínűleg hallott már a SureBackup funkcióról, amely a biztonsági másolatok ellenőrzésére szolgál. Ez a DataLabs használatán alapul, egy izolált környezet létrehozásával, ahol többek között a frissítések tesztelhetők a termelésbe telepítés előtt. Tényleg érdemes így tenni – sok idegi sejtet megspórolhat. a dokumentációval.

Eddig mára ennyi, köszönöm a figyelmet!