SQL Server

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.

Sağlıcakla…

İlgili Makaleler

24 Yorum

    1. Anlatmak için değil bir şeyler farkıdalık yaratmak için yazılmış.. süper

  1. Elinize sağlık hocam, full backup dosyaları ile dif backup dosyaları faklı konumda olması dif backup ın son full yedeği algılanmasına sorun yaratmaz değil mi?
    Teşekkürler

  2. çok güzel ve örnekleme ile birbirini tamamlayan bir yazı döktürmüşsünüz devamını büyük bir heyecan ile bekliyoruz emeğinize sağlık bu güzel yazı için teşekkürler

  3. elinize ve emeginize saglik, yine on numaralik calisma olmus.

    Söyle bir sorum olacak, biz Veeam ile hergün incremental backup yapiyoruz (sanal makinenin). Ve Veeam de ayrica Application Aware Processing aktif (truncate log aktif ve transaction loglari kendisi her 15dk bir alabiliyor). Bu yeterlimidir hocam?
    Yani hergün sanal makinen full calisan hali mevcut + her 15dk bir transaction log backup var. Toplam veri kayibi 15dk, dogru mu?

    1. Merhaba
      Her 15 dakikanın tlog bilgisinin olması o 15 dakikada istediğiniz zamana dönebilirsiniz demek. Yani differential backup olsaydı sadece backup ın alındığı zamana gidebilirdiniz. Bu yönden fazlasıyla yeterli ancak database in full modda olması gerekiyor bu işlem için o da performans açısından dezavantaj.

  4. Ömer bey emeğinize sağlık.
    Bir sorum olacak Differential Backup yönteminde ilk önce full backup alıyoruz, Sonra istediğimiz zaman dilimleri içerisinde değişiklikleri yedekliyoruz.

    20Gb bir data full
    18:00 Differential Backup 1Gb
    19:00 Differential Backup 2Gb
    olduğunu varsayalım full alınan backup ve19:00 alınan Differential Backup import için yeterli olacak mıdır yoksa aradaki 18.00 alınan backup doyasını silsem bir sıkıntı olur mu ?
    Şimdiden Teşekkür ederim.

    1. Bir full ve bir differential yeterlidir. Aralardakine gerek yok. Differential backup kendinden önce alınan full backup ile arasındaki farktır. Dolayısıyla saat 18:00 e dönmek için sabah ki full backup+18:00’daki diff backup, 19:00 a dönmek için sabahki full+19:00’daki differential backup yeterlidir.

  5. Merhaba,
    Makale için teşekkürler. Burada şöyle bir şey de yapılabilir mi? Ben her gün 3 Full Backup alıyorum. Ve her ay da bir backup tutuyorum o aya ait. Ancak diğerlerini manuel silmek zorunda kalıyorum.

    5 günlük backup işleminde geçmiş altıncı günü sildirmek mümkün mü? Aynı ay içerisinde bir haftalık backup benim için yeterli oluyor.

    Teşekkürler.

  6. Merhaba,
    Klavyenize saglık

    Bende de bir SQL backup sorunu var.Hergün neredeyse 100 gb yakın backup var ve artık yerim kalmıyor. bu konuda neler önerir siniz.Backup hergun istiyorlar.

  7. Hocam Selamlar, bir DB’mizde en başından beri kullanılmadığı halde Recovery Model Full seçilmiş ve LOG doyası 50 GB’a ulaşmış. Bu LOG dosyasının bağlı olduğu MDF dosyası ise 6 GB… Yazılımcı arkadaş LOG dosyasında herhangi bir şey tutmuyoruz dedi ama Recovery modeli Full’den Simple’a çekmek konusunda tereddüt yaşıyor. Herhangi bir yan etkisi olur mu? diye sizin bilginize danışmak istedim. Teşekkürler

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Başa dön tuşu