Bu makalemizde sql server’da backup işleminin Full, Diff ve Log backup’ın ne olduğunu detaylı bir şekilde görmüş olacağız. Sonraki makalemizde Full, Diff ve Log Backup alıp Restore işlemini gerçekleştirmiş olacağız.
Backup özü olarak veritabanının yedeğini alma işlemine Backup denir. Öncelikle neden backup işlemine gerek duyarız. Veritabanımızda bulunan herhangi bir bozulma, başka bir ortama taşıma, verilerimizin güvenliği veya herhangi bir sıkıntı anında veri kaybını minimize edecek şekilde backup alıp daha sonra alınan backup’ı ilgili instance üzerine tekrar yükleyebiliriz.
Backup denilince aklımıza 3 tip backup yöntemi olduğu gelmelidir. Bunlar FULL, DIFF ve LOG backup olarak karşımıza çıkmaktadır. Şimdi bu backup türlerinin ne işe detaylı bir şekilde açıklayalım. Backup ve Restore işlemini yapmak için ilgili makaleyi okumalısınız.
Full Backup: Veritabanının tamamının yedeğini alma işlemidir. SQL Server, yedekleme (backup) alırken veritabanının o anki tutarlı görüntüsünü (snapshot’ını) alır. Buna teknik olarak “transactionally consistent backup” denir. Bu fiziksel snapshot değildir ama o anki tutarlı veri yapısını temsil eder. Backup boyunca sadece o “anlık görüntüde” var olan veriler yedeklenir. SQL Server, yedekleme işlemi başladığı andan bittiği ana kadar geçen süredeki tüm değişiklikleri Backup dosyasının (.bak) en sonuna yazar. Her şey tek bir .bak dosyasının içinde paketlenir. SQL Server “anlık görüntüyü” yedek dosyasının sonuna eklediği Transaction Log parçacıkları sayesinde restore anında simüle eder.
Backup işlemi sürerken veri değişse bile: Yani backup, veritabanının backup başladığı andaki halini temsil eder. Backup sırasında veriler değişse bile, başlangıçtaki snapshot’a göre yedek alır. Backup dosyasına bu değişiklikler yazılmaz. Kısaca Backup sırasında yapılan değişiklikler veritabanına normal yazılır ama backup dosyasına dahil edilmez.
Full backup aldıktan sonra SQL Server, değişen her veri sayfasını işaretler. Differential backup başladığında bu işaretli (değişmiş) sayfaların o anki halini yedekler. Yani başladığı anda hangi sayfalar değişmişse, sadece o sayfaların şu anki halini yedekler. SQL Server, log backup alındığında bir LSN (Log Sequence Number) aralığı belirler.
Full backup yönteminde backup alındığı anda ldf dosyasının büyüklüğü ne ise boyutuyla birlikte almaktadır. Bu sebepten restore edilecek ortamda disk yoksa dikkat edilmesi gerekmektedir.
Genellikle büyük sistemlerde haftada bir backup işlemi alınmaktadır. İhtiyaca göre değişkenlik gösterilir. Full backup bittikten sonra diğer yedek türleri referans alınmaktadır.
FULL backup ardından log backuplar daha sonra bir full backup ve ardından tekrardan log backuplar alınırsa ilk full backuptan sonra tüm loglar yüklenerek veritabanı ayağa kaldırılır. Loglar birbirine bağlıdır. Arada full backup olması sıkıntı teşkil etmez. İkinci full backuptan sonra diğer loglarda devam ettirilir.
Full backup işlemi, primary sunucusunda gerçekleştiği için secondary sunucusunun senkronizasyonu üzerinde herhangi bir olumsuz etki yapmaz. Yedekleme işlemi sırasında, primary sunucusundaki veriler secondary sunucusuna anında iletilir. Backup işlemi sırasında secondary sunucusunun synchronization durumunda herhangi bir sorun yaşanmaz. Synchronous commit durumunda, veritabanı işlemleri, primary ve secondary sunucusu arasında eşzamanlı olarak gerçekleşir, bu nedenle yedekleme işlemi sırasında senkronizasyon sağlıklı bir şekilde devam eder. Asynchronous commit sırasında, secondary sunucusunda veri aktarımı biraz gecikmeli olabilir. Ancak, backup işlemi primary sunucusunda yapılacağı için secondary sunucusunda senkronizasyon problemi yaşanmaz, sadece gecikme olabilir. Yedekleme işlemi primary sunucusunu etkilemez, ancak secondary sunucusunda asynchronous commit olduğu için, yedekleme işlemi sırasında primary sunucusunda yapılan işlemler secondary sunucusuna bir süre sonra aktarılabilir.
Diff Backup: Veritabanının en son alınan full backup’dan sonra alınan fark yedeğidir. Yani siz full backup üzerine her gün bir diff backup alırsanız en son alınan diff backup full backup ile arasındaki tüm yapılan işlemlerin fark backup’ını almaktadır. En son alınan diff backup’dan önceki diff backup ise kendi ile full backup arasındaki farkı almaktadır. Full backup üzerine hangi diff backup’ı dönerseniz o ana dönmüş olursunuz. Genellikle kurumlarda her gün bir diff backup alınmaktadır. İhtiyaca göre değişkenlik gösterebilir.
Bir Diff yedek, her zaman tamamlanmış (successful) en son “Full Backup”ı referans alır. Buna LSN (Log Sequence Number) takibi denir. Full backup başladığında bir “Checkpoint” oluşturur ancak LSN değerini ancak yedekleme başarıyla bittiğinde günceller. Eğer bu, veritabanının ilk Full yedeğiyse ve henüz bitmemişse, Diff backup hata verir çünkü referans alacağı bir “Base” (temel) yoktur. Aşağıdaki resimde de görüldüğü gibi Full backup’ın bir checkpoint ürettiği diğer tüm backup türlerinin Full backup’ı referans aldığı görülmektedir.
Alınan bu backup’ların her biri aslında bir maliyettir. Bunun için sistemin ve disk yapısının iyi analiz edilmesi gerekmektedir. Her full backup’dan sonra fark backup’ı sıfırlanmaktadır.
Differential Change Map (DCM Pages): Son tam yedeklemeden (Full Backup) sonra değişen extents’leri izler. Diferansiyel yedeklemelerde hangi extents’lerin değiştiğini tespit etmek için kullanılır. Full backup alındığında bu değer sıfırlanmaktadır. Full backup önerilmesinin sebebi diff backup büyük bir boyut almasın diye önerilmektedir. Her data file’da 1 tane bulunmaktadır. Veri dosyaları içindeki GAM (Global Allocation Map) ve özellikle DCM (Differential Changed Map) adı verilen bitmap sayfalarına bakar. Bir veri sayfası değiştiğinde, SQL Server DCM sayfasındaki ilgili biti “1” yapar. Diff backup sadece bu “1” olan sayfaları okur ve yedek dosyasına yazar. DCM sayfasındaki her bir bit, veri dosyasındaki spesifik bir Extent‘e karşılık gelir. SQL Server, bu bitin DCM sayfası içindeki “sırasından” (offset), hangi veri sayfasına baktığını matematiksel olarak bilir. Differential Backup başladığında, DCM sayfalarını baştan sona tarar. Eğer 5. bit “1” ise, gider dosyanın başından itibaren 5. veri grubunu (Extent) okur ve yedeğe yazar. GAM (Global Allocation Map): Bir Extent’in (8 sayfalık grup) dolu mu boş mu olduğunu takip eder. SQL Server yeni veri yazacağı zaman “neresi boş?” diye buraya bakar. DCM (Differential Changed Map): Bir Extent’in Full backup’tan sonra değişip değişmediğini takip eder. Backup bittiğinde tüm bu bitler tekrar 0‘a çekilir.
İndexs bakımı yaparken differantial yedek alınması önerilmez. Çünkü indexs’leme işlemi veritabanında baştan sona değişiklik içerdiği için diff backup full backup boyutuna ulaşır. Bunun için indexslemeden sonra full backup alınması önerilir. Ya da herhangi bir tablo kopyalama işleminde yine backup boyutumuz büyüyecektir. İndexs rebuild işlemlerinde kesin alınması gerekmektedir.
Log Backup: Transaction log dosyasında yapılan işlemlerin backup’ını almaktadır. Log backup sadece kendinden önceki log backup ile arasındaki farkı alır. Herhangi bir sorun anından full,diff backup restore edildikten sonra log backuplar sırasıyla yüklenerek dönülmek istenen zaman dilimine gelinir. Transaction log alındığında log dosyası truncate olur buda log dosyasının şişmesinin önüne geçer.
Full backup restore ettikten sonra üzerine log backup’ı restore edersek aradaki tüm veriler gelir. Full ile log backup arasına diff backup yüklemek şart değildir. İlk log backup full backup’a bağlıdır. Diff ve log backup arasında hiçbir hiyerarşik ilişki bulunmaz. Full ve diff backupdan sonra log dosyaları truncate edilmez. Sadece log backup alındığında log dosyaları truncate edilir. Diff backup şunu sağlar aslında yüzlerce log backup dönmek yerine bir diff dönerek üzerine log backup’lar eklenir.
Aşağıdaki resimde dikkat edilirse Differential backup ve log backup’ın checkpoint LSN değeri aynıdır. Log dosyalarda bir log’un Last LSN değeri bir sonraki LOG dosyasının First LSN değeridir.
Simple recovery modda full ve diff backup vardır. Log kayıtları olur ve ldf’e yazılır ama checkpoint işlemi gerçekleşir ve daha sonra ldf dosyası truncate edilir. Veri kaybı checkpoint işlemi işlemi yapılmadan sunucu kapanırsa veri kaybı yaşanmaktadır.
Şimdi Detaylı Bir şekilde Backup Zincirini Açıklayalım:
SQL Server’da “Backup Chain” (Yedekleme Zinciri), bir veritabanını belirli bir zaman dilimine geri döndürebilmek için gereken yedek dosyalarının birbirine olan kopmaz bağıdır. Bu zincir, tıpkı bir Lego kulesi gibidir; en alttaki parça (Full Backup) olmadan üsttekileri dizemezsiniz.
Zinciri bir arada tutan tutkal LSN‘dir. SQL Server içindeki her işlem (Insert, Update, Delete) benzersiz ve sürekli artan bir numara alır.
- Full Backup: Zincirin “Sıfır” noktasıdır. O anki LSN’i kaydeder.
- Log Backup: Bir önceki yedeğin bittiği LSN’den başlar ve kendi bittiği LSN’i işaretler.
- Differential Backup: En son Full Backup LSN’inden itibaren değişen “veri sayfalarını” getirir ama log zincirini bozmaz.
Senaryo:
- Pazartesi 08:00 (Full Backup): Temel atıldı. LSN: 100 olsun.
- Pazartesi 09:00 (Log Backup 1): 100 ile 150 arasındaki işlemleri paketler.
- Pazartesi 10:00 (Log Backup 2): 150 ile 200 arasındaki işlemleri paketler.
- Pazartesi 11:00 (Diff Backup): 100’den (Full’den) bu yana değişen tüm sayfaları toplar. Mevcut LSN: 250.
- Pazartesi 12:00 (Log Backup 3): 200 ile 300 arasındaki işlemleri paketler.
Dikkat: Log Backup 3, kendinden önceki Log yedeğine (Log Backup 2) bakar, Diff yedeğine bakmaz. Çünkü Log yedekleri kendi içinde ayrı bir zincirdir.
Bir felaket anında (örneğin saat 12:30’da veri silindi), SQL Server bu zinciri şu sırayla birleştirir:
- Zemin (Full): Önce Pazartesi 08:00 yedeği yüklenir. (Veritabanı LSN 100’de).
- Kısayol (Diff): 09:00 ve 10:00 loglarını tek tek yüklemek yerine 11:00 Diff yedeğini yüklersiniz. (Veritabanı bir anda LSN 250’ye sıçrar).
- Kalan Parçalar (Log): Şimdi 250’den sonraki halkayı eklemeniz lazım. Bu da Log Backup 3‘tür.
Zincir Nerede Kopar? Eğer Pazartesi 10:00’daki Log yedeğini kaybederseniz ve Diff yedeğiniz de yoksa, 09:00’dan sonrasına (12:00’ye) asla gidemezsiniz. Aradaki halka eksik olduğu için “Log Chain is broken” hatası alırsınız.
Bazı işlemler bu “Lego kulesini” devirebilir:
- Recovery Model Değişimi: Veritabanını Full modelden Simple modele çekmek log zincirini anında kırar. Tekrar Full yedek almanız gerekir.
- TRUNCATE LOG (Eski versiyonlar): Logu yedeklemeden temizlemek zinciri koparır.
- Başka Bir Backup Tool: Eğer SQL Server dışında bir yazılım (örneğin bir VM snapshot aracı) “Copy-Only” seçeneğini kullanmadan yedek alırsa, LSN takibini karıştırabilir ve sizin manuel aldığınız zinciri bozabilir.
Eğer sadece Log yedekleriniz olsaydı, 1 hafta önceki Full yedekten bugüne gelmek için binlerce Log dosyasını tek tek yüklemeniz gerekirdi. Diff Backup, zincirdeki uzun bir mesafeyi tek hamlede atlamanızı sağlayan bir “köprü” görevi görür.
Not: Copy-only backup ise başka bir makalenin konusu olmuş olacak. Kısacası bu ifade bağımsız bir şekilde backup alma işlemidir. Çünkü rastgele bir backup alırsak backup hiyerarşisini bozmuş olabiliriz. Full backup’da ve log backup’da bu yapı aktiftir. Diff backup’da aktif değildir. Normalde Backup alınırken alınan backup’ın tam yerini belirten bir işaret konularak bir sonraki backup için başlama noktası belirlenir.Copy_Only Backup seçeneğini seçerek istediğimiz herhangi bir yerden backup almaya devam edebiliriz.
Secondary sunucusuna diff backup restore edildikten sonra primary sunucusunda log backupların neden bazı durumlarda secondary sunucusuna restore etmeden Primary ve secondary sunucusunda senkron işlemi oluyor. Bunun açıklamasını yapalım. Bunun olası nedeni, Always On replikasyonunun DIFF restore sonrası direkt senkronizasyon yapmasıdır.
Soru aşağıdaki adımlarda belirtiliyor.
- Full Backup’ı ve DIFF Backup’ı NORECOVERY modunda Secondary’ye yükledin.
- DIFF restore devam ederken Primary’de 2 adet LOG backup alındı.
- Sen DIFF restore’ü tamamladığında, bu iki LOG backup’ı yüklemedin ama Secondary Always On’a dahil oldu.
- Herhangi bir LSN hatası almadan direkt olarak senkron oldu.
Bu senaryonun olası sebebi:
- DIFF backup yüklenirken, Primary ve Secondary sunucu zaten aynı Full Backup’tan başlatıldığı için LSN chain kopmadı.
- Always On, DIFF restore sonrası Secondary sunucuyu asenkron (catch-up) moduna alarak replikasyonu başlattı.
- Primary ile Secondary arasında DIFF sonrası oluşan fark, Always On’un redo log mekanizmasıyla otomatik olarak senkronize edildi.
- SQL Server, LOG backup restore etmek yerine, Always On’un kendi log gönderme mekanizmasını kullanarak Secondary’yi güncelledi.
Sonuç:
- Primary’de alınan 2 LOG backup’ı restore etmeden de Secondary, Always On’a dahil oldu çünkü Always On kendi log replike mekanizmasını kullandı.
- Bunun olmasını sağlayan temel mekanizma, DIFF restore sonrası LSN zincirinin bozulmaması ve Always On’un redo mekanizmasının devreye girmesidir.
- Bu yüzden, DIFF restore sonrası log backup restore etmene gerek kalmadan sistem otomatize şekilde güncellendi.
Başka makalede görüşmek dileğiyle..
“Kullarım sana Beni sorarlarsa, bilsinler ki Ben, şüphesiz onlara yakınım. Benden isteyenin, dua ettiğinde duasını kabul ederim. Artık onlar da davetimi kabul edip Bana inansınlar ki doğru yolda yürüyenlerden olsunlar.”Bakara Suresi; 186. Ayet
