fbpx
Anasayfa » Data Protection Manager 2010 ile SQL Verilerinin Orjinal Instance Geri Dönülmesi

Makaleyi Paylaş

Microsoft System Center Yönetim Ailesi

Data Protection Manager 2010 ile SQL Verilerinin Orjinal Instance Geri Dönülmesi


Daha önceki makalelerimizde Sistem Center Yönetim ailesi içinde barınan Data Protection manager 2010 yazılımı ile mevcut Sql 2005 sunucumuzun veri tabanını koruma altına almışdık. Bu makalemiz içinde DPM 2010 yazılımı ile almış olduğumuz SQL veri tabanımızın geri dönüş işlemini gerçekleştireceğiz. Makale içinde gerçekleştirecek olduğumuz senaryo, koruma altına alınan SQL serverimiz üzerindeki database’ sinin (OnePoint) bozulması ve bunun neticesinde databaseye bağlı servislerin çalışmaz duruma gelmesini ele alacağız.



image001


Öncelikli olarak koruma altına alınan SQL sunucumuz için oluşturmuş olduğumuz koruma grubunu inceliyoruz.



Oluşturmuş olduğumuz Sql Protection Grubu incelediğimiz zaman Latest recovery point bölümünde en son almış olduğumuz full express backup’ ı yani son geri dönüşüm noktasını görebilmekteyiz.Oldest recovery point bölümündeyse koruma grubunu ilk oluşturmuş olduğumuz zaman alınan ilk geri dönüşüm noktasını görebilmekteyiz.



Total recovery points bölümüne baktığımız zaman grubu oluşturmuş olduğumuz zaman dilimi ile en son almış olduğumuz geri dönüşüm noktası arasında toplam alınan geri dönüşüm noktalarının sayısını görebilmekteyiz.  Özet olarak Koruma grubumuz başarılı bir şekilde çalışmaktadır.

Sponsor



image002


Koruma grubumuz üzerinde bulunan her bir Database’ yi seçtiğimiz zaman Details bölümünde Replica path bölümü çıkacaktır. Bu bölüm karşısında Click to view details linkini tıkladığımız zaman yedeklenen databasenin, Dpm Storage Pool (yedek disk havuzu) üzerinde barınan Mdf ve Ldf Sql verilerini görebilmekteyiz. Bu yol varsayılan değer olarak (yapılandırmanıza göre özeldir) aşağıdaki adreste yer almaktadır.




C:\Program Files\Microsoft DPM\DPM\Volumes\Replica\SqlServerWriter\vol_a4f46cf9-638b-4c1e-a815-c6d5095eceae\97d30376-685b-4434-a857-f771c9bf1e9c\Full\c-Vol\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data




image003




Data Protection Manager 2010 yazılımı üzerindeki kontrollerimizde herhangi bir problemimiz bulunmamaktadır.



Koruma altına almış olduğumuz SQL Serverimiz üzerinde SQL Server Management Studio yönetim panelini açtığımız zaman, koruma altındaki instance altında her bir Database’ nin özelliklerine girdiğimizde,General sekmesinde Databasemiz için bir çok bilgiyi görebilmekteyiz. Bu bilgiler içinde Backup bilgileride yer almakta olup Last Database Backup satırı içinde en sonra alınan yedek zamanı hakkında bilgi görebiliyoruz.




image004




Aynı bölüm altında Files sekmesine gittiğimiz zaman Databasemizin sahip olmuş olduğu mdf ve ldf uzantısındaki SQL verilerinin, SQL sunucumuz üzerinde barınmış olduğu veri isimlerini görebiliyoruz, verilerin güncel boyutlarını öğrenebiliyoruz.




image005




Files bölümünde öğrenmiş olduğumuz bilgilere baktığımıza zaman, SQL verilerimizin Sunucumuz üzerindeki locasyonuna gidiyoruz. Evet. Bu bölümde SQL Server Management Studio’ nun vermiş olduğu bilgilerin doğruluğu görülmektedir.


OnePoint ismindeki databasemizin sahip olmuş olduğu bütün veriler, belirtilen lokasyon içinde yer almaktadır.




image006




Koruma altınan Alınan Sunucumuz, Microsoft Forefront Güvenlik Ürün ailesi içinde yer alan FCS Managment Console Sunucumuzun, Collection Rolüne sahip olan bir sunucusudur. Collection sunucusu OnePoint Databasesine sahiptir. Bu database içinde network içinde barınan bilgisayar ve son kullanıcı bilgisayarlarımızın güvenlik bilgileri yer almaktadır.



Forefornt Client Securty Managment Consolemizi açtığımız zaman yönetim paneli içinde görememiz gerekli olan verilerin No data available olarak görüldüğünü ve verilere ulaşılamadığını görebilmekteyiz.




image007




Reporting serverisimiz üzerinde raporlara ulaşmaya çalıştığımız zaman, benzer başka bir hata ile karşılaşmaktayız.




Incelemelerimiz sonrasında sahip olduğumuz SQL veri tabanı bozulmuş olduğunu anlıyoruz.Gerçekleştirmiş olduğumuz bakım-onarım çalışmaları cevap vermediği için DPM2010 yazılımı ile almış olduğumuz yedekten geri dönüş işlemini gerçekleştireceğiz.




image008




DPM 2010 Administrator Console yönetim arayüzünde Recovery Sekmesine geçiş yaptığımız zaman Sol tarafta Browse bölümünü seçiyoruz.  Recoverable Data bölümü altında domain bilgimiz (inter.comp) görülmekte olup bu bölümü genişlettiğimiz zaman koruma altında bulunan sunucu/bilgisayarları görebilmekteyiz.




Koruma altında bulunan SQL sunucumuzu (2008Odysseus) seçtiğimiz zaman SQL sunucumuzun korunan veritabanını, databaselerini görebilmekteyiz. All Protected SQL Instance bölümünü genişletip, geri dönüş yapacak olduğumuz OnePoint Veri tabanımızı seçiyoruz.  Sağ tarafta takvim görüntüsü altında recovery Point yani geri dönüş noktalarını görebilmekteyiz. Geri dönüş gerçekleştirebileceğimiz zaman dilimleri takvim içinde koyu olarak görülmektedir. Geri dönüş gerçekleştireceğimiz tarihimizi seçip sağ tuş Recovery butonuna basyoruz.




image009




Recovery butonuna bastıktan sonra Recovery Wizard bizleri karşılıyor. Seçmiş olduğumuz Recovery noktası hakkında bizlere bilgiler verilmektedir. Bu bilgiler içinde Geri Dönüşü Gerçekleştirecek olduğumuz tarih, geri dönecek olduğumuz veri tabanı boyutu, geri dönüşün yapılacak olduğu yedek veri tabanının kaynak sunucu bilgileri vb.. bir çok veriyi görebilmekteyiz. Bu bilgiler ihtiyacımızı karşılıyor ve ilerliyoruz.




image010




Select Recovery Type bölümünde Recovery to Original instance of SQL Server (Overwrite database)seçimini gerçekleştiriyoruz. Bu seçim haricinde kalan diğer iki geri dönüş amacımızı farklı makalelerde detaylı olarak inceleyeceğiz.




image011




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 geri dönüş süresi boyunca kullanım dışında kalıyor ve hizmet kesintisi olmaktadır. Geri dönüş işlemi tamamlandıktan sonra geri dönülen database işlem sonrasında hizmet etmeye devam etmektedir. Yedek verileri arasında bulunan mdf ve ldf dosyaları bire bir geri dönülüyor.




image012


Leave database non-operational but able to restore additional transaction logs bölümü yapımız içinde aktif duruma gelmiyor. Bu bölümün aktif olabilmesi içinSQL Mirror teknolojisi olması gerekmektedir. İkinci seçenekteki kazancımız neredeyse sıfır veri kaybıdır. Bu özelliğin çalışma mekanizması;



Transaction Log backup larının içinde uncommitted transaction verileride bulunmaktadır. Bizler ikinci seçimi gerçekleştirip bir geri yükleme işlemini başlattığımız zaman geri dönüş işlemi Aktif SQL sunucusu üzerine yapılacaktır. Aktif SQL sunucusu üzerinde bulunan ve geri dönüşü gerçekleştirilen Database restoring durumunda bekleyecektir. Bizler Aktif SQL sunucumuz üzerine geri dönüş işlemini gerçekleştirirken  diğer tarafta Pasif Sql sunucumuz hizmet etmeye devam edecektir.



Aktif SQL sunucusunun restoring olarak beklemesindeki amaç Transaction Log backuplarının haricinde elimizde uncommitted transaction verilerinin bulunmasıdır ve restore işlemi bittikten sonra başka verileride geri döneceğimiz bilgisini veriyorum. Böylelikle geri yükleme işlemi bittikten sonra database çalışır duruma gelmiyor bizlerin uncommitted transaction verilerinin  geri dönmemiz için hazır durumda bekliyor. Bu işlemleri gerçekleştirilene kadar Pasif SQL sunucumuz hizmet etmeye devam ediyor.



Geri dönüş işlemi tamamlandıktan sonra Pasif SQL sunucusu üzerinde barınan yeni verileri yani uncommitted transaction verilerini geri dönüşü yaptığımız SQL sunucumuz üzerine geri dönüyor ve sıfır veri kaybı ile işlemleri tamamlıyoruz. Uncommitted transaction verilerini geri döndükten sonra yapımızda Aktif SQL sunucusu olarak hizmet eden ve geri dönüş işlemini gerçekleştirmiş olduğumuz SQL sunucumuz üzerinden tekrardan çalışmaya devam ediyoruz.




 


image013




Network Bandwidth Usage Throttlingbölümünün disable olarak görülmektedir. İsteğe bağlı olarak geri dönüşü network üzerinden gerçekleştirirken verilerin mevcut network bant genişliğinin belirli miktarını kullanmasını ve SQL sunucusu üzerinde bir yavaşlama olmamasını sağlatabiliriz. bu yapılandırmada verecek olduğumuz değerler geri dönüş işleminin uzun sürmesine neden oalcaktır. Tavsiyem bu işlemi bir hata durumunda gerçekleştireceğiniz zaman disable olarak kalmasıdır.


San Recovery bölümünü donanımsal bir SAN cihazımız, storagemiz varsa eğer hardware snapshoot kullanılarak SAN tabanlı geri dönüşün yapılmasını gerçekleştirebiliriz. Senaryomuzda  Bu teknolojiye sahip olmadığım için bu bölümü doldurmuyorum.




image014




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.




image015




Recovery Status bölümünde geri dönüş işlemini izleyebilir veya close butonu ile görülmemesini sağlatabiliriz. Close butonu ile sihirbazı kapatıyorum ve DPM sunucumuzun arka tarafta geri dönüşü yapmasını sağlatıyorum. Bu işlem DPM sunucumuz üzerinde kaynak kullanımını düşürecektir.




image016




Geri dönüş işlemi sırasında SQL Server Management Studio consolunu açtığım zaman geri dönüşü gerçekleştirmiş olduğumuz Database’ nin Restoring olarak görüldüğünü görebilmekteyiz. Geri ükleme işlemi sırasında Databasemiz kullanım dışıdır.


Eğer Leave database non-operational but able to restore additional transaction logs bölümünü seçmiş olsaydık Databasemiz bu şekilde kalacaktı!




image017




Geri dönüş işlemi başarılı bir şekilde tamamlandıktan sonra Monitoring sekmesi üzerinden geri dönüş işlemi hakkında bilgi edinebiliriz. Bu bilgiye görebilmek için monitoring sekmesi altında Jobs bölümüne geçiyoruz.  Filtremiz içinde Group by Status Filter names bölümüneyse Today’s job bilgisini veriyorum ve Completed görevler bölümünde tamamlanan işlemlerden geri dönüş görevini seçiyorum. Geri dönüş işleminde herhangi bir problem oluşmadığını ve geri dönüş işleminin başlama zamanı ile bitiş –zamanını görebilmekteyiz.




image018




Geri dönüş işlemi tamamlandıktan sonra SQL Server Management Studio consolunda geri dönüşü tamamlanan Databasenin tekrardan aktif bir şekilde çalıştığını görebilmekteyiz.


Leave database operational seçimini yaptığımız için Databasenin geri dönüş sonrasında aktif-çalışır durumda tekrardan hizmet ettiğini görebiliyoruz.




image019


İşlemler tamamlandıktan sonra SQL veri tabanını kullanmakta olan Forefront CSMC üzerinde sahip olduğumuz bilgilerin çalıştığını görebilmekteyiz.




image020


Aynı şekilde Reporting Server üzerindeki raporlarımızın başarılı bir şekilde görülebilmektedir.




image021


Geri dönüş işlemi başarılı bir şekilde tamamlandıktan sonra koruma grubumuz için Perform consistency check işlemini çalıştırana kadar geri dönüşü yapmış olduğumuz database için yeni yedekler alınamayacaktır. Geri dönüş işlemi tamamlandıktan sonra, yapmış olduğumuz geri dönüş işlemi ve database üzerindeki değişikliklerin algılanabilmesi için ilgili koruma grubu üzerinde Perform consistency check işlemini çalıştırıyoruz.


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

Makaleyi Paylaş

Cevap bırakın