SQL Server

SQL Server’da Backup Stratejileri-3 Differential Backup Kavramı ve Kullanımı

Merhabalar,

SQL Server Backup yazı dizimizin 1. Bölümünde Full Backup ve Differential Backup’tan teorik olarak bahsetmiştik. İkinci bölümde ise full backup ve sıkıştırma işlemlerinden bahsetmiştik. Her iki bölümede aşağıdaki linkler üzerinden ulaşabilirsiniz.

http://SQL Server’da Backup Stratejileri-1 Full Backup ve Differential Backup

https://www.cozumpark.com/sql-serverda-backup-stratejileri-2-full-backup-ve-backup-compression/

Bu bölümde ise differential backup kavramı üzerine konuşacağız.

Biraz hatırlayalım;

Differential backup en son alınan full backup ile şimdiki zaman arasındaki değişen verinin yedeğinin alınması anlamına geliyor.

Differential backup almak için database’in recovery modelinin full mode da olmasına gerek yok. Simple mode da olabilir ki bu büyük bir performans kazancıdır. Zira log dosyası gereksiz şişmez.

Elimizdeki bir differential backup’dan geri dönmek için ondan önce alınan bir full backup’a ihtiyacımız var.

Aşağıdaki görsel bunu güzel anlatıyor aslında.

Hadi şimdi bir database’in differential backup’ını alalım. Differential backup almadan önce full backup alacağım. Önceki yazımızda bahsettiğimiz backup compression özelliğini pasif hale getirip deneyeceğim ki backup veri boyutları biraz daha büyük olsun ve aradaki farkı daha iyi anlayalım.

Şimdi bir full backup alalım.

Önceki derslerimizde backup almak için hem script hem de kullanıcı arayüzü kullanmayı öğrenmiştik. Bu yüzden bu kez sadece script ile yedek almaktan bahsedeceğim.

Full backup boyutu yaklaşık 276 MB.

Şimdi hiçbir değişiklik yapmadan differential backup alalım.

Görüldüğü gibi sadece 1 MB’lık bir dosya oluştu. Bu 1 MB nereden çıktı diye düşünmeyin sonuçta backup dosyası ile alakalı bir şeyler de tutmak durumunda içerisinde.

Peki şimdi database’de ufak bazı değişiklikler yapalım. Örneğin bir tablo ekleyip içerisine döngü ile sürekli kayıt atalım.

Create table  DATES (ID INT IDENTITY(1,1),DATE_ DATETIME)

Şimdi artık elimizde bir normal database’imiz bir de içerisine 10.000 satır eklediğimiz bir dates tablomuz var. Yani database’i çok az da olsa büyüttük. Şimdi bu tablomuzun büyüklüğüne bir bakalım.

Tablomuzun büyüklüğü 264 KB. Şimdi bu database imizi tekrar differential yedek alalım.

Şimdi de dosya büyüklüğüne bakalım.

Görüldüğü gibi çok küçük bir büyüme olmuş.

Şimdi dilerseniz tablomuzu biraz daha büyütelim ve içine 100.000 satır atalım.

Çok küçük bir artış var.

Şimdi bir differential backup daha alalım.

Differential backup boyutu sadece 4 MB.

Şimdi buraya kadar differential backup ile yedek almayı öğrenmişken bir de differential backup ile yedekten dönme yani restore etmeye bakalım.

Bunun için database üzerinde sağ tık restore database diyoruz.

Açılan ekranda historyden son alınan backupları görebiliyoruz.

Şimdi biz hangi saate döneceksek onu seçiyoruz. Örneğin sadece full backup’ın olduğu backup zamanına yani 16:37:11’e dönelim. Database’in ilk hali.

Options bölümünde overwrite the existing database işaretliyoruz.

Backup’tan döndük.

Şimdi kontrol edelim burada DATES tablosunun olmaması gerekiyor.

Görüldüğü gibi bu yedek ilk halimiz.

Şimdi ikinci differential yedeğe dönelim. Burada full ü seçmeden tek başına differential ı seçemeyeceğimizi bilmemiz gerekiyor.

Şimdi ikinci yedeğe dönelim.

Burada sistem aynı anda bir tane differential seçtirir. Çünkü o differential backup full backup ile arasındaki olan tüm değişimi alır. Yani yedekten dönmek için 1 full+1 differential yeterlidir. 

Şimdi dönelim.  Overwrite existing database demeyi unutmuyoruz.

Backup’tan döndükten sonra yine bakıyoruz ve tablomuz yine yok.

Zira bu backup da hiçbir değişiklik yapmadan aldığımız differential’dı.

Şimdi bir sonrakinden dönelim.

Şimdi bakalım.

Gördüğümüz gibi bu backup’ta 10.000 satırlık ilk eklediğimiz zamana döndük.

Şimdi de sonuncuya bakalım.

Evet şimdi 110.000 satırlık veriye döndük. Peki elimizde bu kadar az değil de daha fazla backup varsa o zaman hangi dosyaya bakacağımıza değil hangi tarih ve saate bakacağımıza karar vermemiz gerekir. Hadi gelin şimdi bunu yapalım. Tekrardan restore database diyoruz.

Burada To a point a time kısmında Most recent possible yazıyor.

Yani en son alınan full backup ve varsa differential backuplar listeleniyor. İşte buradan 3 noktaya basmak suretiyle istediğimiz saati girebiliriz.

Örneğin ben burada 16:38:12’ye dönmek istersem sistem otomatik olarak full backup’ı işaretledi.

17:13:12’yi işaretlediğimde ise Full backup ve son alınan differential backup’ı işaretledi.

Peki şimdi buraya kadar öğrendiklerimize bir bakalım.

1.Differential backup fark backup’ı aldığı için oldukça hızlıdır ve az yer kaplar.

2.Sıklıkla alabildiğimiz için az bir kayıpla verimizi koruruz.

3.Transaction log backup almadığımız için database recovery mode u full yapmaya gerek yoktur ve simple olarak çalışır. Böylece sistem az yorulur ve transaction log dosyası büyümez.

Bunlar iyi tarafları. Ama tabi her güzelin en az birkaç kusuru oluyor. Kusur da demeyelim de dikkat edilmesi gerekenler diyelim.

Mesela adı üstünde differential. Yani fark büyük olursa bu fark sürekli büyür.

Hadi şöyle göstereyim.

Örneğin bizim büyük tablolarımızdan birinin kopyasını aldık diyelim. O zaman database de bu kadar fark olacaktır değil mi?

Hadi yapalım.

Elimizde 500 bin satırlık ve yaklaşık 200 MB’lık bir tablo var. SALEORDERS tablosu.

Şimdi database imizin differential backup’ını alalım.

Gördüğünüz gibi differential backup dosyası 200 MB oldu. Çünkü fark o kadar. Bu backup dosyasını 15 dakikada bir aldığınızı düşünün bir de her 15 dakikada bir 200 MB’lık bir yedek dosya hem de hiçbir hareket olmamasına rağmen.

15 dakika sonraki yedek de bu şekilde görünecek.

Her ne kadar 200 MB olarak düşündüğümüzde çok gelmese de database in toplam boyutunun yaklaşık 400 MB olduğunu düşünürseniz her 15 dakikada database’in %50 kadarlık bir yedekten bahsediyoruz.

 Aynı şekilde index rebuild etme ya da index oluşturma gibi işlemler sonrasında da differential backup oldukça büyüyecektir. Bu yüzden bu tarz büyük işlemler sonrasında sistemi rahatlatmak adına aralara full backup serpmek mantıklıdır. Hele hele index rebuild işleminden sonra kesin yedek alınmalıdır.

Şimdi önce bir full backup alalım sonra tekrar differential backup alalım ve aradaki farkı hep birlikte görelim.

Gördüğümüz gibi full backup’ım 474 MB’a çıktı.

Şimdi de tekrar differential backup alalım.

Evet burada da artık fark backup’ının sıfırlandığını görüyoruz.

Ayrıca burada veri boyutları biraz büyük ve abartılı olsun diye compression özelliğini pasif olarak kullandık. Bu konu ile alakalı detaylı yazımı burada bulabilirsiniz.

Fikir vermesi açısından son olarak Compression özelliği aktif olarak full backup aldığımızda

Elde ettiğimiz sonuç aşağıdaki gibi. Bu veri büyüklüğünde yaklaşık 3 kat sıkıştırarak almış.

Özetle bu yazımızda;

  • Differential backup nasıl kullanılır?
  • Nasıl yedek alınır ve nasıl yedekten dönülür?
  • Differential backup alırken nelere dikkat edilmelidir?

Sorularına cevap aradık. Sanki “Tamam da abi bunları nasıl otomatik yaptıracağız?” dediğinizi duyar gibiyim. 😊

Az kaldı tüm bu anlattıklarımı otomatik yaptırmak çok çok kolay.

İlerleyen yazılarda görüşmek üzere.

Sağlıcakla…

İlgili Makaleler

4 Yorum

  1. Teşekkürler hocam. Bir sorum olacak. Diyelim 17:05 de bir kayıt yanlışlıkla silinmiş. 19:00 da fark edildi. 17:00 deki backup restore edildiğinde silinen kayıt silinmemiş olarak görünecek. Ama bu durumda arada geçen 2 saatlik bir veri kaybı söz konusu. Silinen veri tek tabloyu etkilemiyor, Erp ye bağlı db. Birçok tablo etkilenmiş olabilir. O yüzden aynı satırı ekleyip geçeyim de diyemiyorum. Buna benzer bir senaryoda minimum veri kaybı yaşamak için nasıl bir yedekleme planlanmalı.

  2. Merhaba,
    Bu durumlarda tabloları iyi biliyorsan eğer 17:00 deki yedeğe test ortamında dönüp tabloda silinen verileri manuel olarak yerine almak mantıklı olur. Öbür türlü evet 2 saatlik kayıp olacak malesef. Buna yapılacak çok birşey yok.

Bir yanıt yazın

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

Başa dön tuşu