Exchange Server Mimarisinde yedekleme büyük bir öneme sahiptir. Şimdi aklınıza yedeklemenin önemli olmadığı ürün mü var diye sorular getiriyor olabilirsiniz ama Exchange Server için durum bir parça daha farklı. Çünkü yedek almıyor olmanız sadece verilerinizin olası bir kaybına neden olmanın dışında mevcut sisteminde çalışmasını etkileyebilir.
Bildiğiniz gibi Exchange Server çalışma mimarisi gereği RAM üzerindeki bilgileri Log dosyasına oradan ise veri tabanına yazar, bu durumda aslında her şey logların üzerinden geçtiği için log dosyaları çok önemlidir. Olası bir veri tabanı bozulması veya kurtarma operasyonunda yedekten dönmeden veri tabanını ayağa kaldırma şansına sahipsiniz. Bunun temel nedeni aslında veri tabanınız da o logların bir bütünüdür. Ancak tabiki siz düzenli yedek aldıkça bu loglar veri tabanına işlendiği ve bunun kontrolü yapıldığı için düzenli olarak silinir. Örneğin 40GB veri tabanınız var iken o anda 1.2GB log dosyanız olabilir, ancak bir sonraki yedekleme işlemi ile bu loglar da veri tabanına yazıldığı için otomatik olarak silinir. Bu süreçte kullandığınız yedekleme yazılımı full veya incrementel yedek için Exchange Server’ ın yüklü olduğu işletim sistemindeki Volume Shadow Copy VSC özelliğini kullanır ve bu sayede başarılı yedekleme sonrasında logların otomatik olarak silindiğini görebilirsiniz.
Eğer düzenli yedek almazsanız bu loglar ne yazık ki silinmez ve bu durumda da diskiniz dolacağı için hizmet kesintisi yaşayabilirsiniz. Makalemin başında da dediğim gibi eğer Exchange Server için düzenli yedek alınmaz ise sadece veri kaybı değil servis kesintisi de yaşanması normaldir.
Ancak pek çok Exchange yöneticisi bu loglardan bıkmış olduğu için bir alternatif olan circular Logging özelliğini kullanırlar, yani bu durumda yeni logların eklenmesi söz konusu olmazken sistem mevcut logların üzerine yazmaya devam eder. Bu durumda yerden kazanım olur çünkü loglar sürekli olarak artmayacaktır, ancak dez avantajı olası bir kesinti durumunda logları kullanmayacağınız için DB bozulur ise mecbur en son yedeğe dönmeniz gereklidir.
Normal circular logging açmanız halinde bunun yönetimi Exchange information store servisi tarafından yönetilirken continuous replication circular logging (CRCL) açmanız halinde ise bu mekanizma Microsoft Exchange Replication Service tarafından yönetilmektedir.
Bu durumda Circular logging deki gibi logların silinmesi veya üzerine yazılması söz konusu değildir, çünkü bu loglar replike edilecektir.
Eğer bir veri tabanında CL açılır ve bu veri tabanı replike değil ise bildiğimiz standart CL davranışı olan ek log dosyası üretmeme ve var olanın üzerine yazma davranışı sergilenir. Ancak circular logging açtığınız veri tabanı eğer replike bir veri tabanı ise bu durumda CRCL otomatik devreye girer ve bu durumda Microsoft Exchange Information Store servisi ile Microsoft Exchange Replication servisi remote procedure calls (RPCs) üzerinden hangi log dosyasının silinebileceğine karar verme noktasında iletişime geçer.
Bir veri tabanı üzerinde circular logging açıldığında eğer veri tabanı replike değil ise bunu geçerli olması için dismount ve mount işlemi gerekli iken eğer replike bir veri tabanı ise CRCL otomatik devreye girer ( kısa bir süre içerisinde ).
Bir veri tabanı için circular Logging aşağıdaki gibi açılıp kapatılabilir
Set-MailboxDatabase DB1 -CircularLoggingEnabled $True
Set-MailboxDatabase DB1 -CircularLoggingEnabled $False
Peki, bu durumda yedeklemenin çok önemli olduğunu veya log dosyalarından sebep eğer disklerimiz hızlı doluyor ise CL açarak bunu aşabileceğimizi öğrendik. Ancak bazı senaryolarda veya yedekten dönmenin çok ciddi sorunlara veya veri kayıplarına yol açacak şirketler için CL kabul edilebilir bir çalışma yöntemi değildir.
Böyle bir şirkette çalışıyorsanız yani Circular Logging açma gibi bir şansınız yok ise bu durumda yedekleme alt yapınız çok iyi olmalı, eğer yedekleme tarafında sorunlar yaşarsanız örneğin birkaç gün gibi kısa bir sürede Exchange diskleriniz bu loglardan kaynaklı dolabilir.
Benim bu makalemdeki amacım ise genellikle büyük kurumlarda Exchange yedekleme sistemleri için kullanılan 3 parti yazılım firmaları ile Exchange mühendisleri arasındaki sorun sende bende kavgasına son vermek J
Bunun için Volume Shadow Copy Service SDK 7.2 ile beraber gelen Betest.exe aracını kullanacağım.
Öncelikle bu aracı indirelim ve Exchange Server üzerinde kurulum yapalım.
https://www.microsoft.com/en-us/download/details.aspx?id=23490
Kurulum sonrasında Exchange Server üzerinde aşağıdaki komut ile VSS writer listesinden Exchange için kullanılan bileşenin ID numarasını alalım
Vssadmin list writers
Eğer bu Exchange Server bir DAG üyesi mailbox sunucusu ise ve üzerinde pasif veri tabanı kopyası var ise bu durumda “Microsoft Exchange Replica Writer” ı da ek olarak görebilirsiniz.
Not: Eğer bu writer ların durumunda “Last Error” hata görüyorsanı makineyi restart etmenizi öneririm. Aslında gerekli olan information store veya replikasyon servisini restart etmek ama daha sağlam iş olsun diye ve uygun bir ortam var ise sunucuyu yeniden başlayabilirsiniz.
Betest için bir Config dosyası hazırlıyor olmamız gerekiyor, örnek dosya aşağıdaki gibidir
C:\Program Files (x86)\Microsoft\VSSSDK72\TestApps\betest\obj\amd64 altında components.txt isminde olmalı
“{76fe1ac4-15f7-4bcd-987e-8e1acb462fb7}”:”Microsoft Exchange Server\Microsoft Information Store\Postaci\2bf49cd7-fcee-4f2e-a523-feb8a7b0dfc1″;
Buradaki 76 ile başlayan rakam WriterID yi temsil ediyor, Postaci ise mailbox sunucu ismi, son 2b ile başlayan GUID ise aşağıdaki gibi hangi veri tabanını yedeklemek istiyorsanız onun GUID numarasını ekliyorsunuz.
Eğer pasif kopyayı yedeklemek istiyorsanız aşağıdaki gibi komuta ek olarak \Replica yazmanız gerekli
“{76fe1ac4-15f7-4bcd-987e-8e1acb462fb7}”:”Microsoft Exchange Server\Microsoft Information Store\Replica\Postaci\2bf49cd7-fcee-4f2e-a523-feb8a7b0dfc1″;
Şimdi test işlemini başlatabiliriz,
Komut setinden aşağıdaki dizine geçiyoruz
C:\Program Files (x86)\Microsoft\VSSSDK72\TestApps\betest\obj\amd64
Daha sonra aşağıdaki komutu çalıştırıyoruz
BETEST.exe /B /E /T 1 /S output.XML /C components.txt /D c:\betest > output.txt
Burada c:\betest dizini yedek alacağınız dizin olduğu için yeterli alanın olduğundan emin olun.
Bittikten sonra komutu çalıştırdığınız dizindeki output.txt yi inceleyebilirsiniz.
Peki bu testi aslında ne için yaptık? Eğer bu test soncunda yedek alma işleminde bir hata alırsanız bu VSS sorununa işaret eder ki yedekleme yazılımı üreticisini suçlamak yerine Micrsoft tarafında bir case açarak veya çıktı dosyalarındaki hataları inceleyerek sorunu çözdükten sonra yedekleme yazılımı ile yedek almaya devam edebilirsiniz.
Not: bu işlem sayesinde tabiki log dosyalarınız da otomatik olarak silinecektir.
Kaynak
https://techcommunity.microsoft.com/t5/exchange-team-blog/bg-p/Exchange