Category: disaster

A mentés ronda lelkivilága

Ritkán szoktam az Exchange blogról linkelni, valahogy úgy érzem, hogy aki érdeklődik a téma iránt, az úgyis rajta lóg az rss csatornájukon. Most viszont kitettek egy nagyon-nagyon-nagyon hiánypótló írást, melyet mindenkinek el kell olvasnia, azoknak is, akik csak ezt a blogot követik. (“Ha én valamit szeretek magamban, az a szerénység.”)

Katasztrófa

Milyen már, amikor a katasztrófa-visszaállítási teszt során következik be a katasztrófa?

Elmesélem a sztorit. Tanulságos. Először ugyanis elböktük, aztán viszont kimásztunk belőle.

Mivel egy komplett datacentert kellett visszaállítanunk, mondanom sem kell, egy csomó ember nyüzsgött a munkán. Az én feladatom meglehetősen korlátozott volt, a levelezésnek kellett mennie a visszaállítás után, oszt jónapot.
Egy teljesen klasszikus CCR/SCR rendszerről van szó, többször is végigjátszottam már ilyen teszteket, bent volt egy dossziéban a szükséges egységcsomag. Nem mondhatnám, hogy túlzottan ideges voltam. A CCR/SCR replikációra ránéztem még a teszt előtt, normálisan ment.

Aztán egyik délután kilőtték a jelzőrakétát, elvágták a vezetéket a két telephely között. Másnap reggel megkérdeztem a PM-et, hogy tényleg elvágták-e a kábelt. Ja.
Oké, a disable-storagegroupcopy paranccsal kiirtottam az irmagját is a standby node-nak az éles rendszerből, majd vártam, mikor szólnak, hogy mehetek a DR telephelyre, stoppolni. (A kiirtás nagyon fontos: mint nemrég is írtam, ha fizikailag elérhetetlenné válik az SCR, akkor a backup nem törli a logokat, így viszont hamar feltelnek a logpartíciók.)

Eltelt pár nap, szóltak.

Kezdtem az első lépéssel, az adatbázisok macerálásával.

Itt most egy kis kitérő jön. Legyen már szakmai anyag is az írásban, ne csak egy szívás története.
Az SCR node az egy furcsa lény. Felkerülnek rá az Exchange dll-ek, lesz rajta konzol és shell… de Exchange szerver, az nem. Nem fogod látni sehol sem a konzolban. De még a shellben sem. A jelenlétéről is csak akkor fogsz tudni, ha néhány parancsnál használod a -standbymachine kapcsolót.
Ennek ellenére vannak rajta adatbázisok. (Még szép, hiszen ez az egész elv lényege.) Information Store, az nincs. Viszont van Microsoft Exchange Replication szolgáltatás.

Na most, mire is lehet használni egy ilyen szervert?

  • Database portability
    Valamilyen oknál fogva egy adatbázisodat egy másik szerveren szeretnéd felcsatolni. Lehet, hogy kidőlt az SCR forrásod alól a diszk alegység, lehet, hogy kidőlt a CCR-ed alól az az egy SAN, amelyiken mindkét adatbázispéldányok laktak (ugye-ugye), lehet, hogy át akarsz vinni egy adatbázist egy tesztkörnyezetbe. Nos, erre az SCR adatbázisok tökéletesek.
  • Site Resilience
    Az SCR forrásod elpárolgott. Semmivé lett. Te pedig szeretnél máshol, más telephelyen, az előzővel egyező néven létrehozni egy új szervert, majd ez alá felcsatolni az SCR adatbázisokat.

Akármelyik esetről is legyen szó – jelenleg ugye a második játszik – az első lépés az adatbázisok preparációja. Rájuk kell játszatni a logokat – és egyáltalán, olyan állapotba kell hozni, hogy az adatbázis felcsatolható legyen.
Erre szolgál a recover-storagegroupcopy parancs, méghozzá a következő szintaktikával:

recover-storagegroupcopy -identity server\sg -standbymachine scrname -force

Térjünk vissza a konkrét történethez. Kiadtam a fenti parancsot – és azt mondta az a gonosz EMS, hogy nincs ilyen nevű SCR szerverem. Nyilván begépeltem még néhányszor, hátha elütöttem egy karaktert, beírtam a teljes DNS nevével, adtam meg -domaincontroller értéket… hiába. Próbálkoztam a guglival is, de csak annyi választ kaptam, hogy ha ezt írja ki, akkor tényleg nincs a rendszerben ilyen nevű SCR.
Hát ez meg hogyan lehet?

Úgy, hogy – most nem részletezendő okok miatt – még rögtön a teszt elején pár percre összenyitották a két telephelyet. Mi történt? A címtár konfigurációs névtere egyből lereplikálódott a DR telephelyre. Benne az az információ, hogy én akkor már lebontottam az SCR kapcsolatot – azaz nincs SCR a rendszerben. Szépen vagyunk. A DR telephelyen nincs más, amiből építkezhetnénk, csak az SCR node. Ami jelenleg nincs.

Vegyük sorra a lehetőségeket.

  • Húzzunk fel egy kamu clustert az élessel megegyező névvel a DR telephelyen, majd építsünk ki egy SCR kapcsolatot? Az égegyadta világon semmi értelme sincs.
  • Tegyük vissza az SCR szervert az éles környezetbe és építsük ki újra az SCR replikációt? Ez megoldás lenne, de DR teszt során még csak gondolni sem szabad ilyesmire. Nincs éles környezet.
  • Egy korábbi system state mentésből töltsük vissza a konfigurációs névteret – azon belül is az Exchange ágat – autoritatív módon a DR telephelyen? Ez akár még működhetne is, csak éppen ekkor már az összes felesleges DC ki volt irtva a DR címtárból, a meglévők meg már annyira el voltak állítva, hogy esélytelen volt a visszatöltés.
  • Próbáljuk meg Eseutil-lal feljátszatni a logokat? Biztos, hogy a restore-storagegroupcopy csak ennyit csinál? Itt ugyanis az a gond, hogy ha mégsem, akkor nagyot bukunk, mivel a különbség nem itt derül ki, hanem egy későbbi lépésben. Ahonnan már nincs visszaút. És akkor már nincsenek adatbázisok sem, ergo bedőlt a DR teszt levelezési része, az meg azért túl nagy blamázs lenne.

Maradt a jó öreg magyaros megoldás, a buhera. Amit biztosan tudtam, az az, hogy az SCR beállításai a címtár konfigurációs névterében laknak, méghozzá az Exchange Services ág alatt. Mi lenne, ha megkeresném ezeket és úgy csinálnék, mintha lenne még SCR node a rendszerben?
Az első probléma ott volt, hogy honnan találom ki, hol vannak ezek az értékek? A DR telephelyen már nem volt SCR, de az élesen sem. Szerencsére volt hozzáférésem más, hasonló rendszerhez, beléptem, turkáltam. Hadd ne mondjam végig a folyamatot… itt van az eredmény. A beállítások a Storage Group objektumokon vannak (mindegyiken egyenként), méghozzá az MsExchangeStandByCopyMachine nevű változóban, a következő kódolással:

scrname.domain.name;1;xx:xx:xx;yy:yy:yy

Ahol az xx:xx:xx a replaylagtime, az yy:yy:yy pedig a truncationlagtime. Az 1-es értékét nem tudom – de őszintén szólva, nem is érdekel. Nem szándékoztam működő SCR-t létrehozni, csak behazudni a címtárnak, hogy az scrname nevű gépem valóban SCR target volt.

Óvnék mindenkit, hogy éles rendszerben ezeket az értékeket módosítsa. A Microsoft hivatalos álláspontja szerint az SCR replikáció paramétereit csak úgy lehet megváltoztatni, ha lebontjuk a replikációt, majd az új paraméterekkel újra létrehozzuk. Nyilván okuk van rá.

Hozzáteszem, a kockázat most is megvolt. De csökkent! Ha Eseutil-lal esek neki, akkor esély sincs rá, hogy a restore-storagegroupcopy esetleges plusz műveletei lemenjenek. Ha viszont behazudok egy SCR-t, akkor lehet, lefut a restore-storagegroupcopy, a továbbiakban meg már kell a fenének az SCR.

Kiválasztottam egy adatbázist, preparáltam, majd lefuttattam rá a restore-storagegroupcopy parancsot. Molyolt, molyolt… majd a várt 1 warning helyett kettő dobott. Ennek azért nem örültem olyan nagyon, tekintve, hogy a plusz figyelmeztetést olyan szinten voltam képtelen értelmezni, hogy még az se derült ki belőle, hogy lefutott-e a parancs? Vadul nekiálltam túrni a netet, de nem találtam megnyugtató választ. Lefuttattam még egyszer a parancsot… erre megint azt mondta, hogy nincs SCR. Háteztmeghogyan? Hiszen éppen az előbb hazudtam be, hogy van?
Vissza az adsieditbe… és tényleg nem volt ott a beírás. Valaki törölte. Tehát van egy érthetetlen warning-om és belefutottam egy önvédelmi mechanizmusba. Nem túl biztató.

Elvonultam gondolkozni.

A kulcs az, hogy a warning ellenére tényleg megcsinálta-e mindazt, amit tennie kellett? És csak utána törölte-e ki az általam beírt adatokat a védelme?
A törlés biztosan utólag történt, mert hibaüzenetet csak az újabb futtatáskor kaptam. De az a warning… Ráküldtem a parancsot a -verbose paraméterrel. Nem lettem okosabb. Végül úgy döntöttem, hogy ha tényleg képtelen lett volna elvégezni a dolgát – akár egy kezdeti ellenőrzés után is – akkor itt hibaüzenet lett volna, nem figyelmeztetés. Meg egyébként sincs más esélyem, csak ez.
Behazudtam a fenti string-et az összes storage group-nál, beírtam az alábbi parancsot, és malmoztam.

get-storagegroup | restore-storagegroupcopy -standbymachine scrname -force

Jó jel volt, hogy nagyon sokáig dolgozott.

Aztán nagy levegő, gyerünk tovább. DNS preparáció, AD jogosultságok állítása, majd jöhet a vízpróba. Cluster telepítése, a recovercms kapcsolóval. Prerequisit-ek ellenőrzése. 10 perc. Az életemből a tízszeresét vette el. Végül átszaladt rajta. Most jött a döntő pillanat: az első adatbázis felcsatolása.
Sikerült. Aztán szépen egyenként az összes.

Innentől meg már a jól ismert ösvényen mentünk tovább.

Nem az idegbetegek sportja

Exchange és backup… nem dúl közöttük a barátság. Pedig a backup látszólag nem túl bonyolult dolog: egy adott állapotról másolatot kell készíteni. Már az Exchange 5.5 is tudta, hogy amikor elindult a mentés, akkor “befagyasztotta” az adatbázisokat, ezeket lementette, a mentés alatti adatforgalmat ideiglenes adatállományban tárolta, majd a mentés végén az ideiglenes állomány tartalmát rámásolta az élesre. Ennyi.
Mi lehet a baj?

A tudományos fejlődés.

Az hagyján, hogy a tervezők rájöttek arra, hogy a logfájlokkal rengeteg kunsztot lehet bemutatni: full/copy/inkrementális/differenciális backup… ezek régi dolgok. De a cluster koncepció megváltozása, a tranzakciós logokkal bűvészkedő replikációs fürtök már belecsaptak rendesen a lecsóba. Nem is beszélve a fájlmegfogást megkerülő shadow copy-ról, melynél már nem kell vacakolni ideiglenes állományokkal, a VSS writer tud írni akkor is, ha meg van kötve a keze.
Csak éppen maga a folyamat annyira bonyolult lett, annyira sérülékeny, hogy bármilyen kis rendellenesség hetekig tartó kilengéseket képes produkálni. Gondoljunk bele: egyrészt a Windows 2008-ból eltűnt az Exchange mentés lehetősége, később persze visszajött, de bénán: csak egész kötetet enged menteni. Ha ennél finomabb eljárásra van szükségünk, akkor jöhetnek a külső gyártók. Figyeltél? Külső gyártók. Na, innen indul el a totális káosz. Van egy érzékeny, ráadásul a Rollup Packokkal sűrűn változó rendszer, meg a tipikusan lomha és ügyfélérzéketlen külső gyártó. Pusztán csak idő kérdése, hogy jöjjön az a bizonyos apró rendellenesség, melytől hetekig leng a rendszered.
Mi is az, hogy leng? Ha nem megy a mentés, nem törlődnek a logok, ha betelik a logpartíció, megáll a levelezés, ha törlöd a logokat, megáll a cluster replikáció. Egyáltalán nem véletlen, hogy az Exchange team már évek óta azért küzd népnevelésügyileg, hogy felejtsük már el azt a nyűves backupot, próbáljuk meg kiváltani más technológiákkal.

Csak éppen ebben a népművelésben kicsit sok még a köd. Oké, csinálj clustert (CCR, DAG). Ezzel kivédted a katasztrófát. Ha geoclustert csinálsz, akkor elviseled még a telephelyed megsemmisülését is. Great. De mi van a törölt adatokkal? Használd a dumpstert. Remek számítások vannak arra nézve, hogy akár egy évnyi(!) dumpster mennyivel növeli meg az adattárolási kapacitást. Igaz, az Exchange 2010 alá már közértben vásárolható vinyók is jók, de a hosszútávú dumpster egy átlagos felhasználónál durván évi 1,5 GB növekményt jelent. Oké, természetesen lehet trükközni még az archiv postafiókkal is, de azért itt már komolyan neki kell állni számolgatni, mi is az olcsóbb. Azt ugyanis nem szabad elfelejteni, hogy értelmes összegből akkor lesz egy rendszer backupless, ha eleve annak is tervezik. A legtöbbször már van egy SAN, benne egy vagy két rohadt drága storage, azt mondani, hogy ezt innentől tessék nyugodtan kidobni… elég necces. Brutálisan felbővíteni… szintén.

Itt eredetileg egy eszmefuttatás lett volna arról, hogy és akkor mit csinálunk a módosított adatokkal? Ehelyett meaculpa van. Utánaolvastam, és most már tudom, hogy a dumpster 2.0 verziózni is tud. Persze ekkor megint visszajutottunk oda, hogy tárterület, lapátszámra. Különösen, ha egy cégnek mondjuk 5 évre visszamenőleg kell megőriznie a levelezését.

Illetve gondoljunk át még egy szempontot. Ha nincs backup, mi takarítja el a logokat? A Köztisztasági Vállalat nem fogja. Mi is volt a logika a mentés utáni logtörlésekben? Az adatoknak minimum két helyen meg kell lenniük. Eredetileg ez az adatbázis (RAM+HDD) és a log, a mentés után az adatbázis (HDD) és a szalag. Azaz lehet törölni a logot. Ha nincs backup, nincs törlés. Nyilván utánaolvasol, azt találod – de nem túl hangosan reklámozva – hogy használj 3 node-ból álló DAG-ot (mert ekkor nem kell RAID sem, jó a JBOD), ha van rá pénzed, legyen egy lagged copy is, és ha nem akarsz menteni, akkor kapcsold be a cirkuláris logolást. Az Exchange adminok itt kapnak a szívükhöz: 13 éve azt hallják, hogy négy láb jó, két láb rossz, cirkuláris logolás meg a legrosszabb. Elfogadom, tudnunk kell kigondolkozni a dobozból, de valahogy még mindig meglehetősen el vannak rejtve az infók.

Egyáltalán nem meglepő, hogy egy átlagos informatikus – nem beszélve az átlagos IT vezetőről – sokkal inkább azt mondja, hogy backup.

Akit esetleg mélyebben érdekel a dolog, itt talál egy nagyon részletes négyrészes írást Henrik Walthertől. Kötelező darab a tisztánlátáshoz. De a végén tessenek elgondolkodni, mi is a feltétele a 4. részben leírt visszaállításnak.

Na, a hosszú bevezetés után jöjjön a sztori.

Előzmény. Az egyik adatbázis – kampányszerű üzleti tevékenység miatt – bevadult. A logfájlok kihízták a logpartíciót, adatbázis megállt. (Olyan gyors volt a feltelés, hogy bár a figyelő rendszer beriasztott, de mire beavatkozhattunk volna, már fejre is állt minden.) Oké, a logkönyvtárat a már ismert módon áttettük máshová, adatbázis visszaindult.

Nem sokkal később a CCR/SCR rendszerben volt egy failover, majd valamivel később egy failback. A backup külső gyártó szoftverével volt megoldva, méghozzá úgy, hogy a passzív node-ról – és csak arról – ment VSS backup-pal. Egy bibi volt, a szoftver képtelen lekövetni, melyik node a passzív, így azt tudtuk csak beállítani, hogy arról a node-ról mentsen, amelyik az idő nagyobb részében a passzív node. Ez borult fel a pár napos csere miatt és a backup szoftver teljesen bele is zavarodott.

Közben a szerelők felpumpálták a korábbi adatbázis logpartícióját, lehetett visszarakni a logokat. A művelet teljesen hasonlóan zajlott, az eredmény viszont lesújtó lett: az adatbázist ugyan fel lehetett csatolni, de a replikáció failed állapotba került.

Több évnyi tapasztalat után határozottan ki merem jelenteni, hogy az esetek 90%-ában ilyenkor semmi más nem segít, csak a reseed. Nos, most belefutottunk abba a bizonyos 10%-ba: a reseed sem segített. Fejvakarás. Az eventlog szerint hiányzik egy csomó tranzakciós log, és mindenki az anyja életére esküdött, hogy nem ő dugta el. Ekkor derült ki, hogy nem megy a backup, azaz folyamatosan telik fel az összes logpartíció. Miközben reménytelenül nem megy az egyik adatbázisra a logreplikáció. Nem túl biztató a helyzet.

Kipróbáltunk ezt-azt, ahogy az ilyenkor szokás. Nyilván volt közte néhány failover/failback is. Az egyik különösen izgalmasra sikerült, hosszú percekig nem történt semmi, aztán egyszer csak beröffent a cluster. Aznap nem is mertünk hozzányúlni többet.
Másnap összegyűlt a válságstáb. A partíciók monoton teltek befelé, ötlete meg senkinek sem volt. Pontosabban, nekem volt még egy, de azt mondtuk, hogy ha ez sem jön be, akkor eszkalálunk az MS felé.
De mielőtt nekiállhattunk volna, jött az SMS az üzemeltetőtől, hogy reggel ránézett a rendszerre és teljesen váratlanul megjavult a backup. Magától.
Pár hajam azért égnek állt. Megnéztem, és tényleg. Az összes logpartíció tiszta volt… kivéve a replikálatlan adatbázisét.
Huh. Ezt megúsztuk. Bár a fene tudja, hogyan. Én összeraktam ugyan egy elméletet, miszerint a hosszú failoverbe belehülyült a backup szoftver és nem vette észre a failback-et. Emiatt próbálkozott folyamatosan az akkor már aktív node-on, de ez a backup szoftver meg arra képtelen. (Ezeknek a próbálkozásoknak a nyomait láthattuk is.) Ez ment addig, amíg az egyik failback után hirtelen nem realizálta, hogy jé, failback történt. (Ez lett volna az az idegesítően hosszú failback.)
Hülye elmélet, de nem találtunk jobbat.

Kihasználva a lendületet, aznap délután ráküldtem a renitens adatbázisra is egy reseed-et. Hátha ma olyan nap van, hogy minden sikerül. Nem jött be. Másfél óra szuttyogás, aztán a suspend után ugyanúgy ott vigyorgott a failed.

Másnap éppen nagy paláver volt, a sok futó ügy mellett rátértünk erre az esetre is. Sok jót nem tudtam mondani. A logok replikációja a CCR vérkeringése, ha kiesik belőle egy logdarab, azt a replikációt az életben nem rázzuk gatyába. Legegyszerűbb javításnak azt javasoltam, hogy hozzunk létre egy új adatbázist, mozgassunk át mindenkit, majd töröljük a sérült replikációjút. Erre mindenki rá is bólintott, az üzemeltetők elkezdtek teszt postafiókokat mozgatni. (Mert ekkor éppen nem jutott eszembe a disable-storagegroupcopy parancs.)

Délután két üzenetet is kaptam. Az egyik az volt, hogy nincs semmi gond a postafiók-mozgatással. A másik az, hogy nézzek már rá a storage groupra, mert gyanúsan és makacsul úgy néz ki, mint aki egészséges. Ránéztem… és tényleg.
Na, ilyen nincs. Ekkor kerültek bele a fognyomaim az asztallapba. A többi mellé. Ugyanaz a történet, és már másodszor fordul elő, hogy miután fekete színekkel ecseteltem a jövőt, váratlanul megjavult a rendszer. Magától.
Szerencsére elméletgyártásból borzasztó jó vagyok, egy kis idő után itt is találtam valószínűnek tűnő magyarázatot.

Kapkodtam. Amikor ráküldtem a reseed-et, nem vártam eleget. Ha csináltál már ilyesmit, akkor tudod, hogy egy suspend/resume páros után a replikáció mindig healthy állapotot mutat, majd 1-2 perc várakozás és egy refresh után mondja csak meg az igazi értéket. Na, én éppen fordítva jártam, failed értéket mutatott a reseed után, aztán pár perc múlva váltott át healthy-be. Csakhogy akkor én már éppen hazafelé utaztam. (Hogy ne hidd azt, hogy én a fantáziámból élek. A passzív node-on lévő logok dátum értékéből ki tudtam olvasni, mikor röffent be a replikáció. Ebből tudtam, hogy pár perccel később, mint ahogy előző nap bezártam a terminálablakot.)

Na, mindegy, vészforgatókönyv lefújva. Tulajdonképpen minden rendben. Megy a backup, megy a replikáció, madarak ülnek vérebekhez. Eltekintve attól a szépséghibától, hogy a passzív node-on 1 napnyi log volt, az aktívon meg egy heti. De mivel mind a replikáció, mind a backup ment, meg voltam győződve róla, hogy ez a baki hamarosan rendeződni fog.

Nem így történt.

Eltelt két nap, a backup ment, a replikáció szintén… de a logok csak gyűltek. Alapvetően egy Exchange admin élete nem túl bonyolult, csináltam egy újabb reseed-et. Simán lepucolta a logokat a passzív node-ról. Alakul. Az aktív node-ról elmozgattam máshová a replikáció beindulása előtti logokat (ezek biztosan nem játszanak a replikációban), majd trükköztem egyet. Failover. Ekkor az aktívból lett passzív node. Újabb reseed. Innen is lepucolódtak a logok. Failback.

Elégedetten dőltem hátra. Kifogtam a rendszeren… és végre valamit én javítottam meg, a saját agyammal. Replikáció szépen megy, mindkét node-on üres a logpartíció, copyquelength, replayqueuelength értékek masszívan nullák. Tökély.
Persze az abszolút megnyugvás akkor következik be, ha este lemegy a backup és törli is a logfájlokat.

Nem törölte.

Ha láttál már gyilkos tekintetet… akkor szorozd be kettővel. A jelek szerint minden tökéletesen működik… csak éppen a backup nem törli a logokat. Mivel a szituáció egyfelől nagyon általános, másfelől nagyon speciális, esély sincs megoldást találni a guglin.
Marad a szörfözés az eventlogban. Jegyzetfüzet, plajbász, göngyölítsük fel, mi is történik a mentés során. Semmi rendkivüli. A VSS writer megkapja a kérést, összekészíti az adatbázist, a mentő szoftver elviszi, majd jelzi az ESE-nek, hogy a részéről mehet a log file truncation. Az ESE visszaszól, hogy oké, ahogy születik az új loggeneráció, törli a régit. Majd pár órával később egy replikációs lépés során megemlíti az aktuális generáció számát, mely jóval magasabb, mint amit korábban jelzett. Azaz megtörtént a generációváltás – és minden igérete ellenére, az ESE nem törölte a logokat. Őrület.
Gondolkodósarok. Mikor nem törlődnek a logok? Amikor a replikációnak még szüksége van rá. (Emiatt van az, hogy hiába állítod cirkulárisra a logolást egy CCR rendszerben, amíg nem történik meg a logok replikációja, addig nem harap saját farkába a kígyó.) Jó… de ezzel beljebb vagyunk? A replikáció tökéletesen megy. Két ablakban egymás mellé téve a könyvtárakat, akár még animációnak is elmegy, ahogy keletkeznek, vándorolnak.

Kész, itt adtam fel. Egyrészt volt mellette más, igen sürgős munkám, másrészt meg elfogyott a puskapor. Látszólag minden tökéletes, gyakorlatilag meg nem. Hogyan keressek hibát, ha nincs semmilyen nyom?

Hiba volt feladni. Légyszives olvasd el alaposan az eddig írtakat. Minden információ ott van benne, ami a megoldáshoz szükségeltetik. Lehet, én is megtaláltam volna(1), ha nem azon a bizonyos másik munkán járt volna már nagyobbrészt az agyam.

Mindenesetre a beavatkozás nem tűrt halasztást, a logfájlok megint gyarapodtak, a logpartíció szépen telt, telegetett. Microsoft PSS. Leírtam szépen mindent, amit az esettel kapcsolatban tudtam, az üzemeltető kolléga lett a kontakt, én maradtam cc-ben.

Rögtön az első felvetés beletalált a tizes körbe. Ez ugyanis nem szimplán CCR, hanem SCR rendszer is. Csak éppen azzal a szerencsétlen SCR szerverrel soha nem foglalkozik a kutya sem. Azaz ha egyszer, csak úgy véletlenül, beírtam volna a get-storagegroupcopystatus parancs paraméterei közé a -standbyserver kapcsolót, rögtön kiugrott volna, hogy az SCR replikáció még failed állapotban van azon a bizonyos adatbázison. Emiatt volt még szükség a régi tranzakciós logokra, emiatt nem törölte azokat az ESE. Természetesen rögtön nekiugrottunk annak is egy reseed-del, majd amint helyreállt a replikáció, az esti mentés törölte is a logfájlokat. Ahogy kellett.

(1) Különösen úgy, hogy egyszer már ki is írtam magamnak figyelmeztetésként. Azóta egy másik ügyfélnél csináltunk egy katasztrófa utáni visszaállítás-tesztet, és amikor elővettem a korábbi jegyzeteimet, ott vigyorgott az egyikben a kiemelés:

If the SCR source is a clustered mailbox server (CMS) in a CCR environment, the log truncation logic includes successfully copying and inspecting the log files by all SCR targets. This means that if an SCR target is not available, log truncation does not occur on the SCR source even if backups are taken.
http://technet.microsoft.com/en-us/library/bb676465(EXCHG.80).aspx

Exchange backup módok

Habár a végén belekerült egy kis reklám is, és a cikk részletesen az Exchange 2003 mentésével foglalkozik, de mindenképpen a kötelezően elovasandó írások közé tartozik.
Ha tudni szeretnéd, mi is zajlik pontosan adatbázis-mentés közben, akár egy streaming, akár egy VSS mentés során, akkor feltétlenül fusd át.

Link:
Exchange Backup és Restore

Echange 2007 és backup

Ki tudja, mi a viszony az Exchange 2007 és a Windows Server 2008 NtBackup programja között? Illetve, ha már itt járunk, mi a helyzet a Windows Server 2003 NtBackup programjával?

Az első kérdésre könnyű a válasz: a Windows Server 2008-nak nincs NtBackup programja. Pont. A beépített backup program (Windows Server Backup) nem ismeri az Exchange szervert, ergo képtelen menteni is az adatállományait, képtelen kezelni a tranzakciós logokat. Pont. Akinek nem tetszik, el is lehet költözni az országból.
Azért szerencsére ennyire nem durva a helyzet. Megint egy remek iterációs folyamatot figyelhetünk meg. Először az Exchange és a Windows Server 2008 team-ek dugták össze a fejüket, mint megannyi hétfejű sárkány. Aztán azt sütötték ki, hogy tele van az ipar jobbnál jobb külső gyártók jobbnál jobb (oké, csak viccelek) termékeivel – miért kellene annyit görcsölniük a Windows Server Backup-pal? És ebben tényleg van valami, én itt Magyarországon még egy ügyfélnél sem találkoztam NtBackup-ra épülő Exchange mentéssel – pedig mi az amerikai cégekhez képest maximum kerekítési hibák vagyunk. (Na jó, a MOL-nak megszavazok egy nullával való osztást is. 🙂 )
Így is lett. Csakhogy amint ez az egész kiderült, vérig sértett SOHO rendszergazdák kötözték magukat a redmondi mamutfenyőkhöz. Erre beindult a negyedrangú rungekutta, az algoritmus végén pedig kiiterálódott a megoldás: az Exchange-s fiúk készíteni fognak egy plug-int a Windows Server Backuphoz, melynek segítségével VSS-re épülő(!) mentést tudunk készíteni a gyári programmal az Exchange szerverről, tudunk majhd játszani a logtörlésekkel, meg ilyenek. Bár a fejlesztók sejtelmesen megcsillogtatták, hogy a granularitás nem lesz az igaz, de az nem derült ki, ez miben is fog megnyilvánulni: nem lehet majd adatbázis szinten menteni vagy nem lehet inkrementálisat/differtenciálisat menteni? Nem tudjuk. Az egész még csak ötlet szintjén létezik.

Na és akkor mi is a helyzet a 2003 világban? Létezik NtBackup, ismeri a VSS-t, integrálva van az Exchange 2007-tel is. De vajon tudunk-e árnyékmentést végezni Exchange adatbázisról? Nos, VSS ide vagy oda, nem. Illetve igen. Pontosabban, attól függ.
Nagyon nem mindegy, ugyanis, hogy egy adatbázisra pusztán fájlként tekintünk-e? Ekkor működik ugyan a VSS, de az elmentett adatbázis állapota ‘dirty shutdown’ státuszú lesz – és ha belegondolunk, ez teljesen normális is, hiszen nem lettek rájátszva a logok. Ha viszont Exchange-et is értő mentést akarunk készíteni NtBackup-pal, akkor felejtsük el a VSS-t. Ilyesmit csak külső backup programmal fogunk tudni.

Linkek:

Házirendetlenül

Mint GT is rámutatott, az, hogy én létrehozok a nem működő, megsemmisült, sóvel beszántott default gpo-k helyett egy-egy hasonló nevű csoportházirend objektumot, nos… az nem az igazi. A rendszer, pusztán csak név alapján nem fog ráismerni. Hogy egész konkrét legyek, a rendszer csak akkor ismerne rájuk, ha az egyiket 31B2F340-016D-11D2-945F-00C04FB984F9-nek, a másikat meg 6AC1786C-016F-11D2-945F-00C04FB984F9-nek nevezném el – de természetesen ezek a nevek már foglaltak voltak.

Szokásos vadászat a neten, majd viszonylag hamar meg is lett a dcgpofix.exe progi neve. Meg a leírás is, hogyan kell használni. Az én esetemben borzasztó egyszerűen: be kellett írnom a parancssorba, majd minden rémüldözésekor yes-t nyomni. (Mondjuk előtte aprólékosan lejegyzeteltem a GPO-k ACL értékeit. Az ördög nem alszik. ADUC/System/Policy/GUID.) Még hozzá kellett rendelni a GPO-kat a megfelelő objektumokhoz, kitörölni a kamu GPO-kat – és már ment is minden.

Végül még lokálisan is rendet kellett tennem. Ez annyiból állt, hogy most, miután már megvoltak a default GPO-k, ráfutattam mindkét DC-re a DC security sablont. Ez az a sablon, mely akkor jön létre – és húzódik rá a gépre – amikor előléptetjük tartományvezérlővé.

Most nagyjából rend van a Futrinka utcában.

Nem hivatalos rekordkísérlet

Ma olyan délutánom volt, hogy két gépen egyszerre 11 Terminál konzolból dolgoztam. Pörgött a kezem, füstölt a fejem… de sikerült minden.

  • Az egyik cégnél beröffent az egy hete működésképtelen Exchange 2007 OWA proxy.
  • A másik cégnél lecseréltem egy tűzfal mögötti tartomány összes tartományvezérlőjét Windows2003 szerverre, majd előléptettem a tartományt w2k3 módba.

Most egy hosszú szundikálás a metrón, majd jön az otthoni műszak.

[Update]

Azt hiszem, elkapkodtam ezt a délutáni bejegyzést. Mielőtt ugyanis előléptettem volna azt a tartományt, a biztonság kedvéért gyorsan leellenőriztem egy-két dolgot.
A hajam is égnek állt.
Először csak a replikáció nem ment.
Aztán a tartomány tokkal-vonóval leszakadt az erdőről.
Később már az Atyaúristens jogú felhasználómnak sem lett rá joga. Az erdő közölte, hogy olyan tartomány márpedig nincsen.

Na, ekkor füstölt csak igazán az agyam.

De végül meglett. Tudni kell, hogy ez ugyanaz a szutyok tartomány. Egész egyszerűen az történt, hogy a múltkori kavarás után a _pdc srv rekord értéke rossz helyre mutatott ugyan, de mivel az a gép még tagja volt a tartománynak, valahogy csak megtalálták a többiek az eldugott tartomány pdc emulátorát. Csakhogy most minden régi DC demotálva lett, az erdő pedig végképp elveszítette a fonalat. Természetesen az időszinkron is elment.
Most nagyzolhatnék, hogy mindezt brilliáns elmével következtettem ki, de nem lenne igaz. Bizony, ez egy kemény rakkolás volt, gyakorlatilag mind az öt – srv rekordokat tartalmazó – zónát egyenként csekkoltam át, hol találok valami rendelleneset. Szinte csak azt találtam. De végül összelegóztam mindent, kiszórtam a francba minden új link objektumot, hagytam, hogy a kcc elrendezze a dolgot, végül ki is segítettem néhány manuális konnektorral.
Juhé.

Innen már csak a GPO-kat kellett visszaállítanom, ugyanis az összes úgy elszállt, mint a győzelmi zászló. A teljes Sysvol – azaz Policy és Netlogon – csont üres lett. Bezzeg az eventlog…

Van erre egy jó módszer. Érdemes végigrágni, olyan területekre kaphatunk bepillantást, melyekről nekem eddig fogalmam sem volt, pedig elég régóta benne vagyok már az AD bizniszben. Csak a megértés volt egy félóra, a végigjátszás meg a duplája. És persze nem működött úgy, ahogy elképzeltem. (Én már annak is örültem volna, ha az egyik DC létrehoz egy szűz új struktúrát, a másik pedig átveszi. Csak működjön már végre a GPO szerkesztés.)
Végül a megoldás pofonegyszerű volt: habár a régi házirendekhez nem lehetett hozzányúlni, új objektumokat mégis engedett létrehozni. Utána már törölhettem a régi elárvult bejegyzéseket, az új házirendeket meg majd bekalapálja a helyi rendszergazda. Ha használta egyáltalán.

Boldog új évet!

Valamelyik népművelő csatornán láttam régebben egy filmet a német tengerészet csúcs hadihajójáról – és arról, hogyan sikerült elsüllyeszteni. Ez jutott eszembe, ahogy a tegnapi éjszaka során folyamatosan süllyedtem én is a letargiába.
A hadihajó a világ egyik legerősebb hajója volt. Tulajdonképpen sebezhetetlennek készült, egy apró hibával. Ha megfelelő szögből belőttek az egyik tatbudi 10 centis ablakán, akkor eltalálhattak valami robbanásveszélyes berendezést, melytől levegőbe röpülhetett a tatfedélzet.
Az egészről film volt. Látszott a viszonylag kicsike angol hajó és a bazi nagy német hadihajó, ahogy szép kényelmesen fordul oldalra, hogy lesorozza a felszínről az angol jószágot. Aztán egyszercsak valamelyik angol belepukkantott egyet a nagyvilágba – és mit ád Isten, a lövedék pont bement a budiablakon, a hajó meg fordulás közben épp a kritikus szögben volt. A következő pillanatban felrobbant a német hajó segge és szép lassan befordult az egész a tengerbe.

Képzeld el, hogy van egy címtárad, meg egy Exchange szervered. Az ügyfelünknek is volt. Aztán január másodikán hajnali négykor a vacak, kifejezetten csak tartalékcélokra szolgáló PIII WS kategóriájú DC2 merevlemeze diszkrét pukkanással elhalt. Dugovics Tituszként magával rántott egy computer objektumot is a címtárból.
Ez még nem olyan nagy tragédia: a DC-t ki kell irtani, újat kell rakni helyette, a computer accountot meg resetelni kell. Mint ahogy Cary W. Shulz – Active Directory MVP – is írja:

There are user account objects just like there are computer account objects. The computer account objects have a secure channel with a Domain Controller. Over this secure channel the workstation and the Domain Controller communicate. In WIN2000 the computer account objects change their secret password every 30 days ( in WINNT 4.0 it was seven days ). Sometimes this secure channel gets flubbed up…for whatever reason. So, based on what I just wrote you can see how this can create a little bit of a problem. So, in order to resolve the problem of the flubbed up secure channel you Microsoft gives us the ability to reset that secure channel.

Illetve később Bizonyos Steve hozzáteszi:

In that scenario I would reset the Computer account first before trying the remove/add to domain. This works for me 99% of the time, the 1% usually require the remove/add method.

Csakhogy… gondolj bele, mi történik akkor, ha a flubbed account pont egy Exchange Server computer accountja – és bejön az 1%, azaz az account reset sem segít.

Hagyok időt végiggondolni.

A fent említett remove/add módszer értelemszerűen nem működik. Pontosabban meg lehet csinálni, de onnantól az Information Store az életben sem fog elindulni.

Az esetet a kollégám kapta tüdőre. Reggeltől estig a tartományt foltozgatta: vacak DC eltávolítása, tartományi replikáció beindítása, kismillió anomália megszűntetése, új DC üzembeállítása, makacs account resetelgetés… nem segített. Este héttől váltottunk, mint a pankrátorok: arénából ki, arénába be, high five.
Mit láttam?

  • Az Exchange szerveren a szolgáltatások leállítva, mert minek fussanak.
  • Az Exchange szerveren a tartományba belépni nem lehet: azt mondja, nincs olyan account.
  • A netdom join azt mondja, hogy már van ilyen account.
  • Amikor elrontom szándékosan a jelszavamat, akkor azt írja, hogy rossz a jelszó. Azaz a DC – és az AD – elérés tökéletes.
  • Amikor kitiltom a computer accountot, akkor azt írja, hogy ki van tiltva. Az AD acélos.
  • Próbaképp egy munkaállomás beléptetése: tökéletes.
  • Az eventlog alapján az account “Access Denied”.
  • Ha everyone full control-t állítok rajta, akkor is.

Brainstorming.

  1. Vegyük ki a tartományból majd tegyük vissza. Hevesen tiltakoztam. (Lásd korábban.)
  2. Promotáljuk DC-vé, majd az account reset után demotáljuk vissza sima szerverré. Újabb heves tiltakozás. (A dcpromo és az Exchange nem férnek meg egy csárdában. Ha ráküldjük egy Exchange szerverre, akkor tönkrevágja az IIS-t meg az asp.net-et, újra kell húzni mindkettőt. És utána belassul, meg össze-vissza működik. De a fekete leves a következő lépés: demotáláskor az IIS és az AD megszűnik egymással kommunikálni. Nem csak a kérdéses szerveren, hanem az egész organizációban. Nem kicsit durva.
  3. Gondolkozzunk. Mi mehetett tönkre? Az AD szépen működik. Az Exchange számítógéphez nem nyúlt senki, az adatbázisok tutira jók. A network, névfeloldások tökéletesek. Ha valami itt elromlott, az csak a computer objektum lehet.
    Hmm… állítsuk vissza. Elméletileg létezik korlátozott hatósugarú autoritatív restore.
  4. Megpróbálkozhatunk egy éles Exchange disaster recovery-vel is. Persze, tudjuk, hogy az Exchange tökéletes, de ha eljátszanánk, hogy ugyanazzal a névvel átraknánk az Exchange szervert egy másik gépre, talán ki tudnánk erőszakolni egy account reset-et.
  5. Persze nem kizárt, hogy az az elkefélt computer account ellenáll ennek az invitálásnak is. Akkor nincs más hátra, csinálunk egy új Exchange szervert más névvel, átmásoljuk rá az adatbázisokat, a felhasználóknál – szerencsére nincs sok – töröljük az Exchange tulajdonságokat, majd létrehozunk mindegyiknek egy új postafiókot, MAPI profilt, a régi Exchange szervert kiradírozzuk, végül egy offline adatbázismatyizóval kiszedjük pst-kbe a régi leveleket és visszalapátoljuk a felhasználók postafiókjába. Elég gusztustalan, de B tervnek megteszi.

Az utolsó három igéretesnek tűnik. Tudjuk, csak a kombinált bérlet a biztos. Ilyen sorrendben pont jó is lesz nekiindulni az éjszakának.
3. pont. Ahhoz bizony kell egy system state mentés is.
– Van? – kérdezem a helyi rendszergazdát.
– Persze – vágja rá.
Aztán nem sokkal később jön a helyesbítő telefon.
– Volt – közli – Azon a merevlemezen tartottuk, amelyik elpukkant.
Feltúrjuk a gépeket, az egyiken végül beleakadtunk egy két évvel ezelőtti systemdrive+systemstate mentésbe. Volt már akkor ez az Exchange szerver? Éppenhogy: 3 hónappal előtte lett telepítve. Nagyon necces. Nézzük csak, hogyan működik Windows 2000 szerveren az autoritatív restore? Aszongya, belépünk Directory Restore módban, visszatöltünk egy komplett systemdrive+systemstate mentést(!), majd ntdsutil-lal kijelöljük, melyik OU-t akarjuk megtartani, utána újraindítjuk a gépet, mely magára rántja az AD-t. Hát… ennek csak egy veszélye van, az, hogy működik. Gondoljunk bele, visszarántunk egy két évvel ezelőtti állapotot. Lehet, hogy akkor még nem is maguktól tekertek a bitek az alaplapon, hanem kis zöld emberkék hurcolászták őket. Aztán a systemstate… az nem csak az AD-t jelenti, hanem rengeteg operációs rendszer szintű adatbázist is. Azzal, hogy visszarántom az AD-t, az összes többi pókhálós cucc ottmarad. Esetleg azt tudom megcsinálni, hogy mielőtt belevágok, csinálok egy másik systemdrive+systemstate mentést, az első autoritatív restore után visszaröffentem a computer account-ot, ezzel megnövelem az UID-jét, majd csinálok egy non-autoritatív restore-t, melyet teljesen felül fog vágni a jó AD és visszakerülnek a rendszerkomponensek is a helyükre.
Ezzel csak két baj van.

  • Egyfelől egyáltalán nem biztos, hogy a két évvel korábbi állapotú DC be fog tudni lépni a tartományba. Meg ugyan nem esküdnék rá, de úgy rémlik, van valami korlát, ameddig felhasználható a mentés.
  • Elég rizikós egy pici tartomány hegesztésekor egy baromi nagy AD-t belengetni, felvállalni az inkonzisztencia kockázatát.
  • Végül azt írja a manuál, hogy egy ilyen restore során egy csomó AD elem by design tönkremegy. Látható is a blue-frame jellegű elvből, hogy mindent visszarak, még akkor is, ha nem kellene, és abba vág majd egy maszkot. Azaz optimáis esetben visszaáll a computer account, de elszállnak a backlist értékek, az FRS replikáció, a RID pool… meg ilyenek.

Jé, ez három…
Ettől függetlenül ezt az utat túl kockázatosnak ítéltem. Ha a DC 2003-as lenne, a mentés pedig 30 napon belüli, akkor esetleg, de így… inkább nem.

Ennyit az egyenes útról. Nézzük a görbéket.

A korábbi disaster recovery cikk sem rossz, de az igazi recept Petrinél található. Mielőtt bármit is csináltunk volna, a helyi rendszergazda a régi Exchange szerver adatbázisait elmentette félre egy másik hardveren, felhúzott egy nagyjából ugyanolyan operációs rendszerű gépet (oprendszer, SP, patch, Windows komponensek – különösen az utóbbi a fontos). Ezután lehúzta a netről a régi szervert, az újnak átírta az IP címét, én a a nevét, közben reseteltem a computer accountot, majd beléptettem az új szervert a tartományba. Áttörtünk. (Mondjuk elsőre elhűlt bennem a vér, mert egy lépésen belül próbáltam átnevezni is meg beléptetni is a gépet, de az éber – akkor már durván 30 órája ébren lévő – helyi rendszergazda szerencsére figyelt… és a második kisérlet már sikerült.)
Innen már simán ment minden, úgy, ahogy Petri bácsi leírta. A végén extra bónuszként az is összejött, hogy egyszerűen visszamásoltam a korábbi adatfájlokat és az IS szó nélkül felmountolta.

Délután fél egy.
Nem sokkal szilveszter után. Mondanom sem kell, hogy a kollégám is, meg én is szabadságon vagyunk.

De így jár, aki az informatikusok bohó szakmáját választja.

ps.
Éppen befejeztem a jegyzőkönyvet – addig kell írni, amíg emlékszem, mi is történt pontosan – amikor csörgött a telefon. A Service Desk szólt, hogy jött egy bejelentés, miszerint megint nem megy a levelezés az ügyfélnél. Sóhaj, enyhe káromkodás, irány vissza. Átnézni a konnektorokat egytől-egyig, tesztlevelek innen-oda, meg vissza… minden működik. Még be sem fejeztem, amikor újból csörgött a telefon. A felhasználó pontosított, azt szerette volna mondani, hogy reggel nem ment a levelezés.
Délután fél öt van.
Köszönjük, az Ön hívása fontos nekünk.

Hülye nevek

Vannak olyanok. Annyira hülye nevek, hogy józan ésszel nem is lehet kitalálni, mi van mögöttük.

Az első példám ahhoz a bizonyos régi szilikáttechnológiai vizsgához kötődik.
Ugyanis megpróbáltam legalább elolvasni az anyagot – de már viszonylag az elején belefutottam egy olyan kifejezésbe, hogy ‘doghouse adagolás’. A porok készülékbe adagolásáról a kézzel – máséval – írott jegyzet több információt nem tartalmazott. Megkerestem pár évfolyamtársamat, de csak annyit tudtam meg, hogy az előadó nem részletezte a dolgot, egyszerűen csak lediktálta.
Én viszont belekapaszkodtam, mint Floki a lábtörlőbe. Próbáltam név alapján kilogikázni. Megkérdeztem idősebbeket, ők sem tudták. Internet, google… ugyan, hol voltak még ezek. Nyomtatott jegyzet? Maximum a holdban. Aztán valószínűleg Buzz Aldrin hozhatott egyet, mert sikerült felkajtatnom egy példányt. Ebből tudtam meg, hogy a roppant tudományosan hangzó szilárdanyag adagolási módszer Jenőt takarja a lapátjával. Komoly.

A másik ilyen kifejezés a ’round robin’ volt. Először tanfolyamon hallottam, még az előző évezredben. Csak néztem nagy gülü szemekkel, de kérdezni nem mertem, mert mindenki más szemmel láthatóan tudta, miről van szó. Vagy csak sokkal értelmesebb képet tudott vágni, mint én. Hiányos angol tudásommal annyit összeraktam, hogy a round az kör, a robin meg vörösbegy… de ebből csak nem állt össze, hogyan lesz ebből redundáns DNS névfeloldás. Azóta persze kupálódtam, megtanultam, hogy az informatikában a ’round robin’ az ‘ad-hoc’ kifejezést takarja, azaz jó magyarosan azt, hogy ‘ahogy esik, úgy puffan’. De hogy ennek mi köze van a ’round robin’ hétköznapi jelentéséhez, mely a ’sokak által aláírt kérdőív’-et jelenti… megint nem tudom.

A harmadik példány még teljesen friss. Exchange 2003 disaster recovery kapcsán olvashatunk olyan módszerről, hogy dial-tone visszaállítás. Első hallásra elsápad tőle még a sokat látott exchange admin is: micsoda… modemen keresztül kell visszaállítani valamit… vagy neadjisten, mobiltelefonról kell sms-ben parancsokat osztogatni? De persze, hogy nem; a névnek megint nincs semmi köze a módszerhez.
Mely nagyjából a következőképpen néz ki.
Legyen egy elszállt Exchange store. Az eredeti mérete – betartva a Microsoft erre vonatkozó ajánlásait – legyen 99.99 GB.
Legyen ez a VIP store.
A CEO legyen teljesen átlagos:

  • 1 perc emailtelenség után bevörösödik a feje,
  • 2 perc után kitör rajta a légiós betegség,
  • 10 perc után sátáni kacagással kezdi kilapátolni a HR ablakán az infomunkások munkakönyveit.

Ezzel szemben a restore rendszer nézzen ki a következőképpen:

  • Az adatbázis visszatöltési ideje másfél óra.
  • Mire megtaláljuk Jenőt, aki tudja, hol vannak a kazetták, megint másfél óra.

Mit lehet ilyenkor csinálni? Igen, dial-tone.

  • Letöröljük az adatbázis maradékait.
  • Felmountoljuk az adatbázist. Nem, nem szedtem be semmilyen tudattágító szert… tényleg felmountoljuk a semmit. Az Exchange2003 ilyenkor lesz olyan kedves, hogy létrehoz egy tök üres store-t, azokkal az adatbázis nevekkel, melyek a store tulajdonságlapján szerepelnek.
  • Lehet telefonálni a vezérnek, hogy működik a levelezés. Igaz, még nem mindenki éri el a régi leveleit, de a visszatöltés folyamatban van. Lehet levelet írni, kapni. A vezér meg fog nyugodni. Látja, hogy az emberek dolgoznak – és azt a betyár mindenit, tudnak a fiúk, milyen hamar működőképessé tették a rendszert!
  • Elindítjuk a visszatöltést a recovery storage group-ba.
  • Ha visszajöttek az adatok, ráküldünk egy összefésülést és hipp-hopp, vissza fognak kerülni a régi levelek a postafiókokba. Hátradőlünk és elégedett mosollyal kiélvezzük… azt a pár percet, amíg a munkaviszonyunk még tart. Ugyanis elég hamar rá fognak jönni kedvenc VIP felhasználóink, hogy nem működnek a szabályaik. Naná. Mivel eltűnt az összes. Ugyanis a merge csak a postafiókok tartalmát másolja, a metaadatokat, szabályokat nem. Az üres adatbázis meg egész konkrétan megszámolható szabályt tartalmazott.
  • Probléma szál sem, a nyúl már a cilinderben van – csak tudni kell, hogyan húzzuk elő. Miután visszajött az eredeti store a recovery storage group-ba, lemountoljuk. Hasonlóképpen lecsatoljuk a VIP store-t is, majd lemountolt állapotban kicseréljük a kettőt – értelemszerűen mindegyiket a megfelelő névre átnevezve.
  • És most már jöhet felcsatolás után a merge – hogy megkapják az ideges fiúk azokat a leveleket is, melyek a visszaállítás ideje alatt keletkeztek.

Jó, mi? De hogy miért dial-tone? A fene tudja.

Részletesebb írás a módszerről Jim McBee blogján.

Kész katasztrófa

Tegnap egész nap BRS teszten voltam. Ez gyk. katasztrófa utáni visszaállítás teszt, időre. Kimegy egy talicska informatikus egy isten háta mögötti telephelyre(1) és megpróbálja lemezekről, szalagokról visszaállítani az éles rendszert. Izgalmas foglalkozás.
Először is megkérnék mindenkit, hogy az elkövetkező napokban finoman, nőiesen beszéljen velem, mert káromkodásból egy hónapra fel lettem töltve. Köszönöm.
Az én feladatom egy kulcsfontosságú Exchange szerver visszaállitása volt. Bármennyire szűk is ilyenkor az idő, szoktunk azért kísérletezni is. Most például kipróbáltuk, mennyire járható a /disasterrecovery kapcsolós visszaállítás, élesben. (Annak ellenére játszottunk vele, hogy van teljes mentésünk az Exchange szerverről.)
Na szóval, nyers szerver felugrott, particiók/könyvtárak beállítva, régi gép eltávolítva a tartományból, új gép beléptetve, jöhet a szerver telepítés. Next-next-nekemnepofázz-finish,… hűdegyors volt ez a telepítés. Nem is rakott fel semmit, csak egy dll-t. Újabb próba, most már le is nyitogatva a menüpontokat,… hát, azt mondja, hogy a prerekvizitek nem stimmelnek. És tényleg, teljesen kiment a fejemből, hogy az Asp.net és a Pop3 szervízek telepités után manuálba kerülnek. Elindítottam őket, de továbbra is hibaüzi jött, amikor ki akartam választani a kollaborációs komponenst. Jó, akkor szedjük le ezt az elb… izé, nyomorult telepítést. Nem jött le. Még a szerver csodálkozott a legjobban; azt mondta, hogy némá, milyen vicces, váratlanul nem tudom leszedni ezt a komponenst.
Jó. Újratelepítés. Sittysutty megvolt. Hoznám létre az adatbázisok könyvtárait, amikor látom, hogy teljesen össze vannak borzolva a partíciók. Visszanevezés közben jött a hidegzuhany: az E partíciót nem lehet átnevezni, mert az lett a system. Miaf? Ez még akkor is durva, ha tudjuk, hogy a system partíció az, amelyikről bootol a rendszer, a boot partíció pedig az, amelyiken a system van. És tényleg, az E particion ott figyelt a boot.ini. Hajjaj. Újratelepítés, de most még a szöveges setupnál töröltem mind a nyolc partíciót – így nem tudott hibázni a kedves. Ez a telepítés már teljesen olajozottan ment, öröm volt nézni. Nem volt egy felesleges mozdulatom sem. Illetve volt – egy beintés, amikor megint nem volt hajlandó települni az Exchange. Nagyítóval néztem át a prerekvizit listát, de minden klappolt, az utolsó szögig. Lassan már eljött az ideje abbahagyni a kísérletezést, de szerencsére a fájlszerver visszatöltés lefoglalta a szalagos egységet, tehát próbálkozhattam még egyszer. És ismét rámmosolygott a google power, egy link eréjéig.
Érdemes idézni:

I called Microsoft Product Support and their solution was to uninstall 2003 Server SP1, install Exchange, install Exchange SP1 then install 2003 Server SP1. This sounds far too shaky a solution for me and on my front-end servers I installed 2003 Server slipstreamed with SP1, so, since I’m the position to do it, I’m just reinstalling the servers from scratch without SP1 until I have Exchange installed.

Nos, erre nem számítottunk; nem volt nálunk külön Windows2003 szerver telepítő cédé, külön felrakható SP1-gyel. Odamentem a konzolhoz és megtippeltettem a kollégával, hogy vajon mit fogok most csinálni. Fogalmam sincs, honnan találta ki elsőre, hogy szervert fogok újratelepíteni. Amíg a bitek tepertek a vasra, nekiálltam leszedni az Internetről az Sp1-et. Aki netán elfelejtette volna: ez a dög 330 MB. Nem kicsit bonyolította a dolgot, hogy idén újítottunk: nem vittünk laptopot, desktopot; ehelyett az ügyfél unixosaitól kaptunk egy-egy Kanotix Linux live distro cédét. Erről tetszőleges vasat be tudtunk bootolni – volt egy csomó, egymásrahajigálva a sarokban – és rdesktop-pal már csűrtűnk is fel a szerverekre. Töredelmesen beismerem, az ikszre végződő nevű rendszerekben nem vagyok nagy spíler, így okozott némi nehézséget, az Sp1 terelgetése. Windowsban azt csináltam volna egy vinyó nélküli gépnél, hogy bemeppeltem volna K: meghajtóként a szerver valamelyik megosztását és arra töltöttem volna le böngészőből a stuffot. Ez itt nem jött össze. SMB-n tudtam ugyan kapcsolódni, de letöltéskor nem tudtam megadni ezt a kapcsolatot. Végül leszedtem a csomagot ramdiszkre (hálistennek volt bőven), onnan krusader-rel ment tovább a szerverre. (Sorry, MC-vel nem sikerült.) Mindenesetre, amíg a memóriába tőtikézte lefelé a fájlt, addig csak lábujjhegyen mertem közlekedni a szobában.
Közben felment a Windows2003 szerver is, Sp1 nélkül. Ránézésre egy csomó rendszerkomponenst nem ismert fel, driverek meg nem voltak, de úgy döntöttem, nem is kellenek. Ha száguldozni akarok egy autóval, akkor nincs szükségem karosszériára. Ugyan már kilométerekre kerültünk attól az elvtől, hogy a visszaállítandó rendszerhez minél hasonlóbbat állítsunk össze – de amikor a hasonlóságra törekedtünk, az nem jött be. Na, mindegy, a kasztni nélküli cucc beröffent. Ment rá az új install. És nem volt inkompatibilitásra utaló hibaüzenet az Exchange setup indításakor! Elégedett mosoly… de nem. Megjött ugyanaz a nyomoronc 0xC007003A(58) hiba.
Újabb varázslások következtek. De tényleg. A mosoly egyre görcsösebb lett az arcomon. Holnap ITIL vizsga. Közben nemhogy a mai tanulásnak, de a mai lefekvésnek is egyre biztosabban lőttek.(2)
Átnéztem a DNS-t és ott virított benne egy hasonló nevű gép. Ki a lilafaszom tette ezt bele? Nyess. De ettől sem javult meg semmi. Oké. Netdiag. Nagy büdös Kerberos hiba. WTF?! Aszongya nem tudja autentikálni a gépet – de névként a hasonló nevű hostot nevezte meg. Mivan? Valami derengeni kezdett, rátekertem a gépnév rovatra. Basszus. Az eredeti gép nevében szerepelt egy ‘0′ karakter. A nagy kapkodásban megszokásból magyar kiosztásúként használtam egy pillanatra a konzolbillentyűzetet, és nulla helyett a felsőfütyi karaktert tettem be. Az oprencer meg volt annyira intelligens, hogy sem ezt a karaktert, sem az utána következőket nem vette figyelembe. Esetleg figyelmeztetni? Ugyan már. A figyelmeztető csapat az összes aktivitását kiélte akkor, amikor a nem használatos desktop ikonokról volt szó – másra már nem maradt lendület.
Gép kilép/belép, közben átnevez, AD reset. De ettől sem jutottunk előre. Jobb híján rászálltam a Kerberos hibaüzenetre, de semmire sem jutottam vele. Pontosabban annyira, hogy csaltam és megkérdeztem az éles rendszeren dolgozó kollégát telefonon, hogy nézze már meg, az éles szerveren – mely játszásiból most ugye le volt bombázva – mit mond a netdiag. És azon is ott volt a Kerberos hiba.
Tehát ez rossz nyom.
Itt érkeztünk el egy döntési ponthoz. A felkészülési dokumentációk egyik része azt írta, hogy az Exchange /disasterrecovery előtt töltsünk vissza system state mentést. Másik része meg meg sem említette ezt a lépést. Nekem ez utóbbi tűnt logikusnak, hiszen arról szól a történet, hogy _csak_ adatmentés van – az Exchange paraméterek majd az AD-ból fognak visszajönni.
Ötlet híján csapást váltottunk: jöjjön az a system state. De majd csak másnap reggel.
Új nap, új remények. De hamar kiderült, hogy a világegyetemben minden változik, csak a szívás állandó. Akkora volt a hardver különbség a két gép között, hogy képtelenség volt rá visszatölteni a system state mentést.
Ekkor járt le az időm. Visszatértünk a jól bevált Exchange visszaállítási módszerre, hanyagolva az új utakat.
Kár érte, mert reméltem, hogy ennél a visszaállítási módszernél meg tudjuk kerülni az adatbázisonkénti hét órás konzisztencia ellenőrzést.

(1) Csak úgy megjegyzem, hogy ez egy nagyon nagy nevű cég direkt erre a célra felingerelt telephelyén zajlott. Nem csak mi használjuk ezt a szájtot, az ügyfelünkön kívül sokan mások is igénybe szokták venni. Pontosan tudom, hogy kik, ugyanis a nagynevű cég emberei csesztek bezárni a dokumentációs szekrényt. Pusztán unaloműzőként lehetőségem volt áttanulmányozni néhány nagy magyar cég informatikai rendszereinek a leírását.

(2) Yes; hajnal kettő lett belőle.

A lehetetlenre egy kicsit várni kell

Úgy kezdődött, hogy Ügyfél egyik középvezetője nem tudta összeszinkronizálni Sony-Ericsson kütyüjét az Exchange szerverrel. (A szinkronizáció nem közvetlen, van egy erre a célra felingerelt Onebridge szerver a hálózaton. Ezt mi üzemeltetjük, de nem mi támogatjuk.)
A hibát kolléga bejelentette az alkalmazás támogatójának, akitől azt a választ kapta, hogy mentsük ki a postafiók tartalmát pst-be, töröljük a mailboxot, majd hozzuk újra létre – és ettől meg fog javulni a szinkronizáció. Sajnos a kolléga elhitte. Megkérte a középvezetőt, hogy másoljon ki mindent pst-be, majd amikor az jelezte, hogy oké, akkor törölt, purgált és újralétrehozott. A szinkronizáció természetesen nem javult meg, de ezzel a szállal a továbbiakban nem foglalkozunk.
A középvezető visszamásolta a cuccait – és reklamált, hogy valami nem stimmel, nem találja a kontaktjait. Egyeztetés után kiderült, nem tudta, hogy a Contact foldert is ki kellett volna másolnia. Legyünk már olyan kedvesek és állítsuk vissza az eredeti állapotot.
Ekkor jöttem be a képbe én és egyből elszürkült a tekintetem. Mentések természetesen vannak, de ez a purgált, majd újra létrehozott postafiók semmi jót nem ígért. A dumpsteren keresztüli visszaállítás természetesen szóba sem jöhetett.
Elsőkörben be kellett izzítani a Recovery Storage Group-ot az Exchange szerveren, felvenni a piszkálandó adatbázist. Gyors ellenőrzés a registryben: a HKLM\System\CCS\Services\MsexchangeIS\ParametersSystem kulcs alatt a Recovery SGOverride értéke nehogy 1 legyen, mert akkor a visszatöltés fejbevágja az eredeti adatbázist. Nyilván még helyet is kellett keresni a logoknak és az adatbázisnak, ennek megfelelően korrigálni az adatbázis adatlapját – és be kellett állítani, hogy az mentésből felülírható legyen.
Ennyit az előkészületekről, jöhetett a Tivoli Exchange kliens. Itt ért az első kellemetlen meglepetés: az aktív mentések sorából pont kicsúszott az a mentés, amelyre szükségem lett volna, az összes mentések listájának felolvasása meg jó másfél órába telt. Bejelöltem, hogy melyiket szeretném visszaállítani, aztán hagy szóljon.
Jó egy óra után, 99% körül elszállt a visszaállítás, miközben a szerver felsikított, hogy betelt a C:\. Amikor ennek a partíciónak a közelébe sem lett volna szabad mennie. Rövid bogarászás után megtaláltam, hogy a saját profilom verte ki a biztosítékot, simán felhízott 2,5 gigára. További bogarászás után azt is megtaláltam, hogy a Tivoli kliensben üres a temporary directory beállítás; a kis okos tehát a profilomba szemetelt. Kiganéztam, megadtam neki egy másik lemezt és újrakezdtem. Másfél óra a listáig, egy óra a visszatöltés.
Exchange sp1 óta a Recovery Storage Groupból elérhető a Mail Merge funkció (egyfajta lebutított Exmerge), ez nekem tökéletesen megfelelt. Kiválasztottam a másolás alfolderbe opciót és elmentem haza (1.5 GB; 20000 item).
Másnap leellenőriztem a kontaktokat: a folder üres volt. Miaszösz? Dismount, törlés, kezdjük újra az egészet. A másfél órás listavisszatöltés után megvizsgáltam a Tivoli klienst és azt találtam, hogy alapban be van kattintva az automatikus kijelölés opció. Tehát amikor kijelöltem a korábbi adatbázist, akkor ő a biztonság kedvéért végigjelölte a következő teljes mentésig a logokat is és persze a visszatöltés után rá is játszotta azokat – azaz visszakaptam egy olyan állapotot, amikor már az új postafiók volt az adatbázisban.
Kíváncsiságból kipróbáltam, mi történik, ha nem jelölök ki log visszatöltést és nem kérek rájátszást. Visszatöltés előtt figyelmeztetett, hogy lehet, hogy nem fogom tudni felmountolni az adatbázist. És milyen igaza volt: tényleg nem tudtam. Törlés, kezdjük előlről. Bejelöltem a megfelelő adatbázist, kikapcsoltam az automatikus kijelölést, bejelöltem az aznapi logokat (csak azokat!), kértem a rájátszást és beállítottam a temp directoryt.
Nna, így már sikerült.Ezt abból is észre lehetett venni, hogy ekkor már nem működött a Mail Merge. De még az Exmerge sem. Egyik sem találta a produkciós adatbázisban a recovery adatbázisbeli postafiók párját. Nyilván nem, mert ugye törölve lett, purgálva lett, sóval behintve lett. A felhasználóhoz rendelt postafiók már vadiúj volt, akkor is, ha minden látható név ugyanaz volt rajta. Nem kicsit frusztráló, hogy a kezelői felületen ott látom a mailboxot, de képtelenség kimenteni a tartalmát, mert minden eszköz merge műveletre van tervezve; ahhoz meg kell a régi postafiók. Pst-be másolás? Felejtsd el.
Iránya jó öreg google haver. Első körben itt van egy link; azt írják, hogy milyen állapotai vannak egy postafióknak és milyen állapotokban van esély visszaállításra. Purgálás után pl. semmi. Aztán a cikk végén felcsillantottak egy lehetőséget, megadtak egy másik cikket. Ennek már a címe is izgalmas volt, azt mondta: “Hogyan állítsunk vissza purgált postafiókot“. Átolvastam. Fejvakarás. Átolvastam még egyszer. Kezdtem érteni. Zseniális! Hogyan hekkeljük meg a Recovery Storage Group-ot? Először töltsük vissza az adatbázist az RSG-be, ahogyan kell, mountoljuk fel, majd azonnal le. Fontos, hogy ez simán történjen, érdemes a státuszt rögtön leellenőrizni az ’eseutil /mh’ paranccsal.
És itt jön a trükk: nevezzük át az adatbázis fájlokat, pakoljuk át máshová, csináljunk neki produkciós storage groupot, abba csináljunk neki adatbázist és mountoljuk fel.
Nem, nem kell a szívünkhöz kapni, nem lesz innentől kezdve mindenkinek két postaládája – ugyanis amikor felmountoltuk az adatbázist a Recovery Storage Groupban, akkor automatikusan minden postafiók lecsatolt állapotba került és ez a dismount során igy is maradt. (Mondjuk a zabszemteszten nem mentem volna át, amikor csatlakoztattam; mondtam már, hogy ez a VIP adatbázis volt?)
Most előreszaladtam egy kicsit, mert közben azért bejött a képbe a Nagy Harci Fasz.
Amikor ugyanis megértettem, hogy mit kell csinálnom, nekiálltam dismountolni az RSG adatbázist. Nem sikerült, a System Management konzol befagyott. Vártam másfél órát, majd kilőttem a Task Managerből. Kolléga összedugta fejét az ügyfél kapcsolattartójával, este hétkor engedélyezték a szerver újraindítását. Fél nyolckor jött a telefon, hogy gáz van, az Exchange szolgáltatások nem indultak újra. Fél nyolc után öt perccel jött az újabb telefon, hogy nagyobb gáz van, tkp. a szerver nem is állt le, csak úgy lebeg élet és halál között. Oké, irány a Dataplex. Érdekes látvány fogadott: a szerver működött, csak éppen a távoli elérést biztosító szolgáltatásai haltak el. Az egész leállási folyamat az Information Store leállására várt, az viszont beragadt ’stopping’ állapotba. Egyébként a szerver köszönte szépen, jól volt. Az eseménynaplót percenként szemetelte tele a System Attendant, hogy nem tud leállni, mert az Exchange szerver nem elérhető. Elég hülye kifogás. Megnéztem a Filemon cuccal, hogy egyáltalán mi történik: semmi különös, a store.exe egyfolytában a temp könyvtárat csesztette. Az adatbázisok viszont ott vigyorogtak lezáratlanul. Ezután dehogyis mertem kigyilkolni az IS-t. Ahogy a szakirodalom is mondja, ilyenkor kell felhívni a a Microsoft Premier Support-ot: hagy harapjanak ők is egy jó nagyot a felelősségből.

Tudom, minden rendszermérnök életében eljön az a pillanat, amikor éles szituációban be kell jelenteni telefonon egy hibát az amerikai PSS-nek. Ez, úgymond, egyfajta evolúciós lépcső. De nem hiszem, hogy mindenki annyit szerencsétlenkedik vele, mint amennyit én.
Ott kezdődött, hogy a szerverszobában 40-50 szerver duruzsolt a fülembe. Ki lehetett ugyan menni a folyosóra, de ott meg nagyon figyelni kellett a padlólapokat, mert tény, hogy bizonyos lapoknál elmegy a térerő. És persze a teljes kommunikáció egy pici mobillal történt.
Nos,én voltam annyira zöldfülű, hogy már rögtön az első hapinak nekiálltam magyarázni a technikai problémát, bőven ecsetelve az előzményeket. Kicsit ugyanis ideges voltam, mivel ez az ügyfél fő produkciós levelezőszervere volt, a kapcsolattartó pedig elnézte a dolgot, a cég legfontosabb projektjében ma kellett volna külföldre küldeni bizonyos záródokumentumokat.
(Ugyan javasoltam nekik, hogy küldjék el privát postafiókból webes felületen, de azt kaptam, hogy na ne már, verziókövetés van, előzmények vannak, subject kódok vannak, nekik válaszolni kell az előző levélre. Fóti Marci örökbecsűje jutott eszembe: ‘Az informatika még nem érte el azt a biztonsági szintet, hogy rábízzuk az életünket – de mi rábíztuk.‘)
Szóval egyáltalán nem lepődtem volna meg, ha megtudom, hogy az ügyfél verőemberei már melegítenek valahol.
Ehhez képest gyönyörűen elbeszéltünk egymás mellett: én állandóan a problémámat hajtogattam, a hapi meg állandóan azonosítgatni akart: Mi a cégem azonosítókódja? Mi az én azonosítókódom? Mit tudom én! – sikítoztam.
Végül javasoltam, hogy hagyjuk a fenébe az egészet, van hozzáférésem az Online Premier Support oldalhoz, majd bejelentem írásban. (Ott már valamikor hozzá lett rendelve a .net jelszómhoz az egész miskulancia.) Hát, az ötlet jó volt, de valamiért nem akart összejönni a belépés.
Végső kétségbeesésemben felhívtam a TAM-ot. Kolléga szerint nem koránfekvős fajta; Isten tartsa meg a szokását, ébren volt most is. Kikereste nekem a szükséges kódokat és elmagyarázta, hogy az első ember technikailag zokni, annak csak az a dolga, hogy beazonosítson. És azt is javasolta, hogy ha olyan helyen vagyok, ahonnan rosszul hallom a szöveget, kérjek Translation Service-t. Ingyenes és minden nyelvre meg van szervezve. Remek. Megkértem, hogy küldje el az adatokat az otthoni címemre, majd webfelületről leszedem. 10 percig vártam, nem jött semmi. Egy kicsit téptem a hajamat – tényleg csak egy kicsit, aztán valahogy összehegesztettem a céges OWA elérést – lassú is volt, bizonytalan is, de a miénk… és működött. Oda is megkértem a levelet és megjött.
(Másnap esett le: otthonról olyan gyorsan jöttem el, hogy bejelentkezve maradtam a gépemnél – és persze, az Outlook pop3-mal mindig lekapta a levelet. Elmehettem a búsba a webfelülettel.)
Mindegy, megtanultam a leckét: company id nélkül ma már sehová se megyek; itt fityeg a PDÁ-n.
Innentől kezdve már csak egy óra kellett, hogy eljussak a technikai emberhez. Mondjuk az idő nagy részét az tette ki, hogy vártuk a Translation Service-t, aki végül ezen a napon nem jelent meg.
A többi már viszonylag simán ment: elmondtam a problémát, a hapi elkérte az applikációs logot (16MB – bizonytalan OWÁ-n keresztül…), majd némi fejvakarás után közölte, hogy nincs más hátra, gyilkoljam ki a store.exe-t. Eddigis hülyén nézhettem ki – gondolom, a dataplexes fiúk jót szórakozhattak a monitorszobában, hogy percenként rohangászok ki a folyosóra (sorry, I’ll go out… please repeat it…), utána meg vissza a gépterembe, minden alkalommal beriasztva őket… de ezt a lépést már nem voltam hajlandó pusztán szóbeli utasításra meglépni. Megkértem a fazont, hogy írja le emailben, mert nem hallom jól, amit mond. Leírta, kigyilkoltam, újraindítottam és felállt minden. Mármint szolgáltatás. Mondjuk az alatt az öt perc alatt, amíg az IS húzta a csíkot, öregedtem egy kicsit: 8db adatbázis figyelt a gépen, összesen olyan 600 GB méretben. Ha az IS nem indult volna el egyből, akkor életem végéig mentésből kellett volna adatokat töltögetnem.
De elindult. Már csak azt kellett kinyomozni, mi a lószar volt ez? Délután is, amikor nekem beragadt a System Manager és este is, amikor a leállítás ragadt be, a víruskergető jegyzett be gyanús hibaüzeneteket a logba.

Ez egy hálás toposz, exchange adminok előszeretettel szeretnek mindent ráfogni a víruskergetőre – és nem is ok nélkül.
Csak a rend kedvéért, hogy mi mindent tud okozni egy rosszul beállított víruskereső:
-A fájl szintű víruskereső megfogja az exchange adatbázist. Information Store nem fér hozzá, kardjába dől.
-A fájl szintű víruskereső karanténba dobja a tranzakciós log egy-egy fájlját. Information Store kardjába dől, a rendszergazda szintén.
-Ilyenről is olvastam: ha nincs elzárva a fájl szintű kereső elől az exchange szintű kereső temporary könyvtára, akkor a fájlszintű kereső ráharap az ideiglenes állományokra és lefagyasztja az exchange víruskergetőt. Még jó, hogy egy cégnél dolgoznak a fiúk. Bár a cikkben büszkén írták, hogy az ő termékük egy ilyen crash után képes meggyógyítani magát, nem kell újratelepíteni.

Nos, lássuk csak, nálam mi történhetett. Visszatöltöttem mentésből az adatbázist,és… hoppá. Nem a szokott helyre töltöttem, mert ott nem volt elég hely – ehelyett egy másik partíción csináltam neki egy könyvtárat. Kitiltottam belőle a fájlszintű víruskergetőt? Bizony nem. Megint hoppá.
Mekkora farok vagy, Joep – mormogtam hajnalban – ekkora potyagólt a te korodban már nem illik kapni.
És jobb későn, mint soha alapon bementem a víruskereső konfig menüjébe, ahol… meglepetten láttam, hogy az aranykezű kolléga korábban az egész partícióról kitiltotta a víruskeresőt. Tehát farok vagyok ugyan, de szerencsére megúsztam, nem én hibáztam.
(Mondjuk ekkor már voltam annyira fáradt, hogy a folyosón nekimentem az ajtónak: valamiért azt hittem, hogy ki fog nyílni magától. Pedig öreg dataplexes vagyok, pontosan tudom, mely ajtókat kell ballal húzni és melyeket jobbal tolni. Komolyan mondom, kész szerencse, hogy az ügyfél nem látja, hogy milyen állapotban hajt végre életveszélyes műtéteket időnként az üzemeltető.)
A magam részéről itt abba is hagytam a nyomozást egy ‘holnap is nap lesz‘ rikkantással.
Úgyis lett. Első lépésben kikapcsoltam a fájlszintű keresőt. Aztán megnéztem, hogy is áll az RSG adatbázis. Az eseutil szerint a státusz: Dirty shutdown. Hát, nem pont ez állt a cikkben. Adatbázis fájlok törlése, logok törlése, Tivoli. Másfélóra várás a listára, az egyetlen lehetséges kombináció összekattogtatása,visszatöltés. Aztán elindítottam egy Filemont, hogy lássam mi is történik mountolás/dismountolás közben. Semmi érdekes. A store.exe gyanúsan sokszor piszkálta a temp könyvtárat, mely nem volt kizárva a fájlszintű ellenőrzés alól. Kizártam. Az exchange szintű kereső ideiglenes könyvtárát is. Meg kiterjesztés alapján is kizártam az Exchange fájlokat, nemcsak könyvtárnév alapján.
Aztán megint net és kiderült, hogy teljesen rossz nyomon jártam: az az applikáció, mely teleszemetelte a logot a lefagyások előtt, az nem a fájlszintű víruskereső, hanem az exchange szintű. Itt dobtam egy négylábas megadást; összeszedtem a bizonyítékokat és elküldtem a feljelentést a gyártó képviselőjének.

Sokkal jobban izgatott, hogy mi lesz a középvezető kontakt listájával. Az újabb visszatöltés, mount/dismount után az RSG adatbázis státusza szépen Clean shutdown lett, tehát kezdődhetett a hekkelés.
Új, produkciós storage group létrehoz, adatbázis definiálódik. Természetesen másik könyvtárban, a biztonság kedvéért átnevezve. Utána adatbázis fizikailag is átmásolódik, átneveződik, nagy levegő, mount. Egyből jött is a hibaüzenet: adatbázis nem található. Kezdő exchange adminokra ilyenkor törhet rá az az érzés, hogy sürgősen keresni kell egy konnektort vizeletürítési céllal. Ne tegyétek. Sokkal praktikusabb odasétálni a pár méterre lévő darts táblához(1), leemelni a nyilakat és önfeledten hajigálni 10-15 percig. Ha esetleg átfúródik a táblán, nem gond, a fal azért megfogja. Ahogy eltelik az idő, az Active Directory csak szétreplikálja az egész hóbelevancot – és már mountolható is az adatbázis. És igen, mindegyik postafiók le volt csatolva. Nyertünk.
A doksi szerint meg kell keresni a diverzáns postafiókot és hozzávágni egy dummy felhasználóhoz. (Melyet természetesen megcsináltunk, miközben az AD replikációt vártuk.) Oké, dobjuk meg egy postafiókkal. (Sánta, van púpod? Nesze!)
Megint hibaüzenet jött: azt mondta, hogy az a legacyExchangeDN, mely ehhez a postafiókhoz tartozik, már másik felhasználóhoz van rendelve. Hja, mindenre mi sem gondolhattunk. Persze, könnyű a doksinak, ott nem feltételezték azt, hogy purgálás után rögtön újra létrehozzák az új postafiókot a régi felhasználóhoz.
Végülis, nem olyan nagy gond ez, a középvezető user adatainál átírtam AdsiEdittel a legacyExhangeDN értéket valami marhaságra, a recovery usernél átírtam a jóra, 10 perc darts és már csak be kellett pöckölni a labdát: a régi postafiókot hozzá tudtam rendelni a recovery userhez, megnyitottam outlookból mind a két postafiókot és átmásoltam azt a szájbanyomott kontakt listát a pacákhoz. Finita.
Persze még hátravolt a takarítás. El akartam tüntetni ezt a hibrid adatbázist, mert valahogy nem vagyok nyugodt, ha ilyenek kóricálnak a szerver körül. (Jártam már úgy, hogy törölt felhasználók valahogy megtalálták az RSG adatbázit és boldogan csatlakoztak hozzá.) Viszont az sem kizárt, hogy a hapi pár nap múlva veszi észre, hogy valami még kell neki. A tiszta munka átmozgatni a postafiókot egy létező adatbázisba, a hibridet meg lecsatolni, letörölni.
Másolás elindult. Az alkotó hátradőlt és várta, hogy besöpörje a hálás telefonhívások özönét. Ehelyett a helyi kolléga telefonált, hogy a középvezető igen zabos, mert fontos levelet vár, de semmilyen levelet nem kap meg; az összes levele valamilyen recovery usernél landol. Hoppá.
Elfelejtettem visszaírni másolás előtt a legacyExchangeDN értéket. Hát… most már meg kell várni a folyamat végét. 1,5 GB, 20000 item, 30 perc darts.
Az indikátor kijelzi a 100%-ot, majd a másolás könnyed sóhajtással befagy. Ez a szerver nem fér a bőrébe. Szerencsére ezen a területen már megszívtam az összes megszívnivalót, tudtam, mit kell tenni.
Hagy idézzek egy korábbi írásomból:

Végülmár csak ketten maradtunk a porondon: a 4.6 GB méretű mailbox és én. Szembenéztünk egymással, a szél ördögszekeret sodort keresztül az úton. Hirtelen mozdulattal rávetődtem a billentyűzetre és megismételtem a másolási parancsot – de most egy másik adatbázisba. Két óra szuttyogás után megint behalt a másolás… Task Manager, kilőni. Most már 3 példányban volt meg a mailbox – és mind a 3 működött. Egyszerre. Ha elvettem az egyiket a felhasználótól, mind felszabadult. Ha visszaakasztottam rá az egyiket, akkor a többit sem lehetett törölni, mert azt mondta, hogy használatban vannak. A helyzet kezdett kínossá válni. Végül kimentegettem az anyagot pst-kbe, lecsatoltam a mailboxot, töröltem a két rosszat, a maradékot visszacsatoltam – és gyönyörűen működött. Nem sokat dobott a kedvemen, hogy közben megtaláltam a helyes megoldást: a behalt mozgatást kilövés után folytatni kell _ugyanabba_ az adatbázisba, amelyikbe elkezdtük. Szószerint azt írták, hogy az Exchange van olyan intelligens, hogy észreveszi a sikertelen másolás darabjait. Usually. Hát… engedtessék meg nekem a kétkedés joga.

Nos, tulajdonképpen szerencsésnek tarthatom magam: lehetőségem volt kipróbálni, hogy milyen brilliáns hibajavító algoritmust tartalmaz a mailbox move folyamat arra az esetre, ha egy postafiók mozgatás 100% elérése után fagyott le. Tippelj.
Az nyert, aki arra voksolt, hogy nemes egyszerűséggel letörli a félbehagyott postafiókot és azt mondja, hogy kezdd újra, Gézám.
De legalább vissza tudtam állítani a legacyExchangeDN értéket. Újabb 10 perc darts és a középvezető megnyugodhatott: ő lett ő és megvolt a kontaktlista. Aztán végül nem töröltem semmit, lecsatoltam a recovery userről a postafiókot és dismountoltam az adatbázist.
Ősi cowboy szólás, hogy csak a dismountolt adatbázis a jó adatbázis.
Most már tényleg hátradőlhettem: megoldottam a lehetetlent, csak egy kicsit várni kellett rá. A kiajánlott (és kifizetett) 4-5 óra helyett 33-at.
Persze igazán nyugodt nem lehetek: kiváncsi vagyok, mikor veszi észre, hogy a Calendar is üres. Ekkor leszek igazán bajban: fogalmam sincs, hogyan lehet egy Calendarnak azt mondani, hogy select all, aztán copy másik mailbox. Hallottam már olyan emberről, aki látott olyan embert, akinek pst-n keresztül már sikerült ilyesmi – de arról is kiderült, hogy más volt.

(1) Ne mondd, hogy nincs. Nem lehetsz ennyire kezdő a szakmában.