Başarılı tamamlanan bir Exchange Database yedek alma görevi ve sonrasında olay gümlüklerinde görmüş olduğunuz Storage Group Consistency Check bilgilendirmesi kafa karıştırmaktadır.
Exchange Server yöneticileri çok iyi bilmektedir ki dirty shutdown state özelliği Exchange Server Databaseleri için istenilmeyen bir durumdur ve çoğu kez veri kaybı ile sonuçlanan ve geri dönüş işlemleri uzun ve sancılı olan bir durumdur.
Storage Group Consistency Check
Source: Storage Group Consistency Check
Event ID: 200
Level: Information
Instance 1: Database headers have been successfully validated. All databases are in a dirty shutdown state. To bring these databases to a clean shutdown state, log generations 733783 (0x000b3257) to 733892 (0x000b32c4) will be required.
Başarılı bir şekilde tamamlanan Exchange server database yedekleme görevi ve sonrasında oluşan bu olay günlüğünü gördüğünüz zaman çok panik yapmayın. İçeriği her ne kadar ürkütücü olsa bile ufak bir araştırma yaptıktan sonra sadece bilgi verme amacı taşıyan olay günlüğü olduğunuz göreceksiniz. Zaten bulunmuş olduğu olay günlüğü seviyesi de Information sınıfında yer almakta.
Eğer endişeniz devam ediyorsa eseutil / mh komutu ile veri tabanı kontrolü yapabilirsiniz.
Peki ama Exchange Server Database üzerinde bir problem yoksa ve Exchange Server yedekleme görevi başarılı bir şekilde tamamlandıysa bu bilgilendirme ve üstelik hiç istemediğimiz içeriğe sahip olan dirty shutdown state bilgilendirmesi neden yapılmakta?
Exchange Server Database Yedek Alma Türleri
Exchange Server veri tabanı yedek alma işlemleri iki yöntemde yapılmaktadır.
Legacy streaming backup çözümü Eski Exchange server database ‘leri için yapılan bir yedek alma çözümüdür. Windows işletim sistemiyle birlikte Exchange Veri tabanı ve mimarisini bilen ve Exchange Server Extensible Storage Engine (ESE) API ‘lerini okuya bilen yedek alma görevidir.
Bu eski bir teknolojidir ve üçüncü taraf yedek alma yazılımlarının kontrolündedir.
Volume Shadow Copy Service ise diğer bir yöntemdir ve günümüz de genel kullanıma sahip olan yedek alma yöntemidir. Exchange Server 2003 ile tanışmış olduğumuz Volume Shadow Copy Service yedek alma çözümü Exchange server 2007 ile gelişmiş ve Exchange Server 2010 ile birlikte DAG mimarisiyle uyumlu duruma gelmiş bir gelişmiş bir yedek alma çözümüdür.
Bu yedek alma çözümü günümüzde bir çok yedek alma yazılımları tarafından kullanılmakta, Exchange Server 2016 ve Exchange Server 2019 gibi yeni nesil Exchange server lar içinde önerilen yedek alma çözümüdür.
Yeni nesil yedek alma çözümü olan Volume Shadow Copy Service teknolojisi, Legacy streaming backup teknolojisinde olduğu gibi yedek alma görevini tamamen üçüncü taraf yedek alma ürünlerine bırakmamakta.
Legacy streaming backup teknolojisi Extensible Storage Engine (ESE) API ‘leri ile uyumlu olsa bile üçüncü taraf yedek alma yazılımının yönetimindedir ve bu yöntem de Exchange Server üçüncü taraf yedek alma yazılımına bağımlıdır.
Yedek alma yazılımında oluşacak bir hatada yada yazılım dilinde yapılacak bir değişiklik, Exchange Server Database yedek alma görevlerinde probleme sebep olacaktır. Bu sebepten ötürü Volume Shadow Copy Service teknolojisi gelişmiştir. Bu sebepten ötürü Exchange Server Database ‘leri için yedek alma ve ihtiyaç durumunda yedekden geri dönme işlemleri Exchange Serverin çalışmış olduğu işletim sisteminin kontrolündedir.
Peki ama bu ürkütücü hata neden oluşmakta. Sınıfı, bilgi vermek amacını taşımış olsa bile bu bilgilendirme neden yapılmakta bunu inceleyelim.
Consistency check has been successfully initiated
Source: Storage Group Consistency Check
Event ID: 200
Level: Information
Instance 1: A physical consistency check has been successfully initiated. Database ‘\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy51\Database14\Database14.edb’ and the transaction log files in ‘\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy51\Database14\Database14Logs’ with a base name of ‘E09‘ will be validated.
Yukarıda paylaşmış olduğum Consistency check has been successfully initiated olay günlüğü ise All databases are in a dirty shutdown state olay günlüğünden hemen önce oluşan bir başka bilgilendirme olay günlüğü. Bu olay günlüğünde ise Exchange Server organizasyonum içinde bulunan Database14 için oluşmuş ve Exchange Server Database yedek alma görevinin yolunda olduğunu söylemekte.
All databases are in a dirty shutdown state olay günlüğü, genel bir olay günlüğüdür başarılı bir şekilde tamamlanan her bir yedek alma görevinden sonra yani Consistency check has been successfully initiated olay günlüğünden hemen sonra oluşmaktadır.
Şimdi sorumuza gelelim, her şey yolundaysa ve panik yapmayın diyorsak All databases are in a dirty shutdown state gibi ürkütücü bir bilgilendirme neden yapılmakta?
Exchange Recovered File Fragments
Yukarıda paylaşmış olduğum ekran görüntüsü olay günlüklerine sebep olan ve başarılı bir şekilde yedek alınan Exchange Server Database ‘nin sahip olduğu Circulur Logging dizini. ikinci paylaşmış olduğum olay günlüğünde bu dizina şağıda ki gibi görülmekte ve yenilenme zamanı ise Consistency check has been successfully initiated olay günlüklerinden hemen sonra.
‘\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy51\Database14\Database14Logs’ with a base name of ‘E09‘ will be validated.
Olay günlüğünde Volume Shadow Copy Service ‘nin dizini görülmekte biz ise Windows işletim sisteminde tanıtmış olduğumuz dizin üzerinden bu alana ulaştık.
Exchange Server database yedek alma işlemi Volume Shadow Copy Service yedek alma yöntemidir ve Exchange server organizasyonu için önermektedir. Imaj yedek alma yada eski yöntem olan Legacy streaming backup çözümü önerilmez…
Olay günlüklerinin de bizlere söylemiş olduğu Volume Shadow Copy Service, Türkçe karşılığı da gölge kopyalamadır. Yedek alma görevi başladığı zaman ve yedek alma görevi tamamlanana kadar geçen sürede oluşan veriler yedeklenmeyecek (bu değişkenler ise bir sonra ki yedek alma zamanında yedek alınacaktır) ve yedek alma görevi tamamlandıktan sonra Exchange Recovered File Fragments dosyası da yenilenecektir.
Bu işlemler tamamlandıktan sonra Sağlıklı bir geri dönüş noktasına sahip olabiliriz.
İlk olay günlüğü ile ikinci olay günlüğü arasında çok kısa bir zaman olsa bile bu kısa zaman aralığında yapılan işlemlerin bilgisi bizlere verilmekte ve ihtiyaç durumunda Exchange server Recovery yapmamız gerektiği zaman bu kısa aralıkta ki zamana geri dönemeyeceğimizin uyarısı yapılmakta.
Exchange Server takımı bu bilgilendirmeler ile üzerinde ki sorumluluklarından kurtuluyor olsalar bile panik atak hastalığına sahip bir Exchange yöneticisi için All databases are in a dirty shutdown state bilgilendirmesi hiç de iyi bir bilgilendirme gibi durmamakta.
