Daha önceleri aldığımız yedekten bir mailbox kurtarmak istediğimizde çalışan sistemin üzerine yedeği komple geri dönemediğimiz için bir başka sunucuyu hazırlayıp onun üzerinde restore işlemini gerçekleştirirdik. Exchange 2003 ile gelen yeni özelliklerden biri olan Recovery Storage Group bizim yedeklerimizden geri dönüşler yaparken bir başka sunucu ihtiyacımızı ortadan kaldırıyor. Recovery Storage Group yedekten döneceğimiz mailbox store’un mount edilip içinden istediğimiz posta kutularını kurtarabilmemizi sağlıyor. Recovery (Kurtarma) işlemlerinin bir çok senaryoda değişik metodlar ile yapılabileceği bir gerçektir. Bu farklı metodlardan birini; DialTone Recovery metodunu bir test ortamında beraberce uygulayacağız. Öncelik ile aşağıdaki resimde görüldüğü üzere problemden önce bir kullanıcının OWA ile ulaştığı postakutusunu görüyorsunuz.
Daha önceleri aldığımız yedekten bir mailbox kurtarmak istediğimizde çalışan sistemin üzerine yedeği komple geri dönemediğimiz için bir başka sunucuyu hazırlayıp onun üzerinde restore işlemini gerçekleştirirdik. Exchange 2003 ile gelen yeni özelliklerden biri olan Recovery Storage Group bizim yedeklerimizden geri dönüşler yaparken bir başka sunucu ihtiyacımızı ortadan kaldırıyor. Recovery Storage Group yedekten döneceğimiz mailbox store’un mount edilip içinden istediğimiz posta kutularını kurtarabilmemizi sağlıyor. Recovery (Kurtarma) işlemlerinin bir çok senaryoda değişik metodlar ile yapılabileceği bir gerçektir. Bu farklı metodlardan birini; DialTone Recovery metodunu bir test ortamında beraberce uygulayacağız.
Öncelik ile aşağıdaki resimde görüldüğü üzere problemden önce bir kullanıcının OWA ile ulaştığı postakutusunu görüyorsunuz.
Sistemin çalışır durumda iken Exchange System Manager ile Mailbox ve boyutlarını da aşağıdaki resimde görebilirsiniz.
Sistemin bu halinin yedeğini NTBackup aracı ile alalım. Exchange kurulu bir makinada Exchange için özel bir seçim menüsünün NTBackup içine eklendiğini görebilirsiniz.
Yedekleme işlemi bittikten sonra . Sistemin database yapısında oluşabilecek bir problemi biz manuel olarak simule edebilmek adına C:\Program Files\Exchsrvr\MDBDATA yolunu takip ederek priv1.edb ve priv1.stm dosylarının isimlerini değiştirelim veya bir başka lokasyona taşıyalım. Tabii ki bu işlemden önce Mailbox Store’un unmount (dismount) edilmesi gerekmektedir. Sistem bu hali ile o ana kadar depolanmış bütün bilgileri kaybedecektir. Yani kullanıcılarımızı hoş olmayan bir süpriz beklemektedir. Artık o ana kadar yolladıkları aldıkları sakladıkları bilgilerine ulaşamıyacaklar. Ve elbet biz sistem yöneticilerinin de bu süpriz karşısında göz önünde bulundurmaları gereken bir başka husus da zaten kaybedilmiş onca data varken sistemin işleyişinin de durmuş olmasıdır. Bu gözardı edilemiyecek bir problemdir. Doğal olarak sistemin yani email alış verişinin biran önce işlerliğini kazanması ve en kısa sürede de kullanıcı bilgilerinin geri döndürülmesi gerekmektedir. Burada bir konuyu hatırlatmakta yarar var o da Outlook 2003 kullanan istemcilerin Cached Mode çalışmaları onların .ost dosyaları sayesinde halen eski emaillerine ulaşabiliyor olacağıdır. Ama diğer client çeşitleri için malesef bu özellik kullanılır değil.
Dial-Tone metodu yukarıda manuel olarak gerçek hayatta ise ansızın karşılaşılabilecek database ile ilgili problem yaşanan durumlarda boş bir database ile Mailbox Store’un mount edilmesi daha sonra yedeğimizin bu yeni database ile birleştirilmesi esasına dayanıyor.
İlk iş olarak unmount durumdaki Mailbox Store’u mount etmeye çalışacağız. Sistem bizi boş bir database oluşturulacağı konusunda uyaracaktır. Uyarıyı onayladıktan sonra boş bir database oluşacaktır. Bu database ‘ dialtone database’i diyeceğiz.
Mount işlemi bittikten sonra kullanıcılarımız email alışverişine başlayabileceklerdir. Biz de bu sırada yedeklerimizden sistemi geri yükleyip kullanıcıların yitik bilgilerini geri döndürmeye çalışacağız. Bu amaç için Exchange System Manager konsolunda sunucumuzun üzerine gelip New>Recovery Storage Group yolunu takip edip kendimize Recovery Storage Group oluşturacağız.
Oluşan Recover Storage Group üzerinde Add Database to Recover seçeneğini seçip kurtarmak istediğimiz Mailbox Store’u seçeceğiz
Mailbox Store üzerinde Database kısmında “This database can be overwritten by a restore” seçeneğinin seçilmiş olduğundan emin olun. Tabii ki bu arada kullanıcılarımız email alışverişlerini sürdürüyorlar doğal olarak boş database (dial-tone) de yeni datalar oluşuyor. Kurtarma işleminden sonra da diğer bir işimiz bu yeni girdileri de eski database ‘e import etmek olacak. Aşağıda problemden sonra yazının başındaki OWA kullanıcısının attığı bir emaili görüyorsunuz. Dikkat ederseniz mailbox tamamen boşalmış.
Recovery Storage Group’ a Mailbox Store’u ekledikten sonra mount etmeden NTBackup aracını çalıştırıp yedeğimizi geri yükleyeceğiz. Information Store sayesinde yedek direk olarak Recovery Storage Group’ a eklenmiş unmount Mailbox Store üzerine dönecektir. NtBackuptan restore işlemini yaparken “Temporary Location for log and patch files” kısmına boş bir dizin göstereceğiz.
Yedeğimizin devamı olmadığını son yedek olduğunu belirten seçeneği işaretlememiz gerekmektedir.
Restore işlemi bittikten sonra da mount etmesini seçebiliriz yada restore işleminden sonra manuel olarak aşağıdaki gibi kendimiz mount edebiliriz
Restore işleminden sonra Recovery Storage Group içindeki Mailbox Store içinde şirketimizin eski datalarını görecebilirsiniz. Üzerlerine gelip Exchange Tasks ile eski yerlerine döndürmemiz mümkün olacak. Mevcut yapıda yeni gelen emailler ile eski bilgiler kaybomadan birleştirilebilecektir.
NOT: Exchange Tasks menusu Exchange Service Pack yüklemeniz durumunda çıkacaktır. Aksi takdirde Exmerge aracı ile bu işlemi yapabileceksiniz.
Buradan bütün mailbox’ları yeni oluşturulan Dial Tone database’e merge ederek eski ve biz bu işlemleri yaparken oluşan yeni bilgileri ile kullanıcılarımıza döndürebiliriz. Fakat burada bazı problemler oluşacaktır. Örneğin Single Instance Storage mantığınca depolanmış bilgilerin her mailbox için ayrı ayrı oluşturulacak olmaları sebebi ile database eski durumundan daha büyük olacaktır. Buna ilave olarak eski database herhalükarda yeni oluşan DialTone database inden büyük olacak. Bu durumda DialTone database i Recovery Storage deki database’e import etmek daha mantıklı olacaktır. Bu sebep ile artı birkaç işlem yapıp dönüş işlemini tamamlayacağız.
Bunun için iki Store’u da unmount (dismount) edeceğiz bu aşamada kullanıcılar işlem yapamayacaklar. Yapacağımız işlem basitçe C:\Program Files\Exchsrvr\MDBDATA içindeki database’leri C:\Program Files\Exchsrvr\Recovery Storage Group içindeki databaseler ile yerlerini değiştirmek olacak. Tabii ki isimlerini de değiştirmemiz gerekecek. Yani örnek olarak ;
C:\Program Files\Exchsrvr\Recovery Storage Group içindeki Mailbox Store (FIKRIDC).edb dosyasını C:\Program Files\Exchsrvr\MDBDATA içine priv1.edb olarak, C:\Program Files\Exchsrvr\Recovery Storage Group içindeki Mailbox Store (FIKRIDC).stm dosyasını C:\Program Files\Exchsrvr\MDBDATA içine priv1.stm olarak taşıyacağız. Öte yandan C:\Program Files\Exchsrvr\MDBDATA içindeki priv1.edb ve priv1.stm dosyalarını da C:\Program Files\Exchsrvr\Recovery Storage Group içine taşıyıp isim değişikliklerini yapmamız gerekecek. Priv1.stm‘i Mailbox Store (FIKRIDC).stm , priv1.edb‘i Mailbox Store (FIKRIDC).edb gibi.
Burada bir önemli husus da iki store’unda özelliklerinden girip Database sekmelerinde “This database can be overwritten by a restore” seçili olması gerekmektedir.
İki mailbox Mailbox Store mount edildikten sonra kullanıcıların eski bilgilerine kavuştuklarını ve kurtarma işlemi sırasında gönderilmiş veya alınmış bilgilerin ise Recovery Storage Group içindeki Mailbox Store içinde olduğunu göreceğiz. Artık istediğimiz mailbox’arı seçerek Exchange Task yardımı ile Merge ederek kullanıcıların mail bütünlüğünü sağlayabileceğiz.
Merge Data seçeneği eski ve yeni bilgilerin bir arada kullanıcının postakutusunda oluşmasını sağlarken Copy Data seçeneği kullanıcının postakutusunda bir klasör içerisinde import edilen bilgileri görmesini sağlayacaktır.
DialTone işleminden sonra OWA kullanıcımızın postakutusuna baktığımızda dikkat edilirse eski ve yeni bilgilerinin de göründüğünü göreceksiniz.
Titiz bir yedekleme sistemi ile disaster recovery gerçekten hayat kurtarıcı bir fonksiyona sahiptir. Test ortamlarında yedeklerin denenmesi alınan yedeklerin test edilmesi sistem yöneticilerinin önemli ev ödevlerindendir.
Hoşçakalın