EXCHANGE SERVER ‘DA YEDEKLEME STRATEJISI
Nasil ki Istanbul’un fethi bir çagi kapatip yeni bir çagi açtiysa, bence elektronik postanin insan hayatina girmeside yeni bir çag baslatti. Henüz tarihe geçmedi ama torunlarimiz ilerde bana katilacaktir, bundan eminim. Emin olmamin sebebi ise son 3 yil içersinde internet kullanim oranlarindaki artis; Internet kullanimi dünya çapinda % 1800 artmis, toplam 3,5 milyon websitesi ve domain, kayitli 8-9 milyon mail adresi. Sadece hotmail adresleri saatte 6 –8 terrabayt veri transferi yapiyor, evet rakamlar devasa geliyor ama bir kaç yil sonra bunlarda o zamanin sartlarina göre komik kalacak.
Iste tüm bu mail trafiginin omurgasini pastadaki % 55 lik dilimiyle Microsoft Exchange Server yazilimi olusturmaktadir. Çok önemli datalarin tutulabildigi Exchange database’ini güvende tutmak ve sistem devamliliginin saglamak üzerine konusalim.
EXCHANGE SERVER DATABASE ININ YEDEKLENEMESI
Sistem yöneticilerinin korkulu rüyalarindan birisidir exchange çökmesi fakat biraz tedbir ve dogru back-up ile yikimlardan(disaster) kolayca kurtulmak mümkündür. Exchange’in Windows ile ortak çalistigi, active directory ile bütünlestigi dogrudur. Ancak unutulmamasi gereken nokta isletim sisteminden ayri bir yazilim oldugudur. Demek oluyor ki NT back up aslinda bir takim özel islemleri gerçeklestirmeden Exchange database ini yedekleyemez.
Exchange yüklü bir server da NT back up çalistirilip tüm disk seçilmek süretiyle alinan yedeklerin raporlarina bakildiginda exchange için önem arzeden dosyalarin yedeklerinin alinamadigini o anda kullanildigi için es geçildigi (skip) açikca gözlenir. Söz konusu dosyalarin isimlerini hatirlamak gerekirse pub1.edb, pub1.stm, priv1.edb ve priv1.stm dir. Bu dosyalari c:\exchsrvr\mdbdata klasörü altinda bulmak mümkündür, Her ne kadar ilisikli olsa da “genel olarak pub database’i mailboxlar, priv1 database’i ise public folder bilgilerini tutar.” cümlesi yanlis sayilamaz. Mdbdata klasörüne inildigi zaman eger system managerda -loglari üzerine yaz- check boxu isaretli degilse pek çok log dosyasi da görünür. Aslinda bu dosyalar exchange database’inin transaction loglaridir. Exchange yaptigi tüm isleri bu loglara yazar. Exchange yedeklenirken bunlari yedeklemek farz degildir ama database’lerin bozuldugu bir durumda loglar baz alinarak recovery islemi yapilabilir. Böylece bir yikim engellenmis olur. Kisisel tavsiyem yedek alirken ilgili transaction loglarini da yedeklemektir.
* Yedekleme esnasinda dikkat edilecek birinci husus sistemi offline konumuna getirmektir. Yani konu ilgili çalisan servisleri kapatmak;
Microsoft Exchange Internet Mail Service
Microsoft Exchange Event Service
Microsoft Exchange Message Transfer Agent
Microsoft Exchange Information Store
Microsoft Exchange Directory
Microsoft Exchange System Attendant
* Servislerin kapatilmasinin ardindan server bilgisayarin system state’ini ntback up veya üçüncü parti bir yazilimla yedeklemek gerekir.
Yukarda bahsettigimiz gibi exchange, active directory’e ilisik biçimdedir ve bilindigi gibi active directory de ki her obje için bir SID bulunur bu SID ler Active Directory nin her kurulmasinda degisir. Isletim sistemi ise objeleri bu SID ile bulur, sorgular. Ayni sartlar altinda ayni domain de iki farkli Active Directory yüklemek ve ayni kullanici hesaplarini olusturmak mümkün olsa iki directory içinde kullanicilara tahsis edilen SID numaralari farkli olacaktir. Buradan çikarmamiz gereken sonuç, exchange sistem database’nin bir çökme ardindan geri dönülmesi, sistemin çalistigi andaki Active Directory ve SID numaralarinin serverda bulunmasi gerekliligini dogurur. Baska bir deyisle de Exchange database’ini rastgele bir Active Directory e geri döndermek mümkün degildir. Mutlaka serveri yikimdan önceki duruma getirmek gerekir. System state’i bu sebele yedekliyoruz.
* Son olarak copy – paste veya ntbackup ile söz konusu databaseleri ve loglari yedeklemek dir.
Bu yedekleme yapilirken de dikkat edilmesi gereken husus database’in isletim sistemi olmayan bir partition’a veya farkli bir HDD veya tape back-up ünitelerine yapilmasidir. Bu 3 adim ile exchange serveri yedeklemis olduk. Artik servislerimizi aktif hale getirebiliriz.
EXCHANGE SERVER DATABASE’INI YEDEKTEN GERI YÜKLEMEK
Exchange’i yedeklemek ne kadar kolaysa yedekten geri dönülmesi de o kadar kolaydir. Yalniz geri dönüsüm esnasinda bizi kisitlayan etkenlerin fazlaligi konunun karisik görünmesine neden olabilir.
Yikimlarda kendi aralarinda farklilik gösterir. Örnegin sadece exchange server çökebilir, Active Directory çökebilir veya dump hali dedigimiz mavi ekranla karsilasip bilgisayarin hiç açilamamasi olabilir hatta yikimin ardindan formatlanmis bir makine ile de karsilasabiliriz. Bu tip durumlari tek tek irdeleyelim.
Sadece exchange in çökmesi durumu demek mail transferinin tek yönlü veya iki yönlü tikanmasi, posta alisverisinin durmasi demek. Tüm kontrolleri yaptiniz sistemde normal ama mail transferi olmuyor. Exchange i kaldirip, tekrar kurmak istiyorsunuz isletim sisteminiz ayakta. Exchange i tekrar install ettiniz. Yapmaniz gereken tek sey MDBDATA klasörü altini tamamen bosalttiktan sonra Pub ve priv databaselerini bu klasörün altina yapistirmak. Sistem log olmadigini görünce kendisi olusturacaktir.
Tam disaster yani yikim durumunda sistemin geri dönüsünü konunun anlasilmasi açisindan adim adim irdeleyeleyim
Öncelikle kisitlarimizi gözden geçirmeliyiz.
* Yeni kurulacak makinenin FQDN (tam ismi) öncekiyle ayni olmali.
* Yeni kurulacak makinede Active Directory bilgisi öncekiyle ayni olmali.
* Yeni makinenin statik ipsi ilk asamada öncekiyle ayni olmali.
Bu kisitlar isiginda
* Server isletim sistemini ayaga kaldirdiktan sonra Active Directory kurulur akabinde sistem restore mod da açilmak süretiyle system state restore edilir. System State in restore edilmesi Active Directory’mizi eski SID nolariyla ayaga kaldirdigimiz anlamina gelir.
* Exchange ilk kurusta oldugu sekilde kurulur.
* Yukarda adi geçen servisler stop edilir.
* Mdbdata klasörüne inilir. Alti bosaltilir ve yedek database’lerimiz (loglar hariç) yerine kopyalanir.
* Servisler start edilir.
* Servislerin start edilmesinin ardindan, mailboxlarin ve public folderlarin oldugu sanal M sürücüsünü isinteg islemi için dismount etmek gerekmektedir. Dismount islemi için system managerda first storege group genisletilerek mailboxlar ve public folderlar dismount store komutu ile sistemden ayrilir.
* Isinteg islemi yeni kurulan exchange ile sonradan eklenen eski database arasinda sistem bilgisinin güncellemesi ve tam senkronize çalismasi için Microsoft tarafindan tavsiye edilen bir islemdir. Kimi durumlarda isinteg islemi yapilmadan da sistem normale dönebilir. Bu islemin nasil yapidigi konusuna gelince; c:\exchsrvr\bin klasörüne komut satirindan gidilir. Burada isinteg komutunun help inden de anlasilacagi sekilde yanina istediginiz opsiyonlari ekleyebilirsiniz. Yalniz dikkat edilmesi gereken husus testlerin hem mailbox (1) hem Public Folders (2) için yapilamsidir. Isinteg için örnek syntax “isinteg –s servername –fix –verbose –test alltest”
* isinteg islemini hem public hem mailboxlar için yaptiktan sonra sistemi tekrar first storage group dan mount ediyoruz. Böylece Exchange’i yedek aldigimiz zamana geri döndermis oluyoruz.
BOZUK EXCHANGE DATABASELERININ TAMIRI VE DEFRAGMANTASYONU
Yukarda adi geçen pub ve priv dosyalarinin exchange databaseleri oldugunu ve exchange bilgisinin bunlarda tutuldugunu ögrendik ancak bu ilgili exchange dosyalarinin çok hasas oldugunu eklemek zamanidir. Exchange 2000’de en çok rastlanan arizalardan birisi olan database’in bozulmasi, yine isletim sistemi içersindeki bazi yardimci araçlarla düzeltilebilir. Bozuk exchange databaselerinin tamiri konusunu irdeleyelim.
Exchange 2000 serverlarin bir handikapi sanal bir sürücüye mount edilmesidir. Bu handikap 2003 serverda giderilmistir. 2000 server için ise Remove the IFS Mapping for Drive M in Exchange 2000 Server ( color=#000000http://support.microsoft.com/default.aspx?scid=kb;en-us;Q305145&sd=tech) basligi altinda irdelenmistir. Oradaki adimlari dikkatlice uygulayarak exchange’in sanal diske mount etmesi engellenebilir. Nadiren isletim sistemindeki güncellemeler, service pack yüklemeleri, donanim destekleri; genelde de antivirüs programlarinin sanal (M:) sürücüsünü taramaya çalismasi, open relay ile server üzerinden donanim kapasitesi üzerimde spam mail gönderilmeye çalisilmasi ve public folderlara çok fazla veri girisi(domain altinda çok fazla site varsa) exchange database’ini bozan etkenlerdendir.
Serverda agirlasma, store.exe dosyasinin islemci kaynaklarini tüketmesi(islemcinin altini çiziyorum, RAM kaynaklarinin tüketmesi farkli bir sikintidir.), server restart edildikten bir süre sonra mail transferinin çift yönlü yavaslamasi veya tamamen durmasi, clientlerde mail gönderimi esnasinda maillerin outbox ta çok uzun süre beklemesi, Outlooklardan görüldügü halde system managerdan public folderlarin görüntülenememesi, yenilerinin olusturulamamasi veya pub database’i de bozulmussa maillere ulasama(outlook isimleri çözdügü halde) bozuk database symptomlaridir, event viewer’a da konu ile ilgili çok açik loglar düsmez
Sistem yukardaki belirtilerinin birini veya birkaçini gösteriyor ve exchange database’inizin bozuldugunu düsünüyorsunuz ve sistemin offline yedegi yok. Tam bir kabus. ESEUTIL komutlarini bilmeyen bir sistem yöneticisinin ömrünü epeyce törpüleyecek bir durum. Bu sikici durumu atlatmak için yöntemler mevcuttur.
Eseutil komutu ile bazi parametreler kullanilarak defragmantasyon, recover, integrity(bütünlük), file dump(dosya dökümü), repair (tamir) restore, checksum islemleri yapilabilir. Fakat ençok recovery ve repair fonksiyonlari kullanilir.
Recovery fonksiyonu, bozuk exchange’i, transaction loglarini okuyarak düzeltir. Bu islemde veri kaybi yoktur. Yukarda yedekleme anlatilirken loglarin yedeklenmesini bu tip durumlar için tavsiye etmistim. Bir recovery islemi için:
.
* Ilgili serviceler stop edilir.
* Sistem dismount edilir.
* Komut satirindan exchsrvr\bin klasörüne gidilir
* Asagidaki örnek sysntax kendi sisteminize uyarlanilarak yazilir
Eseutil /r e00 /l ”c:\exchsrvr\mdbdata”
Burada eseutil komutumuz, r recovery parametresi , e00 log dosyalarinin ortak olan ilk 3 karakteri (default u e00 dir), tirnak içerisinde ise log dosyalarinin bulundugu path yazilir. Loglarin ve database’in ayni klasörde oldugunu varsayiyoruz.
* Eseutil isleminin ardindan servisler start edilir sistem mount edilmez.
* Isinteg islemi yapilir .
* Sistem mount edilir.
Tüm bunlarin ardindan sistem ayaga kalkmiyorsa paniklemeyin sistemi restart etmek düzeltebilir.
Repair islemi, genelde kötü kapatilma sonucu sistem ve mismatch hatalarinin giderilmesi ayrica bozuk exchange database’lerinin onarimi için kullanilir. Burada veri kaybi söz konusu olabilir. Bir repair islemi için:
* Ilgili servisler stop edilir.
* Sistem dismount edilir.
* Komut satirindan exchsrvr\bin klasörüne gidilir.
* Asagidaki örnek sysntax kendi sisteminize uyarlanarak yazilir.
Eseutil /p “c:\exchsrvr\mdbdata\priv1.edb”
Burada eseutil komutumuz, p repair parametremiz, tirnak içerisinde ise databaseimizin path’i yazilir. Komut dahada uzatilabilir. Bir temp database’i kullanmasi ve bu database’i farkli isimde kaydetmesi gibi spesifikasyonlarda vardir. Ancak bu kadari yeterlidir. Bu islem database’in büyüklügüne göre uzun sürebilir.
* Yukardaki islemler pub1 databasei içinde yapilir.
Eseutil /p “c:\exchsrvr\mdbdata\pub1.edb”
* Database in defrag edilmeside sistemin hizlanmasina yardimci bir durumdur. Repair islemi ardindan siddetle tavsiye edilir.
Eseutil /d “c:\exchsrvr\mdbdata\pub1.edb”
Eseutil /d “c:\exchsrvr\mdbdata\priv1.edb”
* Eseutil isleminin ardindan servisler start edilir sistem mount edilmez.
* Isinteg islemi yapilir.
* Sistem mount edilir.
Recovey ve repair islemleri ardindan sistemin normale döndügünü fakat bir süre sonra tekrar bozuldugunu fark ederseniz. Database’in bozulmasina neden olan tetikleyici unsurlari arastirmalisiniz, ki bunlar daha önce bahsettigimiz gibi üçüncü parti yazilimlar (antivirus, firewall gibi), public folder’a yogun bulk insertler gibi. Diger site’lardaki databaselerin boyut farklarida bu arastirmaya yardimci olabilir.
EXCHANGE YÖNETICILERINE TAVSIYELER
* Exchange yedeklenirken yeterli alaniniz varsa loglarida yedekleyin.
* SMTP trafigini tarayan bir antivirus yazilimi mutlaka kullanin.
* Trafigi yogun sistemlerde ikinci server mümkünse bir dc-adc degilde bir front end -back end seklinde çalistirin.
* Kullanici maillerinin mutlaka pc lerdeki pstlere aktarilmasini saglayin (hem serveri fazla mesgul etmeme, hizli çalisma hemde userla sorumluluk paylasma açisindan)
* Her mailbox için mutlaka uygun bir kota koyun uygun bir attachment boyutu siniri tahsis edin.
* Userlara birçok SMTP adresi eklemek veya forwarders olarak kullanmak yerine gruplar olusturun userlari bu gruplara üye edin.
* Exchange yedeklemesi için bir pacth dosyasini hazirlayin scheduled tasktan bunu gece saatlerine ayarlayin.(offline yedekleme esnasinda thirty party bir yedekleme yazilimi kullanmiyorsaniz mail transferi yedekleme zamani kadar duracaktir)
* OWA dll lerine ve shema bilgisine mümkün oldugu kadar az, hatta hiç müdahale etmeyin.
* Her site daki kullanicilarin maillerini o site daki Domain Controller de tutulmasini saglayin.
* Site lar arasinda replikasyon sürelerini çok kisa tutmayin. (baglanti hizina göre 128 k için 1 saat uygundur.)
ers,n arikanin makalesinden dercedilmistir.
