Forum
Çalıştığım firmada Exchange 2010 DAG yapıda 2 sunucuda store lar tutuluyor. Toplam 7 store bulunmakta. Tüm store ların günlük backup ını DPM 2010 SP1 ile alıyorum fakat yaklaşık 3 aydır Journal Store un backup ını alamıyorum be loglar şişip diskte yer kalmadığında Journal Store u silmek durumunda kalıyorum. "Windows Server Backup" ile backup aldığımda sorunsuz alıyor ve logları temizliyor. DPM deki seçtiğim adımlar resimlerde görüldüğü gibi.
DPM de aldığım hata ;
Exchange sunucuya düşen hata logu ; Event 9782, MSExchangeIS
Exchange VSS Writer (instance 14096598-b0ec-47b4-8efa-02fe49a2b38d:4) has completed the backup of database 'DB_Journal' with errors. The backup did not complete successfully, and no log files were truncated for this database.
Yardımcı olursanız sevinirim.
hem dpm 2012 hem de exchange sunucular uzerinde c++ redistributable 2012 nin kurulu oldugunu dogrular misiniz?
DPM de;
C++ 2010 x86 Redistributable - 10.0.30319
DAG CAS sunucuda;
C++ 2008 Redistributable - x86 9.0.30729.6161
C++ 2008 Redistributable - x64 9.0.30729.6161
Store ların bulunduğu 1. sunucuda;
C++ 2008 Redistributable - x86 9.0.30729.4148 ve
C++ 2008 Redistributable - x64 9.0.30729.4148
Store ların bulunduğu 2. sunucuda;
C++ 2008 Redistributable - x86 9.0.30729.4148 ve
C++ 2008 Redistributable - x64 9.0.30729.4148
EXCHANGE yapının versiyon bilgileri resimdeki gibidir;
Uploaded with ImageShack.us
Vss writer servisinin calistigindan emin olun.Servislerden bu servisi admin hesabi girerek tanimlayin
Sorunun çözümünü buldum. Şu an sorunsuz backup almaktayız.
Kısaca anlatmak gerekirse DPM 2010 dan DPM 2012 ye geçtikten sonra backup işlemlerinde ID:917 hatasını alıyorduk ben bu hatayı tüm backuplar aynı anda çalıştığı için cihaz fiziksel olarak yeterli olmuyor diye yorumlayıp üstünde fazla durmamıştım. Exchange backupta yaşanan sıkıntılar sebebi ile Exchange Protection Group in backup saatini diğer backuplardan ayırmıştım bu vesile ile farkettimki ID : 917 hatası sadece Exchange backup işleminde oluşuyordu.
Bunun üzerine araştırdığımda bir makalede ( http://social.technet.microsoft.com/Forums/en-US/17b8def5-0c41-444d-a840-64dafd9a1a80/connection-to-the-dpm-service-has-been-lost-id917-when-backup-of-exchange-database-runs-to ) bu şekilde : "This can occur if there are two entries in the tbl_RM_RecoverableObject table for Exchange's component. There should be only 1 entry - unfortunately this is not something that is fixable in a forum setting, please open a support case for further investigation and solution." bir açıklama okudum.
tbl_RM_RecoverableObject tablosuna baktığımda Exchange için tanımlamış olduğumuz eski backupların izlerinin bile hala tabloda bulunduğunu gördüm. Bu kayıtlar sanırım DPM 2010 dan 2012 Eval'e geçiş ve Eval RTM versiyona geçerken DPM DB backup - restore işlemlerinden kaynaklandı. Bunun üzerine DPM de Exchange protection group ı sildim ve Exchange sunucularımdan DPM agentlarını kaldırdım amacım DPM üzerinde Exchange ile ilgili hiçbir kalıntı bırakmayıp DB üzerinde manuel silme işlemi yapmaktı.
Bulduğum ( http://gallery.technet.microsoft.com/scriptcenter/c0c57332-8624-48c0-b4c3-5b31fe641c58 ) bu store procedure ile DB de "Exchange","Journal" ve "[SUNUCU_İSİMLERİ]" gibi aramalar yaparak çıkan tüm kayıtları sildim. Bu kısım pek kolay olmadı çünkü tablolar birbiri ile ilişkili olduğundan örneğin bir tablodan bir veri silmek istediğimde diğer bir tablodaki kayıtla eşleştiği hatasını alıyordum ve iç içe sorgular yazarak (yaklaşık 600 sorgu) DB deki tüm kayıtları sildim. Çözüm olarak iki seçenek vardı ya DPM i tekrardan kurmak ki kritik backuplar olduğu için bunu göze alamadım yada DB den kayıt silmek, kayıt silmeye başladığımda 600 tane sorgu yazmam gerektiğini öngöremedim çünkü bir tablodaki bir kaydı silebilmek için tam 13 tablodan kayıt silmem gerektiği oldu fakat her defasında sanırım bu son hatadır diyip bir sonraki adıma geçtim biraz sinir bozucu oldu ama temizlendi çok şükür.
Şu an exchange sunucularıma agent ı tekrar kurdum ve protection group oluşturdum yedekler sorunsuz alındı. İlgilenenlere tekrar teşekkürler.
Geri bildirim için teşekküürler.