A mentés és visszaállítás képessége nem utópia, minden gyártó legalább menteni, némelyik visszaállítani is tud és vannak olyanok is, akik a már mentett adattal kezdenek valamit. A Rubrik esetén a már lementett adaton alapulva lehetséges a Data Security Posture – korábban Sensitive Data Discovery – azaz az általunk valamilyen módon érzékeny tartalmú fájlok azonosítása és persze a Data Threat Analytics – korábban Ranomware Monitoring – ami pedig a zsarolóvírusok azonosításában tud villantani. Ezekhez a mentést nem kell visszaállítani, sem egy izolált “laborban” elindítani a vizsgálni kívánt gépet, hanem simán így “offline” működik – a Rubrik esetén.
Ha vissza kell állítani ideiglenes vagy permanens módon bármit, akkor miért ne tegyük azt meg tervek alapján? Három opciónk van igazából és van egy úgynevezett Cyber Recovery varázsló is.
- Isolated Recovery
- Disaster Recovery
- In-Place Recovery
- Cyber Recovery
A terv maga meghatározza mit, hová, milyen sorrendben “állítson” vissza. Az első három opció fontos a negyedik, a Cyber Recovery megértéséhez.
Isolated Recovery
A Rubrik-nál én azt szeretem, hogy tényleg átgondolták ezt a dolgot. Ha például van két Rubrik CDM-em – értsd két Rubrik klaszterem – az egyik az éles telephelyemen, a másik a DR telephelyen, akkor bármelyiken létre tudok hozni ilyen feladatokat. Tehát van arra mód, hogy az éles telephelyemen lévő klasztert hagyom háborítatlanul és a DR telephelyen lévő klaszteremről indítok el mondjuk egy ilyen Isolated Recovery buborékot – persze kell hozzá hogy a produktív telephelyemen lévő CDM replikálja a kívánt mentéseket a DR telephelyre – ennél fogva a produktív oldali CDM nem kap plusz terhet.
A neve elárulja azt, hogy ez tényleg egy buborék, amibe adott mentett workload helyezhető és azok egy elzárt rezervátumban fognak futni. Létrehozása végtelenül egyszerű, hiszen csak el kell nevezni és meg kell adni, melyik CDM-en lévő mentésekből szeretnénk felfújni a buborékot.
Meg is mutatja azon virtuális gépek – nincs értelme csak DB-ről vagy fizikai gépről beszélni, mivel értelmezhetetlen – listáját, amelyek rendelkeznek mentéssel a kiválasztott CDM-en.
Természetesen kell valamilyen virtualizációs réteg, hiszen bár a tárterületet – a mentéseken alapulva a Rubrik CDM adja – de valahol azért kell egy ESXi, amin elindul maga a VM/VM-ek. Ez lehet az összes kijelölt virtuális gépre egy adott ESXi hoszt, egy vSphere klaszter, sőt, akár VM-enként más és más klaszter vagy hoszt. Tehát van arra lehetőség, hogy a Microsoft VM-eket csak a Microsoft licenszelt, az Oracle termékeket pedig csak az Oracle-re licenszelt klaszterben indítsa el.
Bár opcionális, de igen lényeges az, hogy adunk-e meg egy vagy több olyan datastore-t, amit használhat ha VM-et/VM-eket végül exportálni akarjuk. Ez adja meg azt, hogy ténylegesen a Rubrik-ról jön az IO majd vagy mondjuk valamilyen tárolóról.
A következő lépés a hálózati konfiguráció. Nyilvánvalóan el kell kerülni az IP-címek ütközését de mégis meg kell valósítani azt a kommunikációt, amely mondjuk a buborékon belül lévő VM-ek között történik. Utóbbi annyiban bonyolult, hogy nem biztos – sőt inkább teljesen biztos – hogy a VM-ek nem egy VLAN-ban lesznek, amelyek között pedig meg kell oldani az útválasztást. Erre nem ad beépített megoldást a Rubrik, ezt hálózati oldalon meg kell támogatni. VMware-ről legyen szó NSX-el ez sima ügy, ha pedig nincs NSX, akkor a hálózati csapat kell adjon olyan VLAN-okat, amelyeken alapulva a VM-ek indíthatóak és mégsem ütköznek meg az éles rendszerekkel.
Aztán természetesen a kiválasztott VM-eket csoportokba lehet rendezni, amik az indítási sorrendet definiálják. A csoportok között lehet indítási szünetet beállítani. Alább például a tartományvezérlőt teszem az első csoportba, ami után öt perccel indul a FS01 a második csoportban, majd rá 5 percre minden más.
Igény esetén szkripteket is le lehet futtatni a virtuális gépeken, miután azok elindultak. Ehhez az kell, hogy maga a szkript a VM-ben legyen valahol és annak az útvonalát lehet megadni.
A terv tehát létre is jött, de ekkor még semmi sem történik.Kézzel vagy ütemezetten is indítható a terv. Utóbbi elég jó, mivel mindig a legújabb egészséges – tehát ransom mentes – mentésből fogja elindítani a VM-eket és ha elindult minden, akkor leállítani őket, riportolva azt a sikerességet/sikertelenséget.
A példában én manuálisan elindítom a tervet. Első kérdése az, hogy a mentésből egyenesen induljon el minden VM vagy előtte tegye át valami datastore-ra a mentésből és onnan induljon el. Mivel a terv beállításakor nem adtam meg erre a célra datastore-t, ezért csak az első opció működik.
A következő ablakban a mentési kópia válaszható ki, azaz a legújabb vagy valamelyik korábbi. Ezeket szintén megkülönbözteti aszerint, hogy volt e mármi anomália bennük.
Aztán még egyszer megerősítést kér arról, hogy a korábban megadott hálózati konfiguráció jó lesz-e. Ha igen, akkor a Recover gomb megnyomásával elkezdődik a folyamat.
A folyamat egészen részletesen követhető, mikor állít be mit stb.
vCenter-ben nézve megjelenik a VM-ekkel egyenlő számű NFS datastore és azokon a kívánt sorrendben és késleltetéssel elindul minden VM.
A végeredmény tehát az, hogy a VM a terv végeztével maradnak futó állapotban, de a lényeg az, hogy erről riportot is ad. PDF formátumban, dokumentálva mutatja, hogy sikeres volt-e a terv végrehajtása, mennyi ideig tartott és pontosan mi volt a terv.
Pontosan ez az a riport, ami az ütemezett, rendszeres és automatikus végrehajtás lényege. Ha kell, akkor hetente a legfrissebb mentésen alapulva végrehajtja a tervet. Az ütemezett végrehajtás vége a buborék megszüntetése, míg a manuálisan elindított terv vége a buborék megmaradása.
In-place Recovery
Az ilyet senki sem szeretné soha élesben használni, de ez arról szól, hogy minden elveszett vagy használhatatlan, ennél fogva az eredeti helyre állítunk vissza mindent a mentésből. Ha az Isolated Recovery-t veszem alapul, akkor itt sokkal kevesebb dolgot kell majd megadni, mivel nem kell hálózatot konfigurálni, itt az “élesbe” megy vissza minden.
Nyivánvalóan meg kell adni mit szeretnénk visszaállítani. Már megismert módon itt aztán lehet SLA alapon, VM konyvtár alapon, cluster&host alapon és vSphere tag-ek alapján válogatni.
A szokásos csoportok kialakítása következik.
Kész van tehát a terv, amit megvizsgálva egész jó dolgok láthatóak. Mégpedig az SLA lag, ami nem más, mint az, hogy az aktuális időponthoz mérve milyen régi a legújabb mentés és milyen gyakran van mentés az adott elemről.
Tegyük fel, hogy megtörténik a baj és helybe vissza kell állni azonnal. A “Recover” kiválasztásával vagy a legújabb egészséges mentés vagy a kívánt kópiából – akár VM szinten is felülbírálható – indul el a visszaállítás. Fontos, hogy itt ténylegesen visszaállítja az adatokat arra a datastore-ra/datastore-okra, amelyeken a hibás VM-ek vannak.
Még egyszer megerősítteti velük, hogy tényleg végre akarjuk hajtatni a tervet, mivel ez – bármi is legyen az állapota az éles rendszereknek – visszafordíthatatlan folyamat.
Disaster recovery
Ehhez nem elegendő egy Rubrik klaszter, ehhez kettő kell.
Meg kell adni, hogy mely VM-eket szeretnénk a tervben kezelni.
Természetesen a már ismerős csoportok kialakítása is kell.
A következő lépés annak kiválasztása, hogy hol induljanak el a virtuális gépek. Eredeti helyen nem lehet őket elindítani, mert a terv azt feltételezi, hogy az a hely elveszett, DR helyzet van. Globálisan és VM szinten persze be lehet állítani, hogy mit hol akarunk indítani – hoszton bizonyos VM-eket vagy adott klaszterben, resource pool-ban.
A következő egy nagyon fontos döntést kér tőlünk. El kell dönteni, hogy a DR telephelyen a hiba esetén történő indításhoz szükséges tárkapacitást fent kivánjuk-e tartani vagy csak éppen a tesztek idejére. Az első opcióban érthető módon alacsonyabb RTO-t – azaz gyorsabban állíthatjuk újra üzembe a rendszereket – eredményez, míg a másik ezzel szemben magasabb RTO-t. Mindenképpen megkérdezi melyik/melyek azok a datastore-ok, amelyeket erre használni kívánunk.
A szokásos post script és hálózati beállítások következnek. Utóbbi nyilván kicsit eltér, hiszen egy teljesen másik vCenter Server-be állítom vissza a terv alapján a virtuális gépeimet, szóval cél hálózatokat kell választani és hogy DHCP/fix-ip-t kívánunk-e adni a VM-eknek, ráadásul kétszer is meg kell adni, hiszen a Disaster Recovery tervet lehet tesztelni és élesben is futtatni. Így például, ha csak tesztelni akarjuk, akkor csatolni lehet a VM-eket egy adott hálózathoz – elkerülve az ütközést – míg ha a tervet nem teszteljük, hanem ténylegesen végrehajtuk, akkor az éles hálózathoz csatlakoznak majd a visszaállított VM-ek.
Ha megtörtént az átállás, akkor minden bizonnyal mentésre is szükség lesz újra, így tehát – bár opcionális – de megadható az az SLA, amivel a cél helyen védeni kívánjuk a virtuális gépet.
Cyber Recovery
A Rubrik is úgy írja le saját szavaival, hogy ez egyben egy proaktív és reaktív eszköz is. Proaktív abban a tekintetben, hogy az Isolated Recovery opción alapulva képes az Anomaly Detection-re – ransom stb – és reaktív abban, ha vissza kell állni, akkor az In-place recovery oldalon eredeti helyre vissza is tud állni ha baj van. Összességében a Cyber Recovery csak egy varázsló, ami segít nekünk összerakni azokat az Isolated Recovery terveket, amelyekhez nyúlhatunk ha gond van.
Innentől kezdve már ismerős kérdéseket tesz fel, mégpedig, hogy szeretnénk a Rubrik klaszterről kiszolgálni a mentésből bekapcsolódó virtuális gépeink IO igényét vagy éppen ténylegesen vissza akarjuk tenni az adatot az eredeti helyére és ott elindítani – tároló szempontjából értve. Alább én az eredeti helyre teszek vissza mindent.
Ezek után persze felteszi azt a kérdést is, hogy melyik mentésről legyen szó. Alább az egészséges ÉS legújabb mentést hagyom beállítva.
Ezen a ponton már feltűnhetett, hogy az isolated recovery plan létrehozását folytatjuk éppen, hiszen pontosan azokat a kérdéseket teszi fel, így például hogy hová tegye a kívánt VM-eket.
Mivel korábban azt választottam, hogy én vissza is akarom egyből állítani és nem a Rubrik-ról futtatni a VM-eket, ezért most datastore-t is kér tőlem.
A hálózati rész is ismerős lehet, hogy ne ütközzön a labor buborék az éles rendszerrel.
A szokásos sorrend is beállítható a post recovery szkriptek mellett.
Végül megkérdezi, hogy ezt kívánjuk menteni tervként vagy csak egyszeri futtatásról van szó.
Ha elmentem, akkor ténylegesen egy Isolated Recovery plan jön létre.
Összefoglaló
A sok képesség között könnyű eligazodni. Ha baj van és nincs meg már semmi, akkor recover-t kell végrehajtani. Ha legalább a vCenter Server-ben ott vannak még a virtuális gépek – az inventory-ban – de bennük az adatok sérültek, akkor In-place plan-t kell végrehajtani. Ha több Rubrik klaszter van és mondjuk egy másik adatközpont, akkor Disaster Recovery plan-nel is lehet operálni. Ha nincs baj, csak eseti alapon szeretnénk vizsgálni mondjuk azt, hogy a VM-ek tényleg elindulnak ha kell – vagy például egy patch-et akarunk kipróbálni rajtuk – akkor Isolated Recovery plan-t kell indítani. Ha ütemezetten kívánjuk futtatni ezt a tesztet, akkor pedig ütemezni kell az Isolated Recovery Plan-t.
