Ma ismét örömmel mutatom be Önt kollégámtól, Jevgenyij Ivanovtól, a Veeam technikai támogatási csapatának csapatvezetőjétől hasznos tippekkel. Ezúttal Zhenya ajánlásokat osztott meg a biztonsági másolatokkal és replikákkal való munkához. Remélem, segítenek elkerülni a gyakori hibákat, és a replikák és biztonsági másolatok soha nem lesznek „gyenge láncszem” a helyreállítási folyamatban, ha szükséges.

Szóval üdv a macskában.

Az előzőmben cikk megvizsgáltuk, hogyan lehet optimalizálni a biztonsági mentési infrastruktúra-összetevők terhelését, és megvizsgáltuk a gyakori konfigurációs hibákat. Térjünk át egy másik fontos témára - a helyreállítás megfelelő előkészítésére és végrehajtására. Valós példák segítségével is elemezzük, amelyekkel a technikai támogató csapatnak lehetősége volt dolgozni.

Mentés étterem nélkül – pénz a lefolyóba

Rendszeresen keresnek meg minket olyan felhasználók, akik hasonló nehéz helyzetbe kerültek: biztonsági mentésből kell visszaállítani, de amikor megpróbálják ezt megtenni, az emberek egy számukra megoldhatatlan problémába ütköznek. És ez a probléma nem a biztonsági mentés hiánya, a CryptoLocker tevékenység vagy bármi hasonló. Ez „csak” elégtelen figyelem a biztonsági másolatok és replikák visszaállíthatóságának tesztelésére. Sokan gyakran kizárólag a biztonsági másolat készítésére összpontosítanak, elfelejtve, hogy a biztonsági másolat elkészítése nem csodaszer az esetleges problémákra. Meg kell értenie, hogy a helyreállítás egy teljesen más folyamat, amelynek megvannak a maga sajátosságai, és amelyet a gyártás megkezdése előtt ellenőrizni és tesztelni kell. Íme néhány szemléltető példa:

Egy felhasználó egy kritikus 20 TB-os virtuális gép leállását tapasztalta. Az állásidő természetesen elfogadhatatlan, és az adminisztrátor elindítja az azonnali helyreállítási folyamatot (VM azonnali helyreállítás) - 5 perc után a gép feláll. De ne felejtsük el, hogy a gép ezen állapota csak ideiglenesen használható - át kell költöztetni a termelési adattárba. Ebben a példában pedig, mint kiderült, az infrastruktúra képessé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 a változtatások lemezre mentése lett kiválasztva TÓL TŐL: Veeam Backup & Replication szerver (szemben a vSphere snapshottal) - ennek eredményeként természetesen a szabad lemezterület gyorsan megtelt. Mire a felhasználó felvette a kapcsolatot az ügyfélszolgálattal, a virtuális gépen olyan változások voltak, amelyeket nem lehetett figyelmen kívül hagyni. Vagyis olyan helyzet áll előttünk, hogy lehetetlen gyorsan befejezni egy kritikus gép azonnali helyreállításának folyamatát – hogyan menthetjük el az adatokat?
Őszintén szólva, az évek során már nem emlékszem a finálé minden részletére, de arra emlékszem, hogy végül nem jutottunk semmi zseniálisra. A kliensek legalább úgy oldották meg ezt a problémát, hogy a tartalékokból kibővítették a C: meghajtót, átmásolták a legfontosabb fájlokat, majd csak ezután kapcsolták ki a virtuális gépet, és így migráltak. Általában nem történt csoda.
A felhasználó infrastruktúrája egy tartományvezérlőt futtatott, és a Veeam Backup & Replication összes összetevője DNS használatával volt konfigurálva. Igen, igen, így van, jól hallottad. Száz lehetőség volt az események fejlesztésére, nem kevesebb, de a valóságban minden így zajlott: az emberek karbantartást terveztek, és úgy döntöttek, hogy átváltanak tartományvezérlőjük másolatára. Tervezett kapcsolót alkalmaztak, ami általában ajánlott ilyen helyzetekben. Az első szakaszban minden rendben ment, de a másodikban a forrás virtuális gépet rövid időre kikapcsolták a fennmaradó adatok átvitele érdekében. Természetesen az átállási munka azonnal meghiúsult, mert a DNS leállt.
Szerencsére meg tudtuk kezelni a helyzetet úgy, hogy manuálisan engedélyeztük a replikát a vSphere-ből (valójában nem ajánlott ezt saját kezűleg megtenni, amint azt a következő példában látni fogja). De amint Ön is tudja, a karbantartási folyamat megszakadt és késett. Ezenkívül manuálisan kellett beírnunk a fájlba a gazdagépneveket C: WindowsSystem32driversetchosts a Veeam Backup & Replication szerveren, hogy biztosítsa a helyességet a visszakapcsolás során.
Egy másik kliens egy teljes biztonsági mentési infrastruktúrát épített szalagos meghajtókra, és csak rövid fájlsorozatokat tárolt a lemezen. Amikor számos fájlt kellett helyreállítaniuk egy nagy fájlszerverről, azt találták, hogy egyik gép sem használható másodlagos adattárként a szalagos helyreállításhoz, mivel egyiken sem volt elég szabad hely. (A mágnesszalagról történő helyreállításról közvetlenül és egy kiegészítő adattár használatával olvashat itt (egyelőre angolul)).

Úgy gondolom, hogy mindhárom példában a felhasználókat úgymond illúziók ragadták el - abból indultak ki, hogy ha a mentés sikeres lesz, akkor nem lesz probléma a visszaállítással. De ez, amint megérti, semmi esetre sem mindig így van, ezért a helyreállításra ugyanolyan gondosan kell felkészülni, mint a biztonsági mentésre. Először is érdemes tanulmányozni kézikönyv, amely meglehetősen részletes információkat tartalmaz a helyreállítás különböző típusairól. Minden bekezdés elején felsoroljuk a követelményeket, az előkészítő intézkedéseket és a lehetséges korlátozásokat. A mágnesszalagokról vagy a hardveres tárolási pillanatképekről történő helyreállítás leírása megtalálható a dokumentáció részeiben és cikkeket a Habrén. Ezenkívül a „Tervezés és előkészítés” részben találhatók az alkalmazásobjektumok Veeam Explorer segítségével történő visszaállításának előkészítésének lépései. útmutatók minden egyes hangszerhez. Javasoljuk, hogy figyelmesen olvassa el őket - ez segít a rendszer megfelelő felkészítésében a helyreállításhoz, ha szükséges. Az SQL Server adatbázis visszaállítására vonatkozó utasítások orosz nyelven találhatók: itt.

Miért ne dolgozhatnék a vSphere konzol replikáival?

Elméletileg a Veeam replikák közönséges virtuális gépek, amelyekkel logikusnak tűnik a vSphere eszközök, különösen a vSphere kliens használatával dolgozni. Ezt azonban nem javasoljuk, és ez az ok: a replikára váltás a Veeam Backup & Replication alkalmazásban meglehetősen bonyolult folyamat, szigorúan egymás után következő lépésekre van szükség (hogy ha valami történik, akkor egy lépést vissza tudjon görgetni) és a végső műveletek helyesbítését - csak nézze meg a folyamatot illusztráló képet:

Ha úgy dönt, hogy engedélyezi a replikát a vSphere kliensből, akkor a jövőben valószínűleg számos problémával fog találkozni:

A Veeam Backup & replikáció replikájára való váltás mechanizmusa (az ábrán látható) ezen a gépen már nem fog működni.
A Veeam Backup adatbázisban lévő adatok nem felelnek meg a virtuális gép aktuális állapotának. A legrosszabb esetben szerkesztenie kell az adatbázist a javításhoz.
Még az adatvesztés is lehetséges, mint ebben a példában: a felhasználó manuálisan engedélyezte a replikát a vSphere ügyfélben, és úgy döntött, hogy folytatja a munkát. Egy idő után észrevette, hogy a replika még mindig megjelenik a Veeam Backup & Replication konzolon, és úgy döntött, hogy eltávolítja, mert szükségtelen. Jobb gombbal rákattintott és kiadta a parancsot "Törlés a lemezről". A Veeam Backup & Replication azonnal törölte a replikát a lemezről, amely egy pillanatra már teljes mértékben használatban volt normál virtuális gépként, és tartalmazta a szükséges és hasznos adatokat.

Természetesen vannak olyan helyzetek, amikor még mindig be kell kapcsolnia a replikát a vSphere kliensről - általában ezek az esetek, amikor a Veeam szerver ki van kapcsolva, és a replikát késleltetéssel kell bekapcsolni. De ha minden rendben van a Veeam szerverrel, akkor a konzolról kell replikákkal dolgozni.

Ne törölje a replikákat a vSphere ügyfél használatával sem. A Veeam Backup & Replication nem vesz tudomást erről a változásról, amely hibákhoz és elavult adatokhoz vezethet. Ha már nincs szüksége replikára, törölje azt a Veeam konzol segítségével, ne virtuális gépként a vSphere-ügyfélből. Így mindig naprakész listája lesz a replikákról.

"Ó" - légy óvatos, frissítések!

Itt természetesen a hypervisorok és különféle alkalmazások frissítéseire gondolunk, amelyekről a Veeam segítségével készül biztonsági másolat. Ha a Veeam Backup & Replication szolgáltatással való munka szempontjából nézzük őket, akkor a frissítések 2 kategóriába sorolhatók: nagyok, komolyak, sok változást bevezető - és kicsik.

Nézzük először az első kategóriát.

A legfontosabb frissítések azok, amelyek a hypervisort célozzák. Egy ilyen frissítés telepítése előtt győződjön meg arról, hogy a Veeam Backup & Replication támogatja azt. Ezek a frissítések számos változást vezetnek be a Veeam Backup & Replication által használt könyvtárakban és API-kban, ezért a Veeam Backup & Replication kódját frissíteni és alaposan tesztelni kell a hivatalos támogatásukhoz.

Azt is szem előtt kell tartanunk, hogy például a VMware nem biztosít előzetes hozzáférést a szoftvergyártók számára a vSphere legújabb verzióihoz, így a Veeam fejlesztői és tesztelői a progresszív emberiség többi részével egy időben kapnak új verziót – ezért általában késés a VMware kiadása és a hivatalosan bejelentett támogatás között. A szükséges változtatások száma és változatossága olyan, hogy kicsi az esélye annak, hogy egy egyszerű gyorsjavításba illesszék őket – és a hivatalos támogatást általában a Veeam Backup & Replication kiadási verziójának kiadásával együtt jelentik be.

Ennek eredményeként az a kínos pillanat következik be, amikor a vSphere új verziójának megjelenése után meredeken megnő a technikai támogatás iránti kérelmek száma, mivel a felhasználók hanyatt-homlok rohannak az új verzió telepítésére, és a biztonsági másolataik természetesen azonnal leállnak. . Nekünk, a Veeam műszaki támogatásának kell elmagyaráznunk a felhasználóknak, hogy pontosan mit csináltak rosszul, meg kell kérnünk őket, hogy lépjenek vissza (ha lehetséges), vagy bonyolult módszereket kell kidolgoznunk a zsákutcából való kilábaláshoz. Ezért egy komoly frissítés telepítése előtt feltétlenül ellenőrizze a kompatibilitását az Ön által futó szoftverrel, könyörgöm!

A fentiek mindegyike vonatkozik azokra az alkalmazásokra is, amelyekről biztonsági másolatot készít, és várhatóan visszaállítja a Veeam segítségével. A Veeam Explorers eszközcsalád a megfelelő alkalmazások támogatott verzióinak listáját is tartalmazza, amely a Veeam Backup & Replication minden egyes kiadásával frissül. Ezért, mielőtt telepítené az alkalmazás új verzióját – legyen az Exchange, Oracle vagy SharePoint – mindenképpen olvassa el újra a vonatkozó részt. Veeam Explorers dokumentáció.

A második kategóriába, i.e. Kis frissítések közé beépítem például a VMware Tools új verzióit, az Exchange összesített frissítéseit, a vSphere biztonsági frissítéseket stb. Általában nem vezetnek be jelentősebb módosításokat, és a legtöbb esetben a Veeam Backup & Replication nem tapasztal problémát velük. (Ezért nincs nyilvános bejelentés a termék hivatalos támogatásáról számukra.) Gyakorlatunkban azonban előfordult, hogy az ilyen frissítések olyan jelentősen megváltoztatták a dolgok szokásos menetét, hogy a Veeam Backup működésében hibákhoz vezettek. & Replikáció. Ilyen helyzetekben a probléma megerősítése után a Veeam mérnökei megpróbálnak gyorsan kiadni egy gyorsjavítást.

Műszaki angolul beszélőknekHa szeretne naprakészen tartani, hogy a mérnökök min dolgoznak, és milyen rendszertervezőkkel és műszaki támogatással foglalkozó szakemberekkel találkoznak, azt javaslom, hogy iratkozzon fel fórumainkat. Előfizetői számára minden héten megjelenik egy „Gosztev szó” hírlevél. The RealGostev. Ebben Anton Gostev, a termékmenedzsment osztály vezetője beszél a közelmúltban talált problémákról (és nem csak a Veeam oldalán), új verziók terveiről és az IT világ híreiről. Ha további információra van szüksége, tanulmányozhatja a fórum témáit - ha valamelyik ügyfélnek bármilyen frissítés után problémája van a termék működésével, akkor valószínűleg már írt róla a fórumon.

Amint Ön is tudja, a javítások és frissítések nem csak a biztonsági mentésekkel, hanem azokkal az alkalmazásokkal is problémákhoz vezethetnek, amelyekhez ezek a biztonsági mentések készülnek. És itt a virtuális laboratóriumok - Veeam DataLabs - segítenek Önnek. Valószínűleg hallott már a SureBackupról, amely a biztonsági mentések ellenőrzésére tervezett funkció. Pontosan a DataLabs használatán alapul, egy elszigetelt környezet létrehozásával, amelyben különösen tesztelheti a frissítéseket, mielőtt azokat éles üzembe helyezné. Erősen javaslom ezt – sok idegsejtet takarít meg. És ha valaki még nem ismeri a SureBackup-ot, annak ajánlom, hogy olvassa el dokumentáció.

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