Merhaba arkadaşlar,back-up ile ilgili hazırladığım sunumu ve içeriği ile ilgili bir kaç şey paylaşmak istiyorum.Sonuna kadar okumanızda fayda var,sıkılacağınızı sanmıyorum :).
Yedekleme planı öncesi bir takım şeyleri belirlememiz gerekmektedir.Belirlediğimiz durumlar neticesinde full,diff ve log back-up almak için bir strateji uygulama yönünde adımlar atabiliriz. Veritabanımızın anlık erişilen-güncellenen ve sürekli bir veri giriş-çıkışı sağlanan yapıda olması bizi bir başka soruya iter.Veritabanı üzerindeki tüm tabloların mı yedeklerini alacağız yoksa sadece değişimleri diğerlerine göre çok daha fazla yapıda olan tabloların mı yedeklerini alacağız ?
Bu konuda da bir karar verdiğimize göre yedekleme çeşitlerine bir göz atabiliriz… 3 farklı back-up alma yöntemi bulunmaktadır.
Bunlar ; Full Back-UP : Yedekleme zincirini başlatan olması nedeniyle halkamızın en güçlü kişiliğidir.Ne var ne yok her şeyin yedeğini alır,sistemimiz de ona bir LSN (Log Sequence Number) atar ki bir sonraki Full back-up alımına kadar Diff. Back-up’lar onun peşinden gitsin..
Differential Back-Up : Full Back-up alımından sonraki zamanda gerçekleşmiş değişiklikleri barındırmaktadır.Dolayısıyla Diff. back-up alabilmek için öncesinde bir full yedeğin alınması gerekir.Yedekleme zincirine hiçbir şekilde etkisi yoktur bu arkadaşımızın.Full back-up’ı ona verilen LSN ‘den bulur ve ona göre takip eder.
Transaction Log Back-Up : Bazen o an yaptığımız şeylerden pişman oluruz ve “Allah’ım n’olur zamanı 1 saat geri sar..!” şeklinde dua ederiz.İşte tam bu noktada Microsoft insanların pişman olacağı şeyler yapabilmesini düşünerek böyle bir yedek çeşidi sunmuş.Bu yedek çeşidi bize anlık geri dönüşler sağlar.Her log yedeği alımından sonra varsayılan olarak sanal log dosyaları üzerindeki (“.ldf”) işlenmiş log kayıtları silinir ve log boşaltılmış,rahatlamış olur.Böylece iş çıkışı metrobüs’le karşıya geçmek yerine daha sakin bir zamanda taksiyle karşıya geçerek veritabanımız çok daha hızlı ve konforlu bir yolculukla evine varabilmektedir.
Birde Recovery Model’lerimiz var.Bunlar da yerine göre bazı back-up çeşitlerini önemli hale getiriyor.Aslında hepsi önemli de bu modellerle daha bir havalı oluyorlar.Şimdi de onlara göz atalım.
Simple Recovery Model : Bu modelde iken,veritabanında tutulan log kayıtları checkpoint işleminden sonra silinirler.Dolayısıyla Simple Mod’da iken transaction log’ların büyümesi söz konusu değildir.Geriye dönük log back-up alımı yapılamamaktadır çünkü logların silinmesi yedek alımına olanak vermez ve restore işlemi de yapılamaz.Veri kaybı yaşanma ihtimali çok yüksektir nedeni de en iyi ihtimal ile bir önceki full ya da diff yedeğe dönmeniz gerekecektir.Çok kurcalamamakta fayda vardır.
Full Recovery Model : Yapılan tüm işlemler transaction log dosyasına kaydedilir.Manuel olarak müdahale edilmedikçe de silinmez.Bu model log back-up almaya olanak verir.Şişecek olan log’ları küçültmek için ya log back-up alınır yada shrink işlemi uygulanır.Shrink işlemi için önce recovery modeli tekrar Simple’a alıp gerçekleştirilir.Daha sonra işlem bitince tekrar Full recovery model’e geçilir.
Bulk-Logged Recovery Model : Bu modelde tıpkı Full Rec.Mod. daki gibi tüm işlemleri log’lara kaydeder fakat herhangi bir bulk işlem yapılacağı zaman (insert into,bulk insert,index oluşturma yada silme,rebuild vs.) tüm işlemi tek bir kayıt olarak log dosyalarına yazar.Bu gibi durumlarda veritabanını herhangi bir zamana restore etmek mümkün olmayabilir.Toplu işlem olarak Full Rec.Mod.a göre daha hızlı gerçekleşeceği aşikardır fakat şöyle bir yöntem izlenirse daha faydalı olmaktadır.Eğer bulk işlemi öncesi full recovery’deyken bir transaction log back-up alır,daha sonra bulk-logged recovery’e geçip toplu kaydımızı tamamlar ve tekrar full recovery’e dönersek sektörde yer almış önemli kişileri de memnun eden bir davranış sergilemiş oluruz.
STRATEJİ BELİRLEME
Strateji olarak çoğu kimsenin de öngördüğü şekilde sıkıcı ve istenmeyen bir gün olan Pazartesi’yi Full back-up alım günü ilan ederek eğlenceli hale getirmeye çalıştık.En önemli kısmı bugün halledip geri kalan 6 gün boyunca “En azından full yedeğim duruyor.” rahatlığıyla geçirmemize de olanak sağlayacaktır.Her Diff. yedeği kendisinden önceki Full yedeğini takip ettiğini söylemiştik.Dolayısıyla Salı günü aldığımız Diff yedeği ile Pazar günü alınan Diff yedeklerinin boyutlarının farkı da büyük olacaktır. Yedekleme zincirinden bahsetmişken,oldu ki planımız dahilinde olmayan bir durumla karşılaştık ve bize “Çay koy!” der gibi full back-up almamızı söylediler.Yedekleme zincirini kırmamamız ve …
daha sonra alınacak Diff. back-up’ların aynı LSN ile planlı Full back-up ı takip etmesini “copy_only” seçeneğiyle sağlamış oluruz. Şimdilik yazıyı burada sonlandırıyoruz.
Faydalı bir yazı olduğunu umarak herkese iyi çalışmalar diliyorum…
{ } Veritabanı & Yazılım Geliştirme 