Exchange ve Active Directory Sunucu Veri Kurtarma: EDB ve NTDS.dit

Hızlı cevap: Exchange posta veritabanınız (EDB) ya da Active Directory veritabanınız (NTDS.dit) açılmıyorsa ilk kural sunucuyu yeniden kurmaya kalkmamaktır. Çoğu vakada veritabanı sağlamdır, sorun yarım kalan kapanış (dirty shutdown) ve uygulanmamış işlem günlükleridir. Log replay ve onarım doğru sırayla yapılırsa posta kutuları ve dizin nesneleri kurtulur. Yanlış müdahale veriyi kalıcı bozar. Acil hat: +90 536 662 38 09.

EDB ve NTDS.dit aslında nedir?

Hem Microsoft Exchange hem Active Directory, arka planda aynı veritabanı motorunu kullanır: ESE (Extensible Storage Engine), eski adıyla Jet Blue. Exchange tarafında bütün posta kutuları tek bir .edb dosyasında, Active Directory tarafında ise tüm kullanıcılar, gruplar ve parolalar NTDS.dit dosyasında tutulur. Her iki sistemde de yazma işlemleri önce işlem günlüğüne (transaction log) düşer, sonra veritabanına işlenir.

Bu mimari, ani elektrik kesintisi ya da disk arızası anında veriyi korumak için tasarlanmıştır. Ne var ki kapanış düzgün tamamlanmazsa veritabanı "dirty shutdown" (kirli kapanış) durumunda kalır ve mount olmaz. Burada panikleyip yanlış komut çalıştırmak, kurtarılabilir bir veritabanını bitirebilir.

Dirty shutdown ne demek, neden mount olmuyor?

Bir Exchange veritabanı normalde "clean shutdown" durumunda kapanır. Bu, bekleyen tüm işlemlerin günlükten veritabanına yazıldığı anlamına gelir. Sunucu çökerse, RAID bozulursa ya da güç giderse veritabanı clean olmadan kalır. Mount denemesi şu hatayı verir: veritabanı tutarlı bir kapanış durumunda değil.

Durumu eseutil aracıyla görürsünüz:

  • eseutil /mh komutu veritabanının başlık bilgisini gösterir. State satırı "Dirty Shutdown" ise eksik günlükler vardır.
  • Required Log satırı, mount için hangi günlük dosyalarının gerektiğini söyler. O günlükler diskte duruyorsa kurtarma çok büyük olasılıkla temiz biter.

İlk hedef her zaman log replay'dir, yani eksik işlemleri günlükten geri oynatmak. Bu, en az veri kaybı olan ve veritabanına en az dokunan yöntemdir.

Kurtarma yöntemleri ve hangi durumda hangisi

Durum Yöntem Risk Veri kaybı
Dirty shutdown, günlükler sağlam eseutil /r (soft recovery, log replay) Düşük Yok denecek kadar az
Günlükler eksik veya bozuk eseutil /p (hard repair) Yüksek Bozuk sayfalar atılır
Disk/RAID fiziksel arızası Önce imaj, sonra onarım Orta Arızanın derinliğine bağlı
NTDS.dit bozuk, DC çalışmıyor Sistem durumu yedeği + ntdsutil Orta Yedeğe bağlı

Önemli ayrım şu: eseutil /r (soft recovery) güvenlidir, sadece günlükteki işlemleri uygular. eseutil /p (hard repair) ise son çaredir. Bozuk sayfaları tamir etmez, fiziksel olarak siler. Microsoft bile bu komuttan sonra veritabanını taşımayı (mailbox move) önerir çünkü mantıksal tutarlılık garanti edilemez. Bu yüzden hard repair öncesi mutlaka birebir imaj alınmalıdır.

Active Directory neden ayrı bir dünya?

Bir domain controller (DC) çökerse, sadece bir sunucu değil tüm kimlik altyapısı tehlikeye girer. NTDS.dit, kullanıcı oturum açma bilgilerinden grup ilkelerine kadar her şeyi tutar. Tek DC'li ortamlarda bu dosyanın kaybı, tüm domainin kaybı anlamına gelebilir.

Doğru kurtarma yolu, sistem durumu (system state) yedeğinden geri yüklemektir. Bu yedek NTDS.dit, SYSVOL ve kayıt defteri kovanlarını birlikte içerir. Yetkili (authoritative) ve yetkisiz (non-authoritative) geri yükleme ayrımı kritiktir: yanlış mod, az önce silinen bir nesneyi tekrar replikasyonla silebilir. Yedek yoksa, NTDS.dit dosyasının ESE düzeyinde onarımı denenir ama AD'nin mantıksal tutarlılığı (USN, replikasyon meta verisi) her zaman tam geri gelmeyebilir. Bu yüzden DC kurtarması, salt dosya kurtarmadan farklı bir uzmanlık ister.

Sunucu sanal makinede çalışıyorsa

Exchange ve AD çoğunlukla sanallaştırılmış ortamlarda koşar. Sorun bazen veritabanında değil, altta yatan VMDK ya da VHDX disk dosyasındadır. Bu durumda kurtarma iki katmanlıdır: önce sanal disk imajının onarımı, sonra içindeki EDB veya NTDS.dit. Bu konuyu ayrıntılı ele aldığımız sanal makine disk imajı kurtarma yazısına göz atabilirsiniz. Sunucu fiziksel bir RAID dizisi üzerindeyse ve dizi çöktüyse, RAID 5 çöktü kurtarma süreci yazısı ilk müdahale için yol gösterir.

İlk müdahalede yapılması ve yapılmaması gerekenler

Yapın: Sunucuyu mevcut haliyle dondurun, işlem günlüklerini ve veritabanını silmeyin, varsa son sistem durumu yedeğini koruyun, eseutil /mh ile durumu kayıt altına alın.

Yapmayın: Hiçbir koşulda eseutil /p komutunu imaj almadan çalıştırmayın, günlük dosyalarını "yer açmak için" silmeyin, bozuk veritabanını yeniden mount etmeyi defalarca denemeyin, Exchange'i yeniden kurup üzerine yazmayın.

DSET kurumsal sunucu yaklaşımı

DSET olarak 2003'ten beri Ankara Hacettepe Teknokent Beytepe laboratuvarında kurumsal sunucu kurtarıyoruz. Önce diziden ya da sanal diskten birebir imaj alır, tüm çalışmayı kopya üzerinde yaparız. Orijinal veriye asla riskli komut uygulamayız. Başarı oranımız yüzde 99,4. İlk teşhis ücretsizdir ve veri çıkmazsa ücret almıyoruz. Süreç boyunca verinizin gizliliğini nasıl koruduğumuzu gizlilik ve ücret politikamızda okuyabilirsiniz.

Sık Sorulan Sorular (SSS)

Dirty shutdown veritabanım kurtulur mu?

Çoğu zaman evet. Gerekli işlem günlükleri diskte duruyorsa eseutil /r ile soft recovery yapılır ve veri kaybı neredeyse sıfır olur. Günlükler eksikse onarım daha risklidir ama yine de büyük olasılıkla posta kutularının çoğu kurtulur.

eseutil /p komutunu kendim çalıştırabilir miyim?

Çalıştırabilirsiniz ama önermiyoruz. Bu komut bozuk sayfaları siler ve geri dönüşü yoktur. Önce birebir imaj alınmadan yapılırsa tek şansınızı harcamış olabilirsiniz. Önce bizi arayın, ücretsiz teşhis yapalım.

Active Directory yedeğim yok, NTDS.dit bozuk. Ne olur?

Yedek yoksa NTDS.dit dosyasının ESE düzeyinde onarımı denenir. Kullanıcı ve nesnelerin büyük kısmı genelde kurtulur, ancak replikasyon meta verisindeki tutarsızlıklar ek elden geçirme gerektirebilir. Tek DC'li ortamlarda bu işlem özel uzmanlık ister.

Exchange sunucum sanal makinede, disk dosyası bozuldu. Önce hangisini kurtarıyorsunuz?

Önce dıştaki sanal disk imajını (VMDK veya VHDX) onarırız, içindeki dosya sistemine erişilebilir hale geldiğinde EDB dosyasını çıkarıp veritabanı düzeyinde kurtarmaya geçeriz. Katmanlı bir süreçtir.

Kurtarma ne kadar sürer?

Veritabanı boyutuna ve arızanın türüne bağlıdır. Soft recovery birkaç saatte biterken, fiziksel RAID arızasıyla birlikte gelen vakalar birkaç günü bulabilir. İlk teşhiste size net bir süre veriyoruz.

Kaynaklar