Anasayfa » Data Protection Manager 2010 ile Korunan Bir Databasenin DPM Self Service Recovery Tool ile Farklı Bir SQL Instance Geri Dönülmesi

Makaleyi Paylaş

Microsoft System Center Yönetim Ailesi

Data Protection Manager 2010 ile Korunan Bir Databasenin DPM Self Service Recovery Tool ile Farklı Bir SQL Instance Geri Dönülmesi

 

Daha önce yayınlamış olduğumuz Data Protection Manager 2010 Üzerinde SQL Server İçin DPM Self Service Recovery Tool Yapılandırılması (Configure self service recovery for SQL Serv) makalemiz içinde sahip olduğumuz SQL Yedek dosyalarımızın geri dönüş politikalarını belirlemiş ve bu geri dönüş politikaları çerçevesinde sahip olduğumuz SQL yedek verilerini  Data Protection Manager 2010 ile Korunan Bir Databasenin DPM Self Service Recovery Tool ile Ağ Yoluna Geri Dönülmesi adlı makalemiz içinde paylaşmıştık.

 

 

image001

 

 

Bu makalemiz içinde DPM Self Service Recovey Tool ile yedeğini almış olduğumuz SQL yedeklerinin Farklı bir SQL sunucusu üzerine geri dönüşünü gerçekleştireceğiz.

Yukarıdaki ekrandan görebileceğiniz üzere Daha önce oluşturmuş olduğumuz kural bu işlem için bizlere cevap vermemektedir.

 

 

image002

 

 

Bu sebepten ötürü daha önce oluşturmuş olduğumuz kuralı Modify butonu ile tekrardan düzenleyebilir veya Create Rol butonuyla bu yeni amacımız için farklı bir rol, görev oluşturabiliriz.

Sponsor

Yeni bir kural oluşturmuyorum ve mevcut OdysseusSQLRecovery görüvimi modify butonu ile düzenliyorum.

 

 

image003

 

 

Bu makaledeki amacım, DPM2010 tarafından koruma altına alınan  w2008scipio sunucumun SQL yedeklerini w2008odysseus sunucumun üzerine geri dönmek. Bu sebepten ötürü scipio sql sunucum üzerinde koruma altına alınan ve odyseus sunucum üzerine geri yüklenmesini istediğim databaselerimi ekliyorum. Eklemiş olduğum yeni databaseler Halojen, halojen2009 ve halojen2010 ismine sahip olan databaselerimdir.

 

 

image004

 

 

Data Protection Manager 2010 Üzerinde SQL Server İçin DPM Self Service Recovery Tool Yapılandırılması (Configure self service recovery for SQL Serv) makalesini inceleyecek olursanız yukarıdaki değişikliği daha net anlamış olacaksınız.

 

 

image005

 

 

Kuralımız üzerinde gerekli değişikliği gerçekleştirdikten sonra işlemlere devam edebiliriz. Görüldüğü gibi Specify Database Details bölümünde, SQL Server Instance Names alanında sadece w2008odysseus sql sunucum gelirken yapmış olduğum değişiklikten sonra w2008scipio sunucumun ve eklemiş olduğum üç yeni databasenin geldiğini görebilmekteyiz. Database name bölümünde, odysseus sunucum üzerine geri dönmek istediğim databaseyi seçtikten sonra  ilerliyorum.

 

 

image006

 

 

DPM2010 sunucum üzerinde recovery point alanında görülen geri dönüş tarihler, DPM Self Service Recovery Toolun Specify Recovery Point alanında bire bir geldiğini görebilmekteyiz. Geri dönüş tarihini seçtikten sonra ilerliyoruz.

 

 

image007

 

 

Specify Recovery Type bölümünde Recover to any instance of SQL Server seçimini gerçekleştirip ilerliyorum.

 

 

image008

 

 

Recovery Alternate Recovery Location bölümünde Database File Location alanında c:\SSRTFolder yazıyorum. Hatırlayacağınız gibi Data Protection Manager 2010 Üzerinde SQL Server İçin DPM Self Service Recovery Tool Yapılandırılması (Configure self service recovery for SQL Serv) makalemizde bu folderin DPM Self Service Recovery tol tarafından geri dönüşler için yapılandırmıştık. Geri dönüş noktasında bu folder hazır durumda olmazsa geri dönüşümüz hata verecektir. DPM Self service recovery aracımız bu dolerin altına geri dönüş tarihini bilgisini oluşturan bir folder oluşturacaktır.

 

 

image009

 

 

Specify the recovery option for recovering the selected database bölümünde Leave database operational seçimini gerçekleştirip devam ediyoruz. Bu seçimi gerçekleştirdiğimiz zaman geri yükleme işlemi başladığı zaman, geri dönülen SQL Databasesi yeni SQL sunucusu üzerinde hizmet etmek için hazır olacaktır.

 

 

image010

 

 

Specify Recovery Options bölümünde geri dönüş sonrasında, DPM sunucumuzun herhangi bir bildirim maili gönderip-göndermemesini ve mail içeriğini oluşturabiliriz. Dikkat ederseniz aynı geri dönüş işlemini DPM2010 sunucumuz üzerinde gerçekleştirdiğimiz zaman Network Bandwidth Usage Throttling bölümüde bulunmaktaydı. DPM Self Service Recovery Tool üzerinde bu bölüm bulunmamaktadır.

 

 

image011

 

 

Summary bölümünde geri dönüş işlemimiz ile ilgili özet bilgi verilmektedir. Bu bölüm altında source (kaynak SQL sunucumuzun veri tabanını) destination (geri dönüş yapılacak olan SQL sunucumuzun veri tabanı bilgilerini), Recovery Point bölümünde geri dönüş yapacak olduğumuz tarihi vb.. sihirbaz içinde belirtmiş olduğumuz bilgileri özet olarak görebilmekteyiz.

Recovery butonu ile geri dönüş işlemine başlıyorum.

 

 

image012

 

 

DPM Self Service Recovery Tool bölümüne baktığımız zaman In Progress olarak işlemin başladığını görebiliyoruz. Bu bölüm altında ne kadarlık verinin ne kadarı geri dönülmüş izleyememekteyiz. Eğer görevin ne kadarı tamamlandı izlemek istersek DPM2010 administrator console yönetim arayüzümüz üzerinde monitoring sekmesini açmamız gerekmektedir. Geri dönüş başarılı bir şekilde tamamlandıktan sonra Completed olarak bildirim görülmekte olup geri dönülen yedek dosyasının boyutunu görebiliyoruz.

 

 

image013

 

 

İşlem tamamlandıktan sonra geri dönüşü yapmış olduğum w2008odysseus sunucusu üzerinde SQL Server Managment Studio yönetim arayüzünü açıyorum. Geri dönüşü yapmış olduğum Halojen databasesi belirtmiş olduğum SQL instance içinde yerini almış durumdadır.

 

 

image014

 

 

Databasenin özelliklerine baktığımız zaman Path bölümünde, geri dönüşün gerçekleştirilmiş olduğu alanın SSRTFolder\DPM_Geri dönüş zamanı altında olduğunu görebilmekteyiz. DPM Self Service Recovery aracı daha önce oluşturmuş olduğumuz klasör altında yeni dosyalar açarak geri dönüşü gerçekleştirmiştir.

 

 

Databasenin ve uygulamalarımızın özelliklerine, ihtiyaçlarına farklı olarak gerekli düzenlemeleri yapıp Testlerimizi gerçekleştirebiliriz.

 

 

image015

 

 

İlgili yolu izlediğimiz zaman yedek dosyamızın sahip olduğu mdf ve ldf uzantısındaki SQL verilerini görebiliyoruz.

 

 

Bu işlemlerin tercih edilme sebebini bir kez daha hatırlatmamız gerekirse Test ortamları için kullanabilir. Sunucu, Sunucu işletim Sistemi Versiyonu, SQL Versiyon değişikliği vb.. değişiklikler gerçekleştirmeden önce, değişiklikleri yaparsak ne gibi sıkıntılar, problemler bizleri bekliyor bunları görebilmek için yapabilmekteyiz. Mevcut yapımızda bir değişiklik olmadığı için geçişi yapmadan önce testlerimizi yapabilir ve planlamış olduğumuz projeyi en az sancıyla atlatabiliriz.

 

 

Fatih KARAALİOĞLU
Çözüm Park Bilişim Portalı Kurucu Üyesi

Makaleyi Paylaş

Cevap bırakın