SQL Server’da Backup Stratejileri-1 Full Backup ve Differential Backup

Merhaba

Bu yazımızda SQL Server’da backup alma yöntemlerinden, aralarındaki farklardan ve hangi senaryo için hangisinin uygun olduğundan bahsediyor olacağım. İnşallah birkaç yazılık bir seri halinde yayınlamayı düşünüyorum.

Aslında SQL Server’da backup teknolojileri çok uzunca zamandır aynı olmasına karşın bir çok kişinin bu sistemin yetenek ve avantajlarından haberdar olmadığını düşünerek böyle bir yazı yazmaya karar verdim.

Genel olarak yapılan yanlışlar şöyle;

1-Günde 1 kez Veeam tarzı uygulamalar ile sanal sunucunun tamamının yedeğini almak.

Bu aslında kötü bir şey değil ancak sıkıntı şurada sizin bir felaket anında 1 günlük kaybınız oluşmakta. Sistemi kurgularken yeterli gibi görünse de sıkıntı yaşandığında akşama kadar girilen fatura, sipariş, irsaliye gibi bir çok işlem için ciddi kaybınız oluyor.

2-Transaction log backup alınmadığı halde database recovery model’i full modda tutmak.

Bu durum yapılan her işlemin transaction log dosyasına yazılması sebebi ile hem sistemi yavaşlatan hem de transaction log dosyasını çok şişiren bir durumdur.

3-SQL Backup’ın sıkıştırma özelliğini kullanmadan yedek almak

SQL ile doğrudan yedek aldığınızda sıkıştırma özelliğini kullanırsanız örnek erp,crm,ik gibi sistemlerin veritabanlarında %90 lara varan sıkıştırma elde edersiniz. Bu durum size hem bu oranda yer kazancı sağlar, hem yedek alma süreniz bu oranda kısalır hem de kazandığınız süre ve yer ile daha fazla yedek alabilirsiniz.

4-Günde 1’den fazla yedek almanın daha fazla yer ihtiyacı doğurduğunu düşünmek.

Bu durum doğru değildir. Zira siz differential backup, tlog backup gibi yöntemleri kullanrak sadece değişen veriyi yedekleyebilirsiniz.

 Şimdi bu yanlışları anlattıktan sonra konumuza dönelim.

Temel anlamda SQL Server’da 3 türlü backup yöntemi var.

1-Full Backup

2-Differential Backup

3-Transaction Log Backup

Full Backup: Adı üstünde sistemde bir database’in yedeğinin tamamen alınması işlemidir. Sistem çalışırken online olarak yapılabilir. Senaryoya göre değişir ancak günde en az 1 kere alınması tavsiye ettiğimiz bir yapıdır.

Full backup, yedek alındığı saatteki veriyi içerir.

Örnek senaryo

Mesai 18:00’da bitiyor. Full yedeğinizi gece saat 03:00’da alıyorsunuz.

Ertesi gün öğleden sonra 16:30’da veriniz silindi.

Bir önceki gün 03:00’daki veriye dönebilirsiniz. Yani 1 gününüz kayıp.

Çözüm olarak full backup sayısı arttırılıp zamanı düzenlenebilir. Örneğin her gün öğlen 12:00 mesai bitiminden sonra 18:00’da yedek alıyor olursam akşam ölü zaman için yedek almama gerek kalmaz.

Yani sabah 10:00’da yaşanacak bir kayıp için bir önceki gün 18:00’da alınan yedeğe dönersem sadece 2 saatlik bir kaybım olur. Yine 16:30’daki bir veri kaybında aynı gün öğle 12:00’daki yedeğe dönerim ve kaybım 4 buçuk saat olur.

Tabi bunlar 3-4 saati tolere edebilecek firmalar için uygulanabilecek yöntemler.

Differential Backup:

Diyelim ki sizin en fazla yarım saatlik bir kayıba tahammülünüz var. O zaman farklı yöntemler denemek gerekiyor. Öyle ya, her yarım saatte bir full backup almak mantıklı değil.

İşte bu noktada differential backup dediğimiz yöntem ortaya çıkıyor. Adı üstünde fark yedeği. Peki neyin farkı?

Burada dikkat edilecek cümle;

En son alınan full backup ile differential backup alınan zaman arasındaki fark.

Anlatayım.

Şimdi senaryomuz şöyle olsun.

Elimizde 50 GB’lık Verimiz her 1 saatte 100 MB büyüyor. Her yarım saatte 50 MB eder.

Yani bir günün sonunda 50+24*0,1GB=52,4 yaklaşık 52.5 GB veri eder.

Biz bunu

• Günde 1 full yedek alsak 50 GB
• Günde 2 full yedek alsak 101 GB
• Günde 3 full yedek alsak 153 GB
• Günde 4 full yedek alsak 204 GB
• Günde 5 full yedek alsak 255 GB
• Günde 6 full yedek alsak 306 GB yer kaplar.

Günde 6 full yedek alsak bile 4 saatlik riskimiz var. Bu yedeği de 10 gün saklayacağımızı düşünürsek bu da en az 3-4 TB lık alan ihtiyacı demek ve unutmayalım bu kadar yatırıma rağmen riskimiz hala 4 saat.

Aşağıdaki resimlerde farklı full backup stratejilerinin riski, sisteme getirdiği yük ve yer ihtiyacı görüntüleniyor.

Sistemin yedek alırken yorulması ve bunun mesai saatleri içerisinde yapılması da cabası. Riski azaltmak adına günde 1 kere almaktan iyidir deyip kendimizi avutabiliriz.

Ya da başka bir yöntem deneyebiliriz.:)

Senaryomuza geri dönelim.

Ben günde 1 full yedek alsam 50 GB Full yedek tutar. Örneğin bunu sabah 06:00’da alayım.

Sonra her 1 saatte 1 differential yedek alayım.

Aşağıdaki tablo karşımıza çıkıyor.

Görüldüğü gibi 1 günlük differential backup 27,5 GB lık yer kaplıyor ve kaybımız sadece 1 saat. Burada differential backup’ın full backup olmadan hiçbir işe yaramadığını tekrar belirtmek gerekir ve differential backup kendinen önceki full backup ile olan farkı alır.

Yani burada bizim aldığımız her differential backup sabah saat 06:00 ile olan farktır. Burası çok karıştırıldığı için tekrar etmek istedim. O yüzden 06:30’daki differential backup 100 MB iken ertesi gün 05:00’daki differential backup 2,3 GB.

Günde 1 full backup ve saatte 1 differential backup kullanarak alınan yedek stratejisinde

Riski 1 saate indirdik

Sistemi yedek alma sebebiyle yorma 1/5 oranına düştü

10 günlük yedek için yine yaklaşık 4 kat tasarruf ettik.

Şimdi aynı çalışmayı yarım saatlik risk için yapalım. Yani günde bir full backup, yarım saatte bir differential backup alalım.

Görüldüğü gibi riskimizi yarım saate kadar indirdik ve günlük 106 GB gibi bir veriyle bu işi gerçekleştirebildik.

Yalnız burada şöyle bir risk var. Elimizde sadece 1 adet full yedek var. Bu dosyanın başına bir iş gelirse bu kadar differential hiçbir işe yaramaz. O zaman onun sayısını da  çoğaltalım. Örneğin günde iki kez full yapalım. Sabah saat 06:00 ve akşam 18:00’da.

Şimdi full backup biraz büyüse de differential backup da küçüldü. Çünkü akşam 18:00’dan sonra fark sıfırlandı.

Burada senaryolar arttırılabilir. Hesaplama mantığı genel olarak bu şekilde. Differential backup ve full backup için database in recovery modelinin full modda olmasına gerek yok. Böylece her şey transaction log dosyasında kalmadığı için sistemin gereksiz şişmesi ve fazladan okuma yazma yapmasının önüne de geçmiş olursunuz.

Eğer sizin için veri kaybı 20 dakika, yarım saat gibi değerler tolere edilebilir değerler ise differential +full backup ikilisini gönül rahatlığı ile kullanabilirsiniz.

Genel olarak benim önerdiğim yedekleme stratejisi Günde 3-4 full ve yarım saatte bir differential şeklinde. Ama artık bu makaleden sonra kendiniz de en doğrusuna karar verebilirsiniz.

Burada dikkat edilmesi gereken konu şu. Index bakımı yaparken differential yedek almayın ve index bakımı bittikten sonra hemen bir full yedek alın ki differential yedekleriniz full yedek boyutuna ulaşmasın.:) Zira indexleme işlemi database i baştan yapmış kadar değişiklik içerdiğinden differential dediğimiz fark da database boyutuna ulaşmış olur. İlerleyen yazılarda bundan da bahsediyor olacağım.

Dediğim gibi bu yedekleme stratejileri ile alakalı bir seri yazmayı planlıyorum. Sonraki yazılarda Trasanction Log Backup,

Yedekten dönme senaryoları

Maintanance Plan Oluşturma gibi konuları da inşallah anlatıyor olacağım.

Makalemin bir sonraki bölümü için;

SQL Server’da Backup Stratejileri-2 Full Backup ve Backup Compression