Anasayfa > System Center > DPM 2012 SQL SERVER YEDEKLEME ve GERİ YÜKLEME

DPM 2012 SQL SERVER YEDEKLEME ve GERİ YÜKLEME

Dpm makale serimizde https://rizasahan.wordpress.com/2011/12/03/dpm-2012-disk-ekleme-agent-ekleme-protection-group-tanimlama-ve-dosya-bazli-yedek-alma/ makalemizde temel işlemler olan disk ekleme, agent ekleme, protection group tanımla ve dosya bazlı yedekleme geri yükleme işlemlerini anlatmıştık. Bu makalemizde sql  server yedekleme işlemlerini ele alacağız.

Yedekleme işlemine başlamak için öncelikle yedekleme yapılacak olan Sql serverimize agent yüklemesi yapmamız ve protection groyp oluşturmamız gerekli. Sql serverimize agent kurmak için “management” tabında “egent” sekmesine tıklatarak üstte aktif olan “install” butonuna tıklayarak işlemimizi başlatalım. Bu ekranımızda install agent seçeneği ile domainizde bulunan bir bilgisayara agent kurulumu yapabiliriz. Attach Agent seçeneğinde ise trust bir domain veya workgroup ortamındaki bir bilgisayara agent kurulumu yapabiliriz. Biz domaine join olan SQL servere agent kuracağımız için “install agents” seçeneğini seçerek Next butonu ile ilerliyoruz.

Karşımıza gelen ekran agent kurulacak olan makinemiz listeleniyor ise seçip karşı tarafa geçirebilir veya netbios ismini girerek eklenecek olan bilgisayarımızı buldurup ekleme işlemini yapabiliriz.

Agent kurulacak bilgisayarlar listesine SQL serverimizi ekledik. Next  butonuna tıklayarak ilerleyelim.

Gerekli Authencation bilgilerini girerek Next butonu ile ilerleyelim.

Agent kurulum sonrası Restart edilip edilmeyeceğine karar vererek Next butonu ile ilerleyelim. Ben Restart yapılmaması gerektiğini belirterek seçimimi yapıp ilerliyorum.

Gerekli işlemler tamamlandı Install butonu ile kurulumu başlatalım. Karşı tarafta kurulumda sorun olmaması için firewall devre dışı bırakılabilir veya gerekli portlar açılabilir.

Kurulum işlemi başladı.

Kurulum işlemi tamamladı.

Agent ekranımıza baktığımızda SQL serverin başarılı bir şekilde geldiği görüyoruz.

Sql makinamızı agent kurulumu yaparak Dpm servere tanıttıktan sonra şimdi sıra bir protection grup oluşturma aşamasına geldi. Bu işlem için “Protection” tabına tıklayarak aktif olan “New” butonuna tıklayalım. Karşımıza gelen karşılama ekranını Next butonu ile geçelim.

Koruma grubuna eklenecek olan bilgisayarın türünü seçmemiz gerekiyor. Biz bir server ekleyeceğimiz için “servers” seçeneğini seçiyoruz. Son kullanıcı için bir koruma grubu oluşturacak olsaydık “clients” seçeneğini seçmemiz gerekecekti.

Karşımıza gelen ekranda Dpm tarafından agent kurulmuş olan bilgisayarlar ve Dpm serverin kendisi listelenmektedir. Biz buradan yedekleme yapacak olduğumuz Sql serverimizi seçiyoruz. Sql üzerinde tüm dbleri koruyabileceğimiz gibi tek bir dbyi ve birden fazla instanca var ise birden fazla insatance korumasınıda yapabiliriz. Sql server üzerinde db koruması yaparken aynı zamanda file bazlı koruma veya all volume gibi bu makine üzerinde birden fazla koruma yapabiliriz.

Yedekleme yapacağımız ortamı seçelim. Bizim ortamımızda sadece disk bulunduğu için disk seçeneğini seçerek ve koruma grubumuza bir isim vererek  Next ile ilerliyoruz. Disk ekleme işlemini yukarıda linkini verdiğimiz makalemizde anlatmıştık.

Burada koruma grubumuzun hangi periyotlarda yedekleneceğini, hangi periyotlarda full yedeğinin alınacağını belirleyebiliriz. Resmimizdeki durumda her 12 saatte incremental yedekleme yapılacağı, akşam ve gündüz 9:00 saatlerinde full yedekleme yapılacağı ve koruma grubunun 5 gün için olması gerektiğini belirledik.

Total data size: Seçilen dataların toplam boyut bilgisi verilmektedir.

Disk Space Allocated in DPM: Bizim seçmiş olduğumuz günde bir kez yapılacak yedekleme için, 5 gün tutulacak olan koruma grubu için ayrılacak disk kapasitesi belirlenir.

Avarage disk space allocated in protected computers: Disk üzerinde 300 Mb bos bir alanın olması gerekmektedir. Bu alan ihtiyacını bizler Modify bölümünden değiştirebiliriz. Fakat değişiklik alanı küçültmek için önerilmemektedir! Alanın boyutunu arttırabiliriz. Bu alan dosya sunucumuz üzerinde koruma altına aldığımız her bir volume üzerinde ayrı ayrı oluşturulacaktır. Korunacak dosya sunucusu üzerinde 300 MB  bir alana ihtiyaç duyulmasının nedeni DPM sunucusu Dosya Sunucusu üzerinde oluşan dosya değişikliklerini, dizin değişikliklerini, NTFS file System değişiklikleri vb. bir çok bilgiyi bu alan üzerine yazdırtacak ve ihtiyaç durumunda buradan okuyacaktır.

Automatically Grows Volumes: Disk boyutu yetersiz geldiği zaman otomatik olarak backup diskimiz üzerinde, boşta bekleyen bölümden ihtiyaç duymuş olduğu alanı kullanacak v büyüme gerçekleştirecektir.

Modify seçeneği ile ayrılmış olan disk kapasitesini aşağıdaki resimdeki gibi değiştirme olanağına sahibiz.

Choose replica creation method:  Oluşturulan koruma grubunun hangi zaman dilimleri içinde çalışması gerektiğini belirliyoruz. Çalışma zamanı olarak kural oluşturulduktan hemen sonra, bizim belirlemiş olduğumuz herhangi bir zaman ve saat dilimi içinde veya manuel başlatılması gerektiğini belirliyoruz. Eğer NOW bölümünü seçip kuralımıza devam edersek, kuralımız oluşturulduktan hemen sonra dosya sunucumuzun data koruması başlayacaktır ve ilk recovery point durumunu (geri yükleme alanını) tam yedek alarak gerçekleştirecektir. Now bölümünü seçip Next butonu ile devam ediyoruz.

Run a consistency check if a replica becomes inconsisten:  Aktif duruma getirmenizi öneriyorum. Bu bölümü aktif duruma getirdiğimiz zaman DPM sunucumuz koruma altında bulunan dosya sunucusuna iletişim kuramadığı zamanlar için geçerlidir. Bu zaman dilimi yedekleme zaman dilimleri ile eşleşirse her bir saatte bir DPM sunucusu dosya sunucumuzu kontrol edecektir ve iletişim sağladığı ilk zaman diliminde görevi tekrardan başlatacaktır.

Run a Daily consistency check according to the fllowing schedule: Bölümünde ise bu zaman diliminin her bir saatte bir kontrol etmesini ama gerçekleştirilmeyen başarısız backup görevinin belirli zaman dilimlerinde olmasını sağlarız.

Yapılan işlemlerin bir özet penceresi karşımıza geldi. “Create Group” butonu ile işlemlerimizi yapalım.

Koruma grubumuzu oluşturmadan disk yapımız aşağıdaki gibidir. Disklerimiz daha önce oluşturulan bir koruma grubu için bölünmüş ve gerekli partitionlar oluşturulmuş durumdadır.

Grubumuz başarılı bir şekilde oluşturuldu.

Koruma grubu oluşturulunca disk yapımız aşağıdaki hale geldi. Sql serverimiz için gerekli koruma grubuna ait partitionlar oluşturularak disk yapısı ayarlandı.

Koruma işleminde gerekli zaman diliminde koruma yapılacak biz grup oluştururken , oluşturma işlemi tamamlanınca ilk replikasyonun yapılması gerektiği şeklinde ayarlama yapmıştık. Şu anda replikasyon başladı.

Replikasyon işlemi başarılı bir şekilde tamamlandı.

Yapılan replikasyondan sonra “recovery point” butonu ile bir kez daha elle replikasyon yapmasını isteyerek seçtiğimiz db nin bir kez daha yedeklenmesini sağlıyorum.

İşem şu anda başladı devam ediyor.

İşlem şu anda tamamlandı.

Yedekleme işlemi tamalandı geri dönüş testini yapmadan önce sql serverimiz üzerinden yedeğini aldığımız dbyi silelim.

Şu anda RIZASAHAN isimli db silindi.

Geri yükleme işlemi için “Recovery” tabına tıkladığımızda birincisi koruma grubundan sonra ilk replikanın yapılması diğeri ise bizim manuel olarak yaptığımız replikasyon sonucunda alınan iki geri yükleme noktasını görüyoruz.

Şimdi geri yükleme işlemlerinebaşlayabiliriz. Bu nedenle”Recover” butonuna tıklayarak yedekleme işlemini başlatalım.

Gelen ekranda geri yükleme noktası, yedeğin nereye alındığı kısacası yedek hakkında bilgiler yer almaktadır. Next butonu ile ilerleyelim.

Bu ekranımızda yedeğin orijinal lokasyona dönülmesi, farklı bir sql instance üzerine dönülmesi, network üzerine dönülmesi, elimizde type olsa type dönme gibi imkanlarımız olacaktı. Biz burada orijinal lokasyona döneceğimiz için ilk ve resimde seçili olan seçeneği seçerek Next ile ilerleyelim.

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.

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.

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.

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.

Geri dönüş işlemi başarı ile tamamlandı.

Şu anda yedeği alınmış olan veritabanı başarılı bir şekilde orijinal lokasyonuna geri yüklendi.

Sql makalemizden sonra Dpm programı ile Hyper-v yedekleme ve geri yükleme işlemi, Exchange yedekleme ve geri yükleme işlemi, Son kullanıcıların yedekleme ve geri yükleme işlemi ve workgroup bilgisayarda yedekleme işlemleri gibi adımlara değineceğiz. Bir başka makalede görüşmek dileğiyle.

Kategoriler:System Center
  1. Henüz yorum yapılmamış.
  1. No trackbacks yet.

Bir Cevap Yazın

Aşağıya bilgilerinizi girin veya oturum açmak için bir simgeye tıklayın:

WordPress.com Logosu

WordPress.com hesabınızı kullanarak yorum yapıyorsunuz. Log Out / Değiştir )

Twitter resmi

Twitter hesabınızı kullanarak yorum yapıyorsunuz. Log Out / Değiştir )

Facebook fotoğrafı

Facebook hesabınızı kullanarak yorum yapıyorsunuz. Log Out / Değiştir )

Google+ fotoğrafı

Google+ hesabınızı kullanarak yorum yapıyorsunuz. Log Out / Değiştir )

Connecting to %s

%d blogcu bunu beğendi: