Előre szólok, csak az olvassa el akinek van türelme hozzá. Eléggé hosszúra sikeredett. Én részemről sokat tanultam ebből a történetből.

 

Alapvetés:

Van egy kedves felhasználónk akinek kézen-közön eltűnt a mailboxa. Vissza kéne állítani, de..

1. Összesen valami 3 hetes mentés van róla (a köztes 3 hétről nem is beszélünk mert az kategórikusan nincs meg)

2. Az egész dolog nem olyan kritikus, hogy bármi módon hajlandó lennék az éles szervert veszélyeztetni miatta.

3. Sérti az önérzetemet, ha nem tudom megcsinálni.

4. A kollégái mostanában többször hívtak, hogy próbáljam megoldani (az eset mintegy másfél hónapja kezdődött)

 

Előzmények:

Természetesen az Exchange rendszergazdák szokásos bajával küzdök, hogy cég szinten nem lehet kemény limitet beállítani a felhasználóknak a mailbox méretére, a 16GB-os korlát be van vasalva az Exchange 2003 Standard Editionbe (ebben az időpillanatban az SP2 még nem létezett). Annak idején írtam egy scriptet ami hetente egyszer elküldi a felhasználóknak, hogy túllépték a limitet és töröljenek, de sajnos ez egyre inkább hatástalan.

Egy költözés előkészületei zajlottak éppen aminek kapcsán a szóban forgó Exchange szerverre néhány plusz mailboxot át kellett költöztetni és akárhogy számoltam nem volt ehhez elég hely (az Enterprise Edition beszerzése szóba sem jöhetett anyagi okokból).

Ide tartozik még, hogy a helyszűkére való tekintettel levettem a dumpster törlési idejét egy napra, valamint a törölt mailboxok megtartását is egy napra (mint később kiderült ez utóbbi hiba volt).

Ráadásul a gépnek volt némi Exchange adatbázis hibája is egy valamikori hibás rendszerleállítás miatt (az adott cég előző rendszergazdájának műve).

Ezekből következően két feladat várt rám:

1. Adatbázis reszelés

2. A felesleges mailboxok (elment dolgozók) törlése

Miután nem divat tudatni az informatikával, ha valaki kilép (azért, hogy belépett és legyen mindene azonnal természetesen verjük az asztalt, de nem takarítunk magunk után), elég nehéz kideríteni, hogy ki az aki már nincs. Csináltam egy szép hosszú listát arról, hogy ki van a rendszerben és kiadtam az illetékeseknek, hogy mondják meg ki az aki már nem dolgozik itt. Megkaptam a választ a listámra, arra a kérdésemre, hogy a törlésre kijelölt mailboxokat meddig kell még megtartanom, egy határozott "azonnal törlendő" választ kaptam.

 

A történet itt kezdődik:

Megpróbálom időrendben, dátum szerint felidézni az eseményeket, bár a kezdetek már az idő homályába vesznek.

 

Egy szombat reggel

Észreveszem, hogy az egyik Exchange szerver adatbázisában pici hibák vannak. Ezt valamikor reparálni kellene, de mostanában esélytelen. Költözés lesz, stb. Csinálok egy gyors ExMerge exportot a pst-kről, majd ha lesz rá lehetőség a költözés után, akkor mehet a repair.

Ezt az ExMerge-es dolgot megismétlem a következő hetekben néhányszor, hogy ne legyen gáz.

 

Egy későbbi szombat reggel.

Mennyivel jobb is Exchange-t reszelni, mint az ágyban fetrengeni még néhány órát  

ExMerge Mailbox exporttal indítunk.

Valamikor délelőtt Exchange Store leállít.

Repair.

Elmegyek ebédelni.

Kapok egy hisztis telefont az egyik kollégától, hogy nem tud dolgozni (meg kell jegyeznem, hogy a szombat nem munkanap nálunk). Megegyezünk, hogy valamikor délutánra lesz szerver.

Minden sikerül, béke van.

Kitörlöm a megegyezett felhasználókat. (ezek ugye hétfőre nyomtalanul eltűnnek a már említett egy napos beállítások miatt)

 

Következő hétfő este

Este csinálok még egy ExMerge-es backupot, majd a meglévő korábbi hasonló mentés fájljait felülírom az újonnan keletkezettekkel. Na itt csúszik el a dolog. Volt egy felhasználó akinek nem kellett volna megszüntetni a hozzáférését (láthatóan pontos listát csináltak nekem). Ezt a felhasználót a kedves kollégám ennek a hétfőnek a reggelén újra létrehozta. Én pedig este felülírtam az üres pst fájlal a telit (ez ugye nem fordult elő a megszüntetett és újra létre nem hozott felhasználókkal, hiszen nekik ezen az estén nem keletkezett pst fájljuk)

 

Néhány nappal később

Kiderül, hogy gáz van. El kezdek gondolkozni, hogy mit lehet tenni. Miután a mentésünk rotációs jelleggel diszkre zajlik, már nem volt meg olyan mentés amiben még meg lett volna a keresett adat. Pontosabban valamikor szeptember végén lecseréletem a mentésre szolgáló vasat és van 2db 250GB-os vinyóm amin rajta lehet valami korábbi mentés. Rajta is volt. Leszedtem a fájlokat. Ezt ugyanakkor az éles rendszerre még Recovery Storage Groupba sem merem visszatölteni.

 

2005.11.14

Végre nekiállok a visszatöltésnek. Telepítek egy virtuális gépet, exchange rá, próbáljuk visszatölteni.

1. Sima restore. Nem ment. 9635-ös hibát kapok rá, merthogy nem találja az AD-ben az azonos GUID-ű Storage Groupot.
2. Recovery Storage Group létrehoz. Override RS bekapcsol. A hiba változatlan
3. ADSI Edit, storage group létrehoz, GUID beír, nem megy, közli, hogy az attributum tulajdonosa a rendszer
4. ADSI Edit elindít rendszer joggal (AT parancs), változatlanul nem engedi a GUID-ot módosítani.

Feldobom az ügyet a levlistára, keresgélek a guglin semmi értelmes válasz.

Egyenlőre tanácstalan vagyok.

Kapok egy telefont a törölt mailbox tulajdonosának egy kolléganőjétől, hogy nagyon kellenének az adatok (ez eddig nem volt ennyire fontos, mindegy). Mondom neki, hogy dolgozom rajta de nem sok esélyt látok.

 

2005.11.16

A Microsoft termékbejelentésén vagyok amikor jön egy telefon a mailboxtulajdonos főnökétől, hogy mi a helyzet. Neki is elmondom, hogy megteszek mindent, de eléggé esélytelen az ügy.

 

Néhány napig nem volt időm foglalkozni vele, majd ...

 

2005.11.21.

Megint volt egy kis időm nekikezdeni a dolognak. Feltelepítettem újra a virtuális gépet. Egy cikkben a neten találtam valami halvány utalást arra, hogy a gép nevének, stb. azonosnak kell lennie a restore-hoz. Nosza, csináltam egy olyan környezetet amiben a domain, a gép neve, az Exchange org neve, az Administrative group neve (ez utóbbi trükkös, mert az első admin group nem nevezhető el egyszerűen. System manager feltelepít az Exchange előtt, Administratice Group létrehoz, majd Exchange telepít) azonos az eredetivel.

Bentről magammal hoztam haza az adatbázis backupot

Nekiáltam visszatölteni az adatbázist (Recovery Storage Group nélkül, registry buhera nélkül) és láss csodát elkezdte visszarakni. Gőzerővel visszatöltöttem az adatbázist.

Miután be voltam sózva, SSH-n elkezdtem letölteni bentről a log backupok egy részét.

 

2005.11.22.

Innen már órára bontva megy a történet

05:51 - Felkeltem.

Reggelre lejött bentről még néhány log backup elkezdem visszatölteni őket. Sikerül is azokat amik itt vannak márt, a többit majd bent a munkahelyemen.

08:37 - Beértem

Folytattam a logok visszatöltését.

10:47

Elérek az utolsó backup set-ig, erre közli, hogy sérült, on media catalog kikapcsol, backup set újrakatalogizál, visszatölt, a visszatöltés végénél közli, hogy kéri a set második felét, lelövöm, elkezdi visszajátszani a logokat és ...

elszáll.

Kapok egy 412-es ESE hibát melyben közli, hogy nem tud olvasni egy log fájlt. Naná, a sérült mentés utolsó fájlját.

Letörlöm a hibás fájlt, visszatöltöm az utolsó előtti mentést újra. Elkezdi visszajátszani a logot. Megint elszáll.

Most egy 904-es ESE Backup hiba. Közli, hogy nem talál egy fájlt. Persze azt amit letöröltem.

Na mindegy, ha idáig egyszer már eljutottam, nem adom fel könnyen (nincs sok kedvem újrakezdeni). Fel akarom mountolni a Store-t. 619-es ESE hiba, nem fejezte be a restore-t. Irány a KB. 810099 -es cikk. Kell egy eseutil /cc annak a könyvtárnak a nevével ahol a restore.env található.

Elindítom az eseutilt, ugyanúgy közli, hogy nem talál egy logfájlt és kiírja, hogy E000296b.log -tól E0002F51.log -ig akarta visszatölteni. Hümm. Feltételezem, hogy ezeket az adatokat a restore.env-ből vette. Nekiugrottam ez utóbbinak egy hexeditorral, megkerestem a kérdéses bejegyzést, kijavítottam a 2F51 hex-át 2F50 hex-ára, mert ugye ezt az utolsó fájlt töröltem.

11:34

Eseutil /cc másodszor. Most elindul... várunk. Nézem az Event Logot. Átlag 3 percenként dolgoz fel egy új logfájlt. Kiszámoltam a cirka 10 gigányi logot mintegy 5 nap alatt fogja feldolgozni. Vicces lesz...

15:30

Elindulok a tanfolyam irányába (Év eleje óta egy Informatikai Biztonsági Szakértő című tanfolyamra járok. A mai az utolsó alkalom, majd valamikor decemberben vizsga). Természetesen az eseutil még nem végzett, de gyorsabban halad mint számítottam.

19:30 körül

Visszaérek a tanfolyamról (mint sokszor most sem bírtam végigülni)

Kiderül, hogy az eseutil közben elszállt egy -567 -es hibával. Semmi okosat sem találok rás a KB-ben, egyszerűen csak feltételezem, hogy rászaladt valami hibára az adatbázisban (elvégre az adatbázis mentés amiből dolgozom egy hibás darabról készült). Ez most nem izgat. Sikerült visszatöltenie a logok jó felét.

19:42

Teszek még egy ványatag kísérletet arra, hogy visszajátszam a hibás log utániakat (Hex editor a restore.env-en, eseutil /cc) de ez természetesen nem sikerül.

19:50

Megpróbálom elindítani az adatbázst, természetesen nem megy. Közli, hogy nem volt hard recovery.

19:55

Adatbázis reparálás eseutil /p elindul

20:30 körül

Lelövöm a virtuális gépet, hazamegyek

20:55

Hazaérek, virtuális gép elindít eseutil folytatja (mekkora találmány ez a save state dolog, nem kell kivárni a dolgokat, bárhol bármikor megszakítható és folytatható). Ma már nem foglalkozom vele, majd holnap.

 

2005.11.23

 

02:10 - Felébredtem

Megint azon hülye napok egyike amikor nem tudom rendesen kialudni magam.

Folytassuk az Exchange reszelést. Ránézek a gépre: eseutil befejezte. Indítsunk adatbázist. Nem megy 1088-as hiba az Event Logban. Nem lepődök meg, erre számítottam. Tegnap este még kinyomtattam egy rakás KB cikket és köztük a 324606 -ost ami erről szól. Letöltöm a LegacyDN.exe -t játszom vele egy kicsit. A doksi zavaros. Sikerül gyártanom egy logot amiből kiderül, hogy mely pontokon kell megváltoztatnom a LegacyDN értékét, de megcsinálnom nem sikerül vele. Nem baj. ADSI Edit elővesz, LegacyDN-ek átír (7 helyen).

02:59

Exchnage szolgáltatások újraindítása. Nem indítja el a Public store-t (erre számítottam, mert ugye most a Public Store LegacyDN értéke rossz), de nélküle megleszek. Elindul a Mailbox Store. Hurrá, célegyenes!

Látom a mailbox-okat a System Managerben.

03:12

ExMerge elindít, nem látja a mailboxokat. Ok, ez rendben van. A mailboxok alapvetően disconnected állapotban vannak, csak én ezt nem látom a System Managerben így nem tudom felhasználóhoz csatolni (a Reconnect Mailbox szürke). Ha megvárnám az Exchange rendes napi nagytakarítását akkor látnám az eredményt, de nem akarok erre várni. Irány a KB. A 261142 -es cikkből kiderül, hogy a Run CleanUp Agent az én barátom. Létrehozom a felhasználót, hozzácsatolom a mailboxot.

03:24

ExMerge újra, elkészül a pst. Végeztünk.

Írom a cikket. Kiszedtem minden adatot a virtuális gépből ami kellett.

04:50

Ünnepélyes shutdown. Virtuális gép megy a levesbe.

 

Remélem nem túl zavaros a dolog. Darabokban írtam az elmúlt másfél napban.