Veritabanı Yedekleme Stratejileri - 1
Bildiğiniz gibi SQL Server 2008 üç temel yedekleme tipi destekler. Bunlar full , differential(fark) ve log yedekleridir. Full yedek veritabanınızın tamamını yedekler ve yedekleme zincirinde kendisinden sonra alınacak differential(değişen) yedekleri etkiler. Differential(fark) yedekler adından da anlaşılacağı gibi fark yedekleridir ve son alınan full yedekten sonraki farklılıkların yedeklenmesini sağlar. Differential(fark) yedeklerinin yedekleme zinciri üzerinde herhangi bir etkisi yoktur. Log yedekleri ise log tutulan veritabanları için tutulan logların yedeklenmesini sağlar. Her log yedeğinden sonra varsayılan olarak sanal log dosyaları üzerindeki işlenmiş log kayıtları silinir ve doğal olarak bir sonraki log yedeği kendinden önceki log yedeğinden sonraki işlenmiş log kayıtlarını barındırır.
Şimdi bu temel bilgiler ışığında yedekleme stratejilerimizi oluştururken nelere dikkat etmemiz gerektiğine bir bakalım. Herşeyden önce bir yedekleme stratejisi kullanılabilir olmalıdır yani herhangi bir ana dönülmesi ihtiyacı duyulduğunda olabildiğince az yedek seti kullanılacak şekilde kurgulanmalıdır. Bunun yanısıra yedekleme stratejilerimizi kurgularken yedekleme zamanının ve depolama maliyetlerinin en düşük seviyelerde olması gerekliliği de düşünülmelidir. Yani her gün full yedek almanının getireceği zaman ve yer maliyetini azaltmak için full yedeklerin arasındaki günlere differential(fark) yedekler yerleştirilebilir. Bir yedekleme stratejisinin en önemli özelliği bütünlüğüdür. Yani her yedek gerektiği zaman dönülebilir olmalı ve yedekleme zincirini bozmamalıdır. Örneğin elimizde yüz adet log yedeğimiz olsun. Onuncu yedek dosyasının bozulması durumunda kendini takip eden doksan yedek dosyası işe yaramaz hale gelecektir. Böyle bir durumla karşılaşmamak için yedek dosyaları arşivlenmeden önce muhakkak doğrulanmalıdır. (restore verifyonly)
Şimdi yukarıda bahsettiklerim doğrultusunda bir örnek yedekleme planı çıkaralım. Yedekleme sürelerinin kısaltılması ve yedek dosyalarının boyutlarının düşürülmesi açısından full ve differential(fark) veritabanı yedekleri aşağıdaki gibi kurgulanabilir.
Bu figürde bahsedilmek istenen Full yedekler haftalık periyotlarda differential (fark) yedekler ise full yedeklerin alınmadığı günler günlük periyotlarda alınabilir. Bu kurguda ikinci gün alınan differential (fark) yedek ile yedinci gün alınan diffrential yedek arasında boyut farkı olacağını unutmamak gerekir. Bunun nedeni her differential (fark) yedeğin en son alınan full yedekten sonra yapılan değişiklikleri içermesidir. Bu durumu görsel olarak ifade etmeye çalışırsak aşağıdaki gibi bir figür ortaya çıkacaktır.
Not : Yukarıdaki örnek figür veritabanındaki günlük değişimin eşit olduğu varsayılarak hazırlanmıştır.
Geri dönüş esnasında ise bir differential(fark) yedek bir full yedeğe bağlıdır. Yani differential(fark) yedeğin dönülebilmesi için ilk olarak full yedek dönülmelidir. Bu durumda yukarıda verilen örnek zaman çizelgesi için ikinci güne geri dönüş esnasında full yedek + ikinci gün differential(fark) yedeği, üçüncü güne geri dönüş esnasında full yedek + üçüncü gün differential (fark) yedeği kullanılmalıdır.
Differential(fark) yedek tanımını düşünürsek plansız aldığımız full yedekler, differential(fark) yedek zincirinin bozulmasına neden olurlar. Aşağıdaki figürde bu durum gösterilmiştir.
Varsayılan yedekleme seçenekleri ile yukarıda belirtilen anda full yedek alınması durumunda beş,altı ve yedinci günlerde alınacak differential(fark) yedekler değişecektir ve geridönme ihtiyacında bu yedeğede ihtiyaç duyulacaktır. Düzensiz zamanlarda full yedek alınması istendiği zaman differential (fark) yedek zincirini bozmamak için COPY_ONLY özelliği ile yedek alınmalıdır. COPY_ONLY özelliği full yedek alırken veritabanı dosyalarının değişim tabanlı log sıra numaralarını değiştirmeyecektir ve yedekleme değişmesine neden olmayacaktır, aynı özellik log yedeği alırken yedeklenen işlenmiş log kayıtlarının silinmemesini sağlar, varsayılan özelliklerle log yedeği alındığı zaman sanal log dosyalarının içindeki işlenmiş log kayıtları silineceğine daha önce değinmiştik.
Şimdi gelelim log yedeklerimiz için nasıl bir yedekleme strajejisi belirlememiz gerektiğine.Düzenli log yedeği almanın yedek almak dışında amaçlarıda vardır. Başlıca nedenlerden birisi log dosyasının gereksiz yere büyümesini engellemektir. Log yedeği alınırken varsayılan özellik logu yedeklenen veritabanının sanal log dosyası içerisindeki işlenmiş log kayıtlarının silinmesidir. Bizlerin veritabını tanımlama esnasında belirlediğimiz log için mevcut olan ldf dosyası aslında birden fazla sanal log dosyasından oluşmaktadır ve bu sanal log dosyaları dolduğunda SQL Server yeni bir sanal log dosyası oluşturur. Bu durum disk seviyesinde log dosyasının büyümesi olarak gerçekleşir. Bu nedenlerden dolayı log yedeklerinin hangi sıklıkla yedekleneceğini belirlemeden önce log kullanımı gözlemlemek gerekir. Bu amaç için DBCC SQLPERF(logspace) komutu kullanılarak log kullanım yüzdeleri incelenebilir.
İyi tasarlanmış bir log yedek stratejisi sonucu log dosyaları büyümemelidir. Eğer ki log dosyası çok sık büyüme eğilimi gösteriyorsa log yedeklerinin frekansları azaltılarak daha sık aralıklarla log yedeği alınması gerekebilir. Bir log yedeğinin içeriğinde kendinden önce alınan log yedeğinden sonra gerçekleşen işlenmiş log işlemleri bulunur. Dolayısıyla istenilen bir ana dönmek için o ana gelene kadarki tüm log yedekleri sırası ile dönülmelidir. Bundan ötürü log yedeklerinin doğrulanarak güvenli ortamlarda saklanması çok önemlidir.
Bu makalemde sizlere üç temel yedekleme tipinden, yedekleme stratejileri kurulurken nelere dikkat edilmesi gerektiğinden bahsetmeye çalıştım. Bir sonraki makalemde backup ve restore işlemlerini ve özelliklerini örneklerle derinlemesine inceliyor olacağız.