Etiketler: , | Kategoriler: Sql Server Emrah Uslu | 06.10.2011 14:17

 

Bu yazı, sql server için yedekleme ve kurtarma konusunda kendim için tuttuğum notlardan oluştuğu ve fazla düzenleme yapmadan burada paylaştığım için yazıdaki dilden dolayı özür dileyerek başlayayım.

Şirketler iş süreçlerinin devamlılığı için veritabanı yönetim sistemleri üzerinde Yüksek Erişilebilirlik (High Availability) çözümleri uygularlar.

  - Failover Cluster
  - Database Mirroring
  - Transaction Log Shipping
  - Replication

Böylece canlı sql sunucusunun bir sebeple taleplere yanıt verememesinin ardından stand by bir sunucu üzerinde iş süreçlerinin devam etmesi sağlanır. Yüksek erişilebilirlik çözümleri datanın online olmasını sağlamasına rağmen iş verisini korumak için bir backup stratejisinin varlığı zorunludur. Mesela geliştirici yada admin kaynaklı veri hatası, aşırı yüklenmeden dolayı veritabanının erişilemez olması gibi durumlarda admin, backup'dan recover ederek db'nin tutarlı bir konuma geçmesini sağlar.

VERİTABANININ BOZULMA SEBEPLERİ

Hardware failure : High availability çözümleri var; ancak bir diskin I/O failure vermesi ve datayı bozması gibi yüksek erişilebilirlik çözümlerinin devreye giremediği durumlar gerçekleşebilir.

User Error : Yanlışlıkla data silmek, delete'e where eklememek, tabloyu drop etmek, test sunucusunda sanıp, canlıda değişiklik yapmak, transaction kullanmamak.

Not : Bazı tool'lar transaction log'ları okuyup istenen transaction'ları restore edebiliyor (Log Explorer, ApexSQL vb.)

Application Failure : Uygulamadaki bir bug

Software Failure : İşletim sistemi çökebilir. Driver'lardan biri bozulabilir.Bundan korunmak için service pack ve patch'leri takip etmek ve kurmak gerekir. Bu sql yada makineyi restart etmeyi gerektirebilir ancak high availablility çözümünün devreye girmesindense planlanmış kısa bir bakım tercih edilebilir. Desteklenen ve güncellenmiş driver'lar makinenin ve dolayısıyla makine üzerinde çalışan uygulamaların performansını artırır.

Haddinden Fazla Yetki : Sql server login'lerini kullanan uygulamalar ve kişiler, olması gerkenden daha fazla yetkiye sahip olabilirler. Mesela dbowner, sysadmin vb. gibi yetkilerle bug veya free-form sorgu ekranında yanlış tablo silinebilir. DBA'ler de normal kullanıcı ve sysadmin kullanıcısını ayrı ayrı kullanırlarsa onlar da "ahh, yanlış sorguyu yanlış yerde çalıştırdım" dan sakınmış olurlar.

Lokal Felaket : Data Center'ın zarar görmesine sebep olacak deprem, sel vb. felaketler için farklı coğrafyalarda yüksek erişilebilirlik çözümleri ve backup merkezleri olmalıdır. Bütün bu durumlar için kurumsal bir plan yapilmalıdır :

  - High Availability (Yüksek erişilebilirlik)
  - Backup/Restore (Yedekleme/Geri Yükleme)
  - Disaster recovery (Felaket Kurtarma)

Bu planları hayata geçirmek için risk/fayda analizi yapmak lazım. Downtime süresi ve bize potansiyel maliyeti, gerçekleşen olayla ilgili bize diğer potansiyel maliyetleri, üretilecek çözümün bize maliyeti hesaba katılmalıdır. Bunun için riskler, maliyet ve faydalar için araştırma ve ardından dokümantasyon yapılmalıdır. Burada risk yönetiminin karar vericisi DBA (veritabanı yöneticisi) değildir, şirketin yönetimidir. Ardından DBA, oluşturulan planı hayata geçirmeli ve düzenli aralıklarla test etmelidir.

 

BACKUP / RECOVERY PLAN

1. İş Gereksinimlerini Analiz Et

  • Her uygulamanın ve veritabanının sahibi kim
  • Bu veritabanının amacı ne
  • Bu uygulama / veritabanı için kabul edilebilir downtime nedir
  • Değişen veriler hangileridir ve ne sıklıkla değişirler
  • Ne kadarlık bir veri kaybı kabul edilebilir (Bu zamanla değişebilir, o yüzden backup plan ve stratejileri zamanla güncellenmelidir)
  • Veritabanının boyutu ve büyümesi nedir
  • Bu veritabanı için Maintenance Window nedir? (index, dbcc, backup, sistemin online response'unu etkileyebilir. Bunların zamanlarını kontrol et)
  • Bu veritabanı için belli bir bütçe var mı?
  • Bir veritabanı hatası gerçekleştiğinde kimin haberi olacak, nasıl haberi olacak 

 

2. Veritabanlarını Kurtarma Kriterlerine Göre Kategorize Et

Kritiklik : mission-critical (article, statistic, sales tabloları gibi)

Size : Büyük veritabanlarının, küçüklere göre backup ve restore süreleri daha uzun olacaktır. Bu süre filegroup backup'ı ve diğer yöntemlerle azaltılabilir.

Volatility : Büyük miktarda veri değişimi alan veritabanlarının, aktif olmayan veritabanlarına göre farklı bir plana ihtiyaçları vardır.

Bu 3 kritere göre hangi veritabanının, hangi kategoriye gireceğine karar verilir; ardından planlar bu gruplara göre yapılabilir.

 

3. Kategorilere İsim Ver

 Aşağıdakilere benzer, faydalı olabilecek şekilde gruplar isimlendilir.

  • Mission Critical with High Acticity (Yüksek aktiviteli iş kritik)
  • Mission Critical with Low Acticity (Düşük aktiviteli iş kritik)
  • Non-Critical  (Kritik olmayan)  

 

4. Her kategori için aşağıdakilere karar vermek gerekiyor

 a) Recovery Modeli

  • Veri kaybını minimize et (FULL)
  • Bulk load işlemlerinin performansını artır (BULK-LOGGED)
  • Bakım maliyetlerini düşür (SIMPLE)

 b) Backup Planı

Her bir kategoriye giren veritabanı için full backup, belirli periyotlarla alınacaktır. Bunun dışında aşağıdaki kriterler göz önünde bulundurularak diğer yedekleme alternatifleri plana dahil edilmelidir.

  • Belirlenen kategori ve recovery modeline göre
  • İhtiyaç duyulan backup sıklığına göre
  • Backup Güvenlik politikasına göre

 

5. Dokümantasyon yapmak lazım

 Şu ana kadar 2 tane dokümantasyonun hazırlanmış olması gerekiyor.

  • Biri iş gereksinimleri için insanlarla yapılan görüşmelerden ortaya çıkan liste
  • İkincisi ise veritabanı kategorizasyonu ile ilgili olan liste.

Bu 2 doküman haricinde şunların da dokümante edilmesi gerekir :

i) Contact List

Acil durumlarda kimler aranacak, onları kim arayacak, bunların telefon numaraları, mail adresleri, ev adresleri vb. Aynı zamanda ihtiyaç halinde vendor, teknisyen, ulaşım hizmet verenler vb. iletişim bilgileri bulunsa iyi olur.

ii) Karar Ağacı

Hangi durumda ne yapılacağını sırayla ve mantıklı bir şekilde anlatan bir doküman. Stres halindeyken yardımcı olması amacıyla kullanılır.

iii) Recovery'nin Başarılı Kriterleri

Veritabanlarına göre geri dönüşün başarılı olduğundan emin olmak için kullanılır.

iv) Key'ler, backup'lar, yazılım ve donanımların lokasyonu

Makinelerin ip'leri, şifreler, otomatik backup'ların nereye alındığı vb.

v) Infrastructure Dokümantasyonu

İsimlendirme düzeni, dns/network bilgileri vb.

 

6. Planı Onaylamak, Uygulamak ve Test Etmek

Belki işin en zor kısmı budur. Planı hazırlamak yetmez. Çalışmayan bir plan işe yaramayacaktır.

 

7. Backup Hata Alırsa Bundan Haberdar Olun

Düzenli backup alma sürecinin başarılı bir şekilde devam ettiğini, alınan backup'ların kullanılır olduğunu garanti etmek gereklidir.  Eğer süreçte bir hata varsa bundan haberdar olunması gerekir.

Ayrıca dikkat edilmesi gereken bir diğer konu şudur : Db backup işlemi, diğer bakım işlemlerinden sonra alınmalıdır. Index, db shrinking gibi. 

 

Bu serinin sonraki yazılarına aşağıdaki linklerden ulaşabilirsiniz.

Backup Restore Planlaması - II

Backup Restore Planlaması - III

 

Kaynak : Wrox SQL Server 2008 Administration, MSDN

 

Yorum ekle

biuquote
  • Yorum
  • Canlı önizleme
Loading