vSphere Data Protection 5.1 - Backup

Az első részben a VDP telepítéséről és konfigurációjáról volt szó. A végére eljutottam odáig, hogy a VDR konfigurációs oldalára bejelentkezve minden szolgáltatás működőképesnek tűnt. Nézzük meg, hogy a Web kliens oldalon milyen változás látható a sikeres telepítés után.

 

A kliens baloldali sávjába beköltözött a VDR, azaz a vCenter regisztráció is sikeres volt. Miután elindítottam, egy kicsit meglepődtem az induló képernyőn. Úgy tűnik, hogy a fejlesztés (vagy éppen a lebutítás) egyik célja az volt, hogy kinézetre pontosan visszaadják a VDR-t. Nekem ez  nem tűnt jó ötletnek, hiszen mégsem egy nagyon sikeres terméket cserélt le a VMWare, de talán az vezérelte a fejlesztőket, hogy a VDR-rel megszerzett ismereteket minél könnyebben fel lehessen itt is használni. Aki tudja, hasonlítsa össze a két felületet:)

 Ugyanaz az ábra, ugyanazok a menük, a Basic Tasks terület is változatlan. Egyedül a legfelső sorban látható, hogy itt más termékről van szó.
Mivel most a mentésről lesz szó, vágjunk is bele. Válasszuk a Backup fület, majd a Create New Backup Job link segítségével készítsük el az első jobot. A vSphere Web kliensben megszokott felületű varázsló indul el, amiben néhány lépésen keresztül könnyedén összekattinthatjuk a a kívánt tartalmú mentési feladatot. Előbb a mentendő gépeket kell megadnunk. Itt nem csak egyesével, hanem a gépeket tartalmazó többféle konténer kiválasztásával egyszerre többet is megadhatunk. Olyan apróságokra viszont ügyelni kell, hogy ha pl. egy cluster-t választunk ki, majd később az egyik gépet elmozgatjuk egy másik cluster.be, akkor a gép kikerül a mentések közül.

 

Bár a gépek között ott van maga a VDR is, azt nem lehet ilyen módon menteni. A következő lépésben a mentési gyakoriságot állíthatjuk be.

 

 

Az összes lehetséges beállítási mód leolvasható a fenti képről. Ezután az ún. Retention policy, azaz a megőrzési idők beállítása következik. Itt is minden leolvasható a következő képről.

 

 

Négy féleképpen mondhatjuk meg, hogy a VDP hogyan őrizze meg a mentéseinket. Örökre, megadhatunk egy megőrzési hosszt, megadhatunk egy dátumot, amikor már törlődhetnek, illetve meghatározhatunk egy megőrzési rendszert. Ez a része már a VDR-nek is tetszett. Ezután már csak adnunk kell valami jó nevet, áttekinteni még egyszer a beállításainkat, és készen is vagyunk.

 

 

Kapunk egy figyelmeztetést, hogy a job létrehozása akár több percig is eltarthat. A szükséges idő az érintett virtuális gépek mennyiségével arányos. Ha nézzük közben a taskokat, akkor láthatjuk, hogy minden egyes gépen végez módosításokat a job mentése során.

 

 

Ha mindennel végzett, a job megjelenik a listában.

 

 

A Next Run Time oszlopban az látható, hogy 20:00. Miért pont akkor kezdődik? Erre a választ a Configuration fülön lévő Backup Window Configuration részben találhatjuk.

 

 

Látható, hogy a napot három részre tudjuk osztani. Ebből a zöld színű jelenti azt az időszakot, amikor a mentések futhatnak. Ennek pedig a kezdeti ideje a képen is leolvasható 20:00 óra. Az egyes területek jelentéséről majd egy későbbi posztban írok (talán). A lényeg, hogy itt tudjuk megváltoztatni a mentési ablakot.

Ha eljön az idő, a taskok között láthatjuk, hogy elindultak a mentések.

 

 

A mentés a szokásos módon, snapshot készítéssel történik. Ha mentés közben ránézünk egy virtuális gépre, akkor a következőt láthatjuk.

 

Ha végzet minden géppel, a Reports fülön némi információhoz juthatunk. Egy picit túlzónak tűnik a megnevezés, mert túl sok mindent nem tudunk innen kinyerni. Ez a rész visszalépésnek tűnik a VDR-hez képest.

 

 

Hol tudnánk legkönnyebben leellenőrizni, hogy a mentéseink eredménye rendelkezésre áll-e? Természetesen a Restore fülön.

 

Már néhány mentési megoldást volt szerencsém kipróbálni. Azt kell mondanom, hogy a VDP egyszerű, mint egy fa ék:) A sebesség is nagyon jónak tűnt, de nyílván ezt igazából egy nagyobb környezetben lehetne lemérni.

Összességében eddig tetszik. Egyszerű telepíteni, konfigurálni. A mentések során kevés lehetőség közül választhatunk, de nyílván ez is volt a cél. Azaz minél egyszerűbb legyen a használata. Viszont hiányolom a részletes riportolást, amiből láthatnám pl. a sebességet.

Ahogy mondani szokták, a backup akkor ér valamit, ha vissza is tudunk a mentésből állítani. Ennek szeretnék majd a végére járni a következő részben.

VMware Data Recovery 2.0

A vSphere 5 bejelentésével egy időben a VMware Data Recovery-nek (a továbbiakban VDR) is elérhetővé vált egy új verziója. Ráadásul a fő verzió szám ugrott egyet, így akár arra is gondolhattam volna, hogy egy sor újdonság, fejlesztés lesz benne. Mivel az előző verziót élesben használom egy kis környezetben, és mint egy régebbi bejegyzésben írtam, nagyon hiányzik egy riportoló, mail küldő funkció, ezért ez volt az első amit az új funkciók között kerestem. Erről egy kicsit később.
A telepítésről nem akarok részletesen írni, mivel az semmit nem változott. Az upgrade-re sem kell sok betűt pazarolni, mivel ha a régi környezet mentéseit tartalmazó diszkjeit (vagy megosztásait) lecsatoljuk, majd az új appliance-hez felcsatoljuk, akkor tulajdonképpen készen is vagyunk.

Akkor vegyük sorra, mi változott:

• 64 bites CentOS 5.5 operációs rendszeren fut az Appliance.
• Növelték a mentések, integritás ellenőrzések sebességét. Aki már használta, az tudja hogy főleg az utóbbi esetében szükség is volt rá. 100-200GB mentés esetében képes volt órákig tekergetni a diszket úgy, hogy visszajelzés csak arról volt, hogy éppen történik valami. De hogy éppen hol tart, kb. mennyi idő van még hátra, stb. arról mélyen hallgatott.
• A megszakadt integritás ellenőrzést most már tudja folytatni. Eddig, ha valami miatt nem végzett, minden kezdődött előröl. Az ellenőrzés során nem csak azt ellenőrzi, hogy az adatok rendben vannak-e, hanem a megőrzési szabályoknak megfelelően törli a feleslegessé vált mentéseket.
• Most már van egy kis beleszólásunk abba, hogy ezek az ellenőrzések mikor fussanak le. Ha nem állítunk be semmit, vagy a Default-ot választjuk, akkor minden hétköznap délelőtt kilenc és délután öt között fog futni

• Az ellenőrzések futtatása alatt is képes menteni vagy visszatölteni
• Van email küldési lehetőség. Az smtp szerver beállítása semmiben nem különbözik más rendszerekétől. Ezen kívül pedig csak azt tudjuk beállítani, hogy mely napokon és hány órakor akarjuk kapni a levelet. Ennyi. A levél tartalma logikusan felépített, és minden fontos információt tartalmaz. (Appliance paraméterek, futott jobok, mentett gépek, sikertelen mentések, mentési idők, destination-ök állapota)

• Lehetőségünk van arra, hogy futó backup job esetében felfüggesszük a jobot olyan értelemben, hogy amit éppen ment azt még befejezi, de új virtuális gépek mentésébe már nem kezd bele

Néhány tulajdonság, képesség ami nem változott:

• Továbbra is a kisebb környezetek mentésének ideális eszköze. A hangsúly a kisebben van, mivel továbbra is élnek a korlátok (egy appliance max. 100 gépet képes menteni, egy vCenteren max. 10 appliance lehet, max. 2 destination tartozhat egy VDR-hez, és ezek mérete is korlátos)
• Dinamikusan képes új gépeket is menteni, amennyiben datacentert, clustert, vagy foldert jelölünk ki. Ilyenkor az adott helyre bekerült új gép mentése automatikusan megtörténik a következő futásnál.
• Rendkívül rugalmas retention policy (léteznek előre beállított sablonok, de ha kell mi magunk állítjuk be, hogy hány darabot őrizzen meg a legutolsó mentésekből, mennyit a heti mentésekből, a haviból, negyedévesből, évesből)
• A mentési ablak is csak úgy állítható, ahogy az ellenőrzéseket is tudjuk ütemezni. Azaz korlátozhatjuk egy adott időszakra, de pontosan nem tudjuk megmondani, hogy mikor történjen a mentés
• Külön kliens program telepítése után képes file szintű visszaállításra is (itt a telepítés egy .exe file bemásolását jelenti csupán)
• Tudtam, hogy valami fontosat elfelejtek: a nagyon jó deduplikációs  képességet

Mindenki döntse el magában, hogy ez így megérdemli-e a 2.0-ás verziót...

Hibás VMware Data Recovery működés

Bár a virtuális gépek mentésére használt elsődleges eszköz a TSM, bizonyos esetekben jól meghatározott gépek körére tökéletes megoldás nyújthat a VDR is. Főleg, hogy az 1.2.0-ás verzió már egészen megbízhatóan működik. Most persze ellentmondtam a bejegyzés címének, de tényleg ez az igazság. Hogy néha mégis történik egy kis gubanc? Melyik termékkel nem?

A VDR egyik nagy hiányossága, hogy nem képes üzeneteket küldeni a mentések státuszáról. Éppen ezért fordulhatott elő, hogy néhány napig a backup jobok nem futottak le. Ez onnan derült ki, hogy folyamatosan ellenőrzöm a snapshotok méretét, korát, és az egyik mentendő szervernél feltűnt, hogy a VDR által készített snapshot még mindig létezett. Hogy pontosan mi történt, az már nem fog kiderülni. De az biztos, hogy a VDR már nem törölte a saját maga által kreált snapshot, a mentéshez saját magához felcsatolt diszkek még mindig ott voltak, illetve a backup sem futott attól az eseméyntől kezdve.

Gyors keresés a Neten, és a következő KB cikkhez jutottam el. Bár a körülmények nem voltak teljesen azonosak, de mégis kecsegtetett némi reménnyel.
A cikkben foglaltaknak megfelelően letöltöttem a fixdeletable.py Perl scriptet, bemásoltam a virtuális gép folderébe, majd futtattam.

Látható, hogy bizonyos vmdk file-ok esetében végre is hajtotta a módosításokat (törölhetővé tette a snapshotokat). Ezután létrehoztam egy snapshotot, majd a snapshot manager-ben a Delete All paranccsal igyekeztem megszabadulni az összes snapshottól. A várt siker helyett a következő üzenet fogadott:

A zárolást nyílván nem okozhatta más, mint maga a VDR, hiszen a két diszk továbbra is látszott a VDR erőforrásai között. Ezután még négy lépés hiányzott a sikerhez:

• VDR leállítása
• mivel így a lock megszünt,  a snapshotok törlése
• a VDR lemezei közül a nem oda valók törlése (vigyázva arra, hogy csak a VDR-től vegye el, a datastore-on maradjon
• VDR indítás, ellenőrzés

Ha a Data Recovery rendelkezne valamilyen beépített üzenetküldő szolgáltatással, mindez még a hiba napján megoldódhatott volna. Remélhetőleg a következő verzióban ez a hiányosság megszűnik.