Mentés másként: System Center Data Protection Manager 2007
Úgy tűnik, mintha az üzemeltetéssel foglalkozó szakemberek axiómaként elfogadták volna, hogy a biztonsági mentések készítésének ideje az éjszaka, a mentések hordozója pedig csak mágnesszalag lehet. A következő írásban arra szeretnénk rávilágítani, hogy ez sokkal inkább beidegződés és kényszerűen kötött kompromisszum, mint axióma.
A következő írásban arra szeretnénk rávilágítani, hogy ez sokkal inkább beidegződés és kényszerűen kötött kompromisszum, mint axióma. A Microsoft System Center termékcsalád részeként érkező Data Protection Manager 2007 pedig egyenesen ösztönöz arra, hogy felülvizsgáljuk a megkövesedett mentési gyakorlatot és egy rendkívül rugalmas rendszerrel váltsuk fel. Az első mondatokat olvasva felmerülhet a kérdés, hogy mi is a gond az eddig olyan jól bevált mentési megoldásokkal. A teljesség igénye nélkül lássuk csak a három legfontosabbat:
Megbízhatóság
A megbízhatósággal kapcsolatban kétféle kétség merül fel. Az első kérdéskör technológiai jellegű, hiszen a szalagos egységek a jelentős technológiai fejlődés ellenére egy nagyjából ötvenéves működési elven alapulnak. A technológiai sajátosságokból adódóan a helyreállítás sikeressége függhet például az egyes egységek beállításától, kopottságától. Ráadásul ezek a meghajtók nagyszámú mozgó alkatrészt (görgők, szalagvezetők, befűző mechanikák, szervómotorok) tartalmaznak, amelyek jelentősen csökkentik a meghajtók MTBF (Mean Time Between Failure) mutatóit.
A Microsoftnál üzemelő szalagos egységek például a szakszerű üzemeltetés mellett is 17 százalékos meghibásodási arányt mutatnak éves szinten. A merevlemezek meghibásodási mutatói manapság ennél már lényegesen jobbak, nem is beszélve arról, hogy az egy gigabájtra vetített beszerzési költségük is sokkal alacsonyabb, még akkor is, ha hibatűrő rendszerbe szervezzük őket. És akkor még nem is beszéltük arról, hogy javításuk, cseréjük mennyivel egyszerűbb és gyorsabb, mint a szalagos egységeké, márpedig az idő az IT világában is egyre jobban mérhető forintban vagy más tetszőleges pénznemben.
A megbízhatósággal kapcsolatos másik kérdés az üzemeltetési gyakorlathoz kapcsolódik. Annak ellenére, hogy a legtöbb mentési szoftver felkínálja a mentések visszaellenőrzésének lehetőségét, a legtöbb esetben ezt a funkciót kikapcsoljuk, és jóhiszeműen arra hagyatkozunk, hogy a technika bizonyára precízen elvégzi majd a feladatát. Az ilyen döntéseknek leggyakrabban az időtényező az oka, de erről a következő pontban még részletesen szó lesz. Az ellenőrzések kihagyásának következményeivel majd csak akkor szembesülünk, amikor teszt vagy éles visszatöltés során olvashatatlan szalagokkal találkozunk, vagy éppen magáról a meghajtóról derül ki, hogy nemcsak most nem olvas, hanem hosszabb ideje nem is ír.
A mentési ablak beszűkülése
A legtöbb vállalatnál a biztonsági mentéseket erre a célra fenntartott időszakban készítik ("backup window"). A mentés idejére kicsit megáll az élet, korlátozzuk az alkalmazások futását, leállítunk üzleti folyamatokat és szolgáltatásokat, hogy ezzel is elősegítsük a mentések sikeres lefutását. Ez a megközelítés egy ideig teljesen működőképes lehet, de ahogy a vállalat egyre jobban épít a számítástechnika által nyújtott szolgáltatásokra, és ahogy a mentendő adatmennyiség (egyébként egyre gyorsabban) növekszik, úgy nő az esélye annak, hogy a mentéseket már nem tudjuk elkészíteni a rendelkezésünkre álló időben.
Átmenetileg persze kezelhetjük a problémát a visszaellenőrzés kikapcsolásával, a teljes mentések ritkításával, a folyamatok párhuzamosításával, de végül szembe kell néznünk azzal, hogy mindenképpen kifutunk az időből.
A szolgáltatáskiesés költsége
Különösebb közgazdasági okfejtések nélkül is belátható, hogy a komputerizáció előrehaladtával a vállalatok informatikai függősége növekszik. Vállalatunk, ügyfelünk piaci versenyben való helytállása tehát (egyre kevésbé) közvetett módon függ az informatikai háttértől és szolgáltatásoktól, amit alkalmazottként vagy partnerként nyújtunk a számára. A helyzet egyenes következménye, hogy az informatikai szolgáltatások akár csak részleges kiesése komoly veszteségekkel járhat; ezért minden vállalat és szolgáltató érdeke az ilyen esetek elkerülése vagy legalább csökkentése.
Ezen a ponton viszont szembesülnünk kell azzal, hogy magas rendelkezésreállás (vagyis a kiesés elkerülése) csak magas költségekkel biztosítható, míg a helyreállítási idő csökkentése technológiai okok (szalagos meghajtók sebessége) miatt nem lehetséges. Mielőtt az ördögi kör teljesen ránk záródna ideje tehát, hogy feladva a jól megszokott technológiákat és eljárásokat valami új megoldás után nézzünk, amivel teljesíteni tudjuk az egyre növekvő elvárásokat. Ha pedig eközben olyan eszközre bukkanunk, ami a fentieken túl még az üzemeltetési folyamatokat is egyszerűsíti, akkor mindenképpen eljött a váltás ideje.
Az új versenyző
Az első tapasztalatok alapján a System Center Data Protection Manager 2007 jó eséllyel indul a különféle "alternatív" mentési megoldások versenyében. Aki figyelemmel kíséri a Microsoft portfólióját, az emlékszik arra, hogy hasonló néven egy 2006-ból keltezett termék is létezik; tudásban azonban az inkább csak vázlat vagy előtanulmány a napokban a TechEd IT Forumon bejelentésre került új változathoz képest.
Az új változat például teljes mértékben támogatja a 64 bites platformokat, míg a korábbival (legalábbis az SP1 előtt) csak 32 bites rendszereket menthettünk, sőt maga a DPM is létezik és telepíthető 64 bites változatban. A korábbi rendszer közvetlen módon csak a fájlrendszer adatait volt képes menteni, az Exchange és SQL adatbázisokat a hagyományos módon fájlba kellett menteni (natív eszközzel, vagy ntbackup-pal), mielőtt a DPM gondjaiba vehette őket (lásd a 909644 számú tudásbázis cikket).
A DPM 2007-ben új fogalomként jelenik meg az Application Protection, amin az Exchange és SQL adatbázisok, a SharePoint farmok és Virtual Serveren futó virtuális gépek közvetlen védelmét kell érteni. Gondoljuk végig kicsit mélyebben a listát és látni fogjuk, hogy egy átlagos Windows alapú infrastruktúrából alig marad ki valami:
- fájlrendszer;
- System State (benne a registry, az Active Directory, a tanusítványtár, az IIS metabase stb.);
- Exchange adatbázisok;
- SQL adatbázisok;
- Sharepoint farmok;
- virtuális gépek (VHD fájlok)
A sokoldalú alkalmazhatóság technológiai háttere az árnyékmásolatok széleskörű és intenzív használata, ami lehetővé teszi, hogy adatbázisokat és nyitott fájlokat pillanatfelvételszerűen mentsünk. Ez a technológia az adatbázisok tranzakciós rendszerével és diszkalapú adattárolással ötvözve soha nem látott hatékonyságú mentési/helyreállítási rendszert biztosít.
Alapfogalmak
Itt érdemes néhány szót ejteni a szoftverhez kapcsolódó új szakkifejezésekről, mert a belső működés –akármennyire egyszerű is csak ezek megértése után válik nyilvánvalóvá. Minden adatmentés alapja egy kezdeti másolat (Initial Replica vagy Baseline Initial Mirror). Ekkor a DPM gyakorlatilag lemásolja a védendő adatokat legyen az egy megosztás, a System State, Exchange vagy SQL adatbázis(ok), virtuális diszk (VHD) fájl vagy a Sharepoint esetében fájlok és adatbázisok sajátos keveréke. Természetesen ezek a kiinduló mentések is árnyékmásolat technológiával készülnek, így nem szükséges az adatbázisokat vagy bizonyos szolgáltatásokat leállítani.
A kezdeti és a ráépülő további mentések az általunk választott mentési stratégiának megfelelően kerülnek elhelyezésre. A rövidtávú védelmi stratégia esetén (és általában is) az előnyben részesített cél a kiszolgálónk merevlemeze vagy egy SAN-on található logikai meghajtó. Ebben az esetben beszélünk disk-to-disk vagy röviden D2D stratégiáról. A hosszútávú stratégiát választva kapjuk a "klasszikus" szalagos mentési lehetőségeket, ilyenkor azonban számítsunk arra, hogy a visszaállítás rugalmassága korlátozottabb lesz. Ez a disk-to-tape vagy D2T megoldás. Ha teljeskörű védelmet szeretnénk, akkor természetesen a két módszert ötvözhetjük is, és ekkor disk-to-disk-to-tape mentéseket készíthetünk (D2D2T), amivel már komoly audit elvárásoknak is eleget tudunk tenni.
Az alkalmazások mentésénél találkozunk még az Express Full mentéssel, ami gyakorlatilag az élő adatbázis és a replika rendszeres újraegyeztetését jelenti. A rendszer ilyenkor meggyőződik arról, hogy a kezdeti másolatból, az árnyékmásolatokból és a tranzakciós logokból felépített szintetikus mentés valóban egyezik-e az élő rendszeren futó adatbázis példánnyal és szükség esetén javítja az eltéréseket, majd ezt az egyeztetett példányt használja a további mentések alapjául.
[oldal:Vágjunk bele!]
Az elméleti alapozás után lássuk, mivel és hogyan vághatunk neki a Data Protection Manager 2007 használatának! Először is szükségünk van egy erre a célra fenntartott kiszolgálóra. A jelentős és folyamatos terhelés miatt nem célszerű a DPM-et futtató gépünket más célokra is használni. A minimális hardverkövetelmények a merevlemezek kivételével a System Center családban már megszokottak: legalább 1 GHz órajelű, P4 osztályú processzor, 2 gigabájt memória és Windows Server 2003 R2 SP2.
Merevlemezből viszont sok. Sőt, nagyon sok. Általános ökölszabályként azt mondhatjuk, hogy a mentendő adatok minimum másfélszerese szükséges. Exchange és SQL adatbázisok esetén a kalkuláció alapja az adatbázisok mérete és a naponta keletkező tranzakciós logok mérete. A lemezkapacitás rendelkezésre állhat helyben (belső diszkek) vagy más gyors elérésű formában (SAN, vagy iSCSi). Fontos azonban, hogy az adatmentésre szánt területet NE particionáljuk és ne formázzuk meg, ezt majd a DPM dinamikus formában megteszi helyettünk. Természetesen megtarthatjuk a szalagos mentőegységeinket is és D2D2T mentések készítésére használhatjuk őket. A támogatott meghajtók listája tekintélyes hosszúságú, ideértve a robotizált eszközöket is.
A telepítés meglehetősen egyszerű folyamat, mindössze arra kell figyelnünk, hogy magán a DPM kiszolgálón és az összes védett gépen fent kell lennie a KB940349-es javítócsomag megfelelő változatának, ami az árnyékmásolat szolgáltatás harmadik generációját tartalmazza. A DPM kiszolgálón ezen felül természetesen követelmény a PowerShell jelenléte, mert enélkül nem használható a DPM Management Shell. Kisebb környezetben adatbázismotorként telepíthetünk egy helyi példányt a telepítő DVD-n található SQL Server 2005 Standard verzióból, komolyabb rendszerek esetén viszont célszerű a DPM adatbázist független SQL szerveren helyezni.
A felügyeleti felület is egyszerű és áttekinthető, nem csábít senkit arra, hogy órákat töltsön el a különféle lehetőségek felfedezésével. (Különben is ideje megszoknunk, hogy a felfedezhető dolgok mostanság a Management Shell programokban találhatók, így van ez a DPM esetén is.) A konfigurálást a Management szekcióban kell elkezdenünk. Itt a Disks szekcióban adhatjuk át a Data Protection Managernek azokat a merevlemezeket, amelyeken a rövid távú mentési stratégiánk részeként szeretnénk az adatainkat tárolni. Ezután a Libraries szekcióban beállíthatjuk a szalagos egységünket, feloszthatjuk és katalogizálhatjuk a szalagtárat, tehát felkészülhetünk a hosszabb távra tervezett mentéseinkre.
Végezetül telepítenünk kell a mentendő gépekre a DPM ügynökét, ami nem megy minden esetben simán: a tapasztalat szerint ajánlatos a telepítés előtt a helyi tűzfalakat pl. egy netsh firewall set opmode disable paranccsal átmenetileg kikapcsolni. Ha lehetőségünk van a célgépeket újraindítani, akkor azt tegyük meg, mert az ügynök csak az újraindítást követően működik megfelelően. Ha az újraindítás csak egy későbbi alkalommal lehetséges (pl. a következő karbantartási ablakban), akkor a telepítést követően mindenképpen kapcsoljuk vissza a tűzfalat. Az újraindítás után a megfelelő tűzfalszabályok már életbe lépnek és nem akadályozzák a DPM szerver és az ügynök közötti kommunikációt.
A mentések kezelése
A Protection szekcióra továbblépve állíthatjuk be a tényleges mentéseinket. A beállítás előtt feltétlenül végezzünk gondos tervezőmunkát! Mentendő adatainkat csoportosítsuk forrásuk (pl. fájlkiszolgálók, SQL adatbázisok stb.) és/vagy fontosságuk szerint! Így összeállíthatunk egy mentési tervet, ami tartalmazza, hogy milyen típusú adatokat, milyen gyakorisággal és milyen stratégiával mentünk, mennyi ideig tartunk bizonyos adatokat lemezeken és mikor tesszük át szalagra. A kialakult tervet a vállalatunknál kialakult rend szerint érdemes egyeztetni az üzleti oldal képviselőivel, a minőségbiztosítási felelősökkel és mindazokkal, akik érintettek lehetnek az adatmentés sikerességében. Egy jól kitalált mentési rendre aztán akár garantált SLA-t is vállalhatunk.
Amikor tehát tudjuk, hogy milyen adatok fognak egy mentési csoportba tartozni, akkor nekiláthatunk a Protection Groupok létrehozásának. A néhány lépéses varázslónak mindössze három érdemi pontja van: mit, hogyan és milyen gyakran akarunk menteni. Tartalmi szempontból menthetünk megosztásokat vagy logikai köteteket, System State-et, Exchange és SQL adatbázisokat, Sharepoint farmokat és virtuális gépeket. Ezeket a szokott módon a mappastruktúra böngészésével és jelölő négyzetekkel kipipálásával választhatjuk ki. (Természetesen van mód bizonyos fájlok, vagy akár egész mappák kizárására is.) A második pontban adjuk meg a csoport nevét és azt, hogy lemezre vagy szalagra szeretnénk a mentést végezni.
A harmadik lépés talán a legbonyolultabb, a "mikor" kérdése. Itt nemcsak előre, hanem visszafelé is kell gondolkodnunk. A Retention range paraméter ugyanis azt mondja meg, hogy a DPM mennyi időre lásson vissza az időben, tehát mennyi időre visszamenően leszünk képesek gyors lemezekről és sűrűbben végzett mentésből visszaállítani az adatokat. A Synchronization frequency határozza meg, hogy milyen gyakran készül pillanatfelvétel a védett adatokról, vagyis közvetlenül ez az érték határozza meg, hogy milyen mértékű lehet a maximális adatvesztésünk. A legrövidebb beállítható érték 15 perc, de ezzel bánjunk óvatosan, mert egy erősen igénybevett fájl- vagy Exchange kiszolgálón jelentős mértékű változás történhet akár 15 perc alatt is, ami jelentős terhelést okozhat mind a forrás kiszolgálón, mind a hálózaton, még akkor is, ha a DPM 2007-et egyébként felkészítették az erőforrások optimális kihasználására. A File recovery points alatt állíthatjuk be, hogy a DPM milyen gyakran frissítse a mentett adatok kiinduló állapotát (vagy egyszerűbben: milyen gyakran készítsen teljes mentést).
Az eddigi lépések alapvetően meghatározzák a mentésekhez szükséges lemezterületet, amiről a varázsló következő lépésében kapunk is egy összesítést. Az utolsó lépés a kezdeti mentés időzítése. Itt azt kell szem előtt tartanunk, hogy ebben a fázisban a teljes védendő adatmennyiség tükröződik a hálózaton a DPM kiszolgálóra és a pillanatfelvételek megindításának előfeltétele, hogy ez a mentés sikeresen végbemenjen. Tehát hagyjunk rá megfelelő időt és időzítsük olyan időpontra, amikor más szolgáltatások működését nem akadályozza!
További lehetőségek
A létrehozott csoporton még finomhangolást végezhetünk (soha ne tegyük ezt pl. kezdeti szinkronizálás közben, mert megszakítja a folyamatot!). Engedélyezhetjük a hálózati tömörítést (on-wire compression), amivel processzorteljesítményért cserébe hálózati sávszélességet nyerhetünk. Időzíthetünk napi konzisztencia ellenőrzést, ami főként akkor lehet hasznos, ha heti vagy kétheti teljes mentést állítottunk be. Ez az ellenőrzés garantálja az adatok integritását a következő teljes szinkronizálásig.
A Data Protection Manager egyik jelentős előnye, hogy támogatja távoli kiszolgálók mentését is. Minden telepített ügynökre beállíthatunk hálózati sávszélesség felhasználást munkaidőre és egyéb időszakokra, ezzel garantálva, hogy munkaidőben az üzleti alkalmazások megfelelő sávszélességhez jussanak, míg éjszakai és hétvégi időszakokban a mentéseké lehet az elsőbbség. A teljes védelem érdekében már "csak" a szalagos mentéseket kell konfigurálnunk, ezeket viszont akár hétköznapra és munkaidőre is tehetjük, tehát van alkalmunk ellenőrizni őket és beavatkozni, ha szükséges.
Az adatok helyreállítása
A helyreállítások legalább annyira egyszerűek, mint a mentések: kikeressük a visszatöltendő mappát vagy fájlt, kiválasztjuk azt az időpontot, amelyik állapotot szeretnénk visszaállítani (ez lehet egy akár 15 perccel ezelőtti időpont is!), majd megadjuk, hogy az eredeti helyére, vagy valamilyen alternatív helyre szeretnénk a visszatöltést, és már mehet is. Sőt, az általános beállításokon keresztül engedélyezhetjük a felhasználók számára is a visszatöltést! Mielőtt teljesen kétségbeesnénk a lehetőség hallatán: a felhasználók az XP-ből és a Vistából ismert "Előző verziók" funkció használatával végezhetik a visszatöltést, a kiszolgáló közelébe továbbra sem engedjük őket. Egyszerűen a DPM ügynök fog közvetítőként működni és felajánlani a DPM kiszolgálón megtalálható mentéseket a felhasználó számára.
Ha a visszaállításhoz csak részleges információink vannak, akkor a keresés funkció is rendelkezésünkre áll, így pontatlan elérési utak vagy fájl nevek esetén is van esélyünk megtalálni az igényelt adatokat. Az alkalmazások visszatöltése már valamivel bonyolultabb, hiszen Exchange esetében például beszélhetünk teljes Storage Group, adatbázis vagy postafiók visszatöltéséről. Az első két esetben dolgozhatunk közvetlenül az eredeti helyre, a visszatöltés végeztével az adatbázisok automatikusan elindulnak, sőt ha a tranzakciós logjaink nem sérültek meg, akkor adatvesztés sem lesz. Ha csak egy postafiókot kell visszaállítanunk, akkor nem kerülhetjük el a Recovery Storage Group használatát az Exchange-ben, cserébe viszont a DPM rugalmasan együttműködik az Exchange Toolbox eszközeivel, ezzel is egyszerűsítve a folyamatot.
SQL adatbázisok esetén is van lehetőségünk az eredeti helyre vagy alternatív mappába történő helyreállításra, sőt, ha hordoznunk kell az adatokat, akkor akár szalagra is történhet a visszatöltés. A tranzakciós rendszernek köszönhetően itt is lehetséges a veszteségmentes visszaállítás.
Integráció a Microsoft felügyeleti eszközeivel
Érdemes még megemlíteni, hogy a Data Protection Manager az ügynök telepítésekor automatikusan felismeri a fürtözött kiszolgálókat és minden tagra telepíti a szükséges ügynököt. Hiba esetén az adatok mentését automatikusan a másik node ügynöke folytatja. Exchange 2007 esetében az ügynökök felismerik a Cluster Continuous Replication konfigurációt és a passzív node-ot használva végzik a mentést, de nem jönnek zavarba az egyéb magas rendelkezésre állású konfigurációktól (LCR, SCR) sem.
A DPM Management Shellben minden funkciót megtalálunk, amit a grafikus felületen és vannak olyan különleges lehetőségek is, amikre csak itt találunk megoldást. Ha a mentéseket erre a célra elkülönített alhálózaton szeretnénk elvégezni, akkor a Management Shellen keresztül ezt is konfigurálhatjuk, tehermentesítve a felhasználói hálózatot. A mentési rendszer felügyeletét több szálon végezhetjük: a felügyeleti konzol Monitoring szekciójában láthatjuk az aktuális feladatokat és azok állapotát.
A Reporting szekcióban 6 előre definiált jelentést kérhetünk le, vagy időzíthetünk. A jelentések készülhetnek HTML, Excel vagy PDF formátumban, és akár mellékletként is elküldhetjük őket a mentéssel foglalkozó kollégának vagy csoportnak. A System Center Operations Manager (vagy System Center Essentials) használói pedig a megfelelő felügyeleti csomag telepítésével integrálhatják a DPM teljes felügyeletét meglévő rendszerükbe, így mindent egy helyről érhetnek el.
Hasznos olvasni- és néznivalók a DPM 2007-ről:
A Data Protection Manager 2007 honlapja
DPM 2007 technikai referencia a TechCenteren
DPM 2007-tel kapcsolatos webcastok (angol nyelven)
Somogyi Csaba
Microsoft Magyarország
Véleménye van?