Feltehetően mindenki hallott már az Exchange adminok életét megkeserítő a remek stub alapú archiválási technikáról. Arról van szó, hogy egy külső gyártó terméke (pl Symantec Enterprise Vault) MAPI felületen végigszkenneli az Exchange kijelölt adatbázisait, majd a beállított feltételeknek eleget tevő levelekből (méret, időpont) a tartalmat kiveszi, átrakja a saját adatbázisába, az eredeti helyen pedig csak egy pointert hagy ott, mely az átmásolt tartalomra mutat.
Az elv még nem is lenne rossz – bár látjuk, hogy összességében helyet nem nyertünk, viszont az Exchange adatbáziskezelő műveletei felgyorsultak. Persze ennek ára is van, a csonkolt levelek elérése lassabb, egy disaster utáni recovery kész horror (pedig eleve sem egy leányálom), plusz adminisztráció, na meg több zsák pénz.
Most ne menjünk bele, hogy ennek van-e egyáltalán létjogosultsága Exchange 2010 alatt (itt ugye az adatbázisok maximális mérete a tera tartományban mozog). Tételezzük fel, hogy már van ilyen rendszerünk, megörököltük a korábbi Exchange verziónkkal. Jelen cikkben csak egy apróságra hívnám fel a figyelmet: hogyan lehet egy pitiáner tervezési hibával hülyét csinálni magunkból.
De előbb számoljunk. Exchange 2003 alatt a default blokkméret az adatbázisban 4 Kbyte, Exchange 2007 alatt 8 Kbyte. Azaz bármekkora is volt a levél, egy 4/8 Kbyte méretű stub marad a levél helyén. A felszabaduló helyet pedig az Online Maintenance visszadolgozza a szabad területek közé.
Az Exchange 2010 alatt a blokkméret 32 Kbyte lett. Gondoljuk el: akármekkora volt a levél, 32 Kbyte hely mindig foglalt marad a számára. Rólam tudni kell, hogy hajlamos vagyok több képernyő hosszúságú emaileket írni, de még ezek sem érik el a 32K méretet. Gyakorlatilag ezt a határt csak csatolással szokták átlépni – igaz, azzal nagyon.
Akkor mi is az a pitiáner hiba? Az, amikor úgy állítják be a külső rendszert, hogy alaphelyzetben a csatolásokat archiválja, de egy bizonyos idő eltelte (mondjuk egy év) után minden levelet. Ez az utóbbi húzás az, amelynek az égegyadta világon semmi értelme sincsen. A levél után ott marad a 32K hely, igaz, ezen belül a sok szöveg helyett csak egy link lesz benne – de a felszabaduló hellyel az Online Maintenance nem tud mit kezdeni. Foglalt marad. Cserébe megnyerjük, hogy plusz helyet foglalunk el az archiváló rendszerben, a felhasználó lassabban éri el a régi levelét, egyszerre kell gondoskodnunk mind a két rendszer rendelkezésreállásáról és kinlódhatunk mind a backup/restore, mind a DR folyamatainkkal.
Azaz, ha használunk ilyen külső rendszereket, akkor felejtsük el az idő alapon történő archiválást az összes levélre, koncentráljunk csak a csatolásokra. (A magam részéről pedig azt tenném hozzá, hogy gondolkozzunk el a Personal Archive és menedzselt mailbox kombináción, sokkal olcsóbban – és egyszerűbben – is el tudjuk érni ugyanazt, mint a külső cuccokkal.)
Recent Comments