1. Ana Sayfa
  2. Exchange Server 2007
  3. Exchange Database’inizi Standby Continuous Replication (SCR) ile Yedekleyin! – Bölüm 2 – Restore İşlemi

Exchange Database’inizi Standby Continuous Replication (SCR) ile Yedekleyin! – Bölüm 2 – Restore İşlemi

MVPVarolan mimarinize bir önceki makalede anlatıldığı gibi birden fazla target sunucusu ekleyebilirsiniz. Peki felaket anında merkez lokasyonunuzu kaybettiğinizde target’tan tüm mimarinizi nasıl ayağa kaldıracaksınız. Şekil-1’de görüldüğü gibi varolan cluster tamamen kullanılamaz halde ve tüm resource’lar offline durumda. Makalenin ikinci kısmında böyle bir felaket senaryosunda SCR Target sunucuyu kullanarak tüm yapıyı restore edeceğiz. Dikkat edilmesi gereken noktalar restore işlemi esnasında kullanılacak CMS isminin (MSHowtoMail) aynı şekilde korunması gerekliliğidir. Bunun dışında istenilirse farklı bir IP’yi CMS IP’si olarak atamanız mümkün durumda. Özellikle merkez ofisinizin bu ilk restore işleminden sonra bir şekilde geri yüklenebileceğini düşünüyorsanız CMS IP’sini farklı bir IP vermenizde fayda olacaktır.

SCR
Şekil-1

1. SCR target olan sunucunun recover hale gelmesi için aşağıdaki komutları çalıştıralım. Force parametresini özellikle merkez ofisinizin bu ilk restore işleminden sonra bir şekilde geri yüklenebileceğini düşünüyorsanız kullanmamanızı öneririm.

Dismount-Database “MSHowtoMail \First Storage Group\Mailbox Database”

Dismount-Database “MSHowtoMail \Second Storage Group\Public Folder Database”

Restore-StorageGroupCopy –Identity “MSHowtomail \First Storage Group” –StandbyMachine MSHowto-SCR01 -Force

Restore-StorageGroupCopy –Identity “MSHowtomail \Second Storage Group” –StandbyMachine MSHowto-SCR01 –Force


Şekil-2

2. -StorageGroupCopy komutunun kullanılmadan işlem yapıldığı durumlarda aşağıdaki hata mesajının alınması olasıdır.


Şekil-3

3. Artık Recover işlemine geçebilecek seviye ulaştık, aşağıdaki komutu MSHowto-SCR01 sunucusunda

setup.com /RecoverCMS /CMSName:MShowtomail /CMSIPAddress:192.168.10.33

çalıştırdığınızda aşağıdaki uyarı ile karşılaşabilirsiniz. Bu uyarı ile karşılaşmamak için ise daha önceden Cluster Administrator içerisindeki Resource’ların Owner’larını belirlemeniz gerekecek. Örneğin şu anda MSHowto-MB02 ve MSHowto-MB03’e ulaşılamaz durumda fakat setup bu sunuculara ulaşmayı deniyor. Bunun önüne geçmek için,


Şekil-4

Ulaşılamayan tüm sunucularınızın owner’lıklarını iptal etmelisiniz. İlk durumda aşağıdaki resimdeki gibi olan Resource Owner’lıklarının son halinde, Preferred Owner altında sadece MSHowto-SCR01 isimli sunucu bulunmalıdır.


Şekil-5

4. Son durumda erişilemeyen sunucularınızı Preferred Owners listesinden çıkartmış olmalısınız.


Şekil-6

5. Ve tüm bu uyarı ve hatalardan sonra setup’ı tekrar çalıştırın (IP’yi SCR Source olan merkez lokasyonu bir daha ayağa kaldırmayacağımı düşünerek değiştirmeden kullanıyorum)

setup.com /RecoverCMS /CMSName:MShowtoMail /CMSIPAddress:192.168.10.31


Şekil-7

6. Bu işlemden hemen sonra Cluster Administrator’e baktığınızda aşağıdakine benzer bir görüntü alabilirsiniz. Burada eski SCC’yi barındıran Node’lar manuel olarak Cluster Adminstrator üzerinde evict edilerek temizlenmiştir.


Şekil-8

7. Son olarak Database’leri mount etmek için aşağıdaki komutları kullanın:

Mount-Database –Identity “MSHowtoMail\First Storage Group\Mailbox Database”

Mount-Database –Identity “MSHowtoMail \Second Storage Group\Public Folder Database”


Şekil-9

Bu işlemden hemen sonra Cluster Administrator’e baktığınızda aşağıdakine benzer bir görüntü alabilirsiniz.


Şekil-10

Management Console’da ise aşağıdaki gibi bir görüntü karşınıza gelecektir.


Şekil-11

Not: Makalede bahsi geçen sunucular aynı Cluster Administrator altında aynı Quorum bilgisini okuyarak çalışmaktadırlar. Fakat değişen kurumsal yapılarda, uzak lokasyonlar aynı qourom bilgisini okuyacak şekilde konfigüre edilemeyebilir. Bu tarz dizaynlarda SCR Target’ları farklı Quorum bilgisi okuyacak şekilde yapılandırmalısınız.

Not: SCR Target olacak sunuculardaki Shared Disk alanına atanmış sürücü harfi (makalede T:\) ile SCR Source’daki sürücü harfi aynı olmalıdır.

Not: SCR Source olan sunucularda bulunan database yolu ile SCR Target olan sunuculardaki database yolu aynı olmalıdır.

Not: Bu makalede merkez ofisteki Exchange yapısının bir daha restore edilemeyeceği düşünülerek hareket edilmiştir.

Not: Tüm SCR mimarisinin replikasyon HealtCheck işlemi için Test-ReplicationHealth CMDLet’i kullanılabilir.

Bu konuyla ilgili sorularınızı https://forum.mshowto.org linkini kullanarak ulaşacağınız forum sayfamızda sorabilirsiniz.

Referanslar

Managing Standby Continuous Replication

How to Enable Standby Continuous Replication for an Existing Storage Group

How to Enable Standby Continuous Replication for a New Storage Group

How to Disable Standby Continuous Replication for a Storage Group

How to Prepare for Disk Management Activities when Using SCR

How to Move a Storage Group in a Standby Continuous Replication Environment

How to Move a Database in a Standby Continuous Replication Environment

How to View the Status of Standby Continuous Replication

How to Verify a Standby Continuous Replication Copy

How to Suspend Changes to a Standby Continuous Replication Target

How to Resume Replication to a Standby Continuous Replication Target

How to Seed a Standby Continuous Replication Target

Activating Standby Continuous Replication Targets

Standby Continuous Replication: Site Resilience with Standby Clustering

Standby Continuous Replication: Database Portability

Yorum Yap

Yazar Hakkında

Emre Aydın, Üniversite öncesi tüm öğrenimini İstanbul’da, üniversite öğrenimini ise Kocaeli'nde tamamladı. İşletme Yüksek Lisansını (MBA) Işık Üniversitesinde gerçekleştirmiştir. Üniversite sonrası Metis, Microsoft Türkiye, BilgeAdam gibi bilişim sektörünün farklı firmalarında Çözüm Danışmanı, Birim Müdür Yardımcı ve Birim Müdürü olarak görev almıştır. Son olarak Comparex Türkiye'de Birim Müdürü olarak çalışmış ve sonrasında tekrar Microsoft Türkiye çatısı altında Office 365'ten sorumlu teknik çalışan olmuştur. Uzmanlık alanı olan Microsoft Exchange Server, Office 365, Microsoft EMS, Windows Server ve Microsoft Azure konularında birçok kişi ve firmaya teknik eğitim vermiştir. Özellikle  Türkiye’nin önde gelen firmalarında Mesajlaşma Teknolojileri üzerine başarılı projelere imza atmıştır. Türkiye'nin en büyük ve uzun soluklu bilişim portali olan MSHOWTO’yu 2005 yılında kurmuş, portalin isim ve fikir babası olmuştur. Halen MSHOWTO’da yönetici olarak portalın birçok kişiye ulaşmasında önemli bir görev üstlenmektedir. Microsoft Office 365 alanında MVP olan Emre Aydın, Türkiye’de 11 kez üst üste MVP seçilebilme başarısı gösteren iki MVP’den birisidir. Birçok üniversite, etkinlik ve lansmanda konuşmacı, moderatör olarak yer almıştır. Sahip olduğu bazı sertifikalar: MVP | Office 365 | Since 2006 MCT | Since 2005 MCSD | Azure Solutions Architect MCSE | Private Cloud, Messaging, Communication, Server Infrastructure, Productivity, Platform MCSA | Office 365, Server 2012, Server 2016, Cloud Platform MCTS | Developing Azure Solutions, Implementing Azure Infrastructure, Architecting Microsoft Azure Solutions, SAM P-Seller Intelligent Cloud | EMS Amazon | AWS Certified Solutions Architect - Associate

Yorum Yap