SQL Server

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

Merhaba,

Önceki yazımızda SQL Server’da backup stratejilerinden bahsetmiş ve Full Backup, Differential Backup türleri ile nasıl yedek alabileceğimizi ve nasıl kapasite hesaplayacağımızı teorik olarak anlatmıştık.

Bu yazımızda ise backup alırken sıkıştırma yani compress özelliğinden bahsedeceğiz. Biraz da bilmeyenler için bir yedek nasıl alınır ve yedekten nasıl dönülür konularından bahsedeceğiz. Siz eğer fulll yedek almayı ve yedekten dönmeyi halihazırda biliyorsanız doğrudan aşağıda compress tarafına bakabilirsiniz.

Compress kısmında bir SQL backup dosyasını

  • Compress aktif şekilde
  • Compress pasif şekilde
  • Winrar ile sıkıştırarak
  • Winrar ile sıkıştırmadan

Almanın performans değerlerine bakıp avantaj ve dezavantaj değerlerine bakacağız.

Aslında bu özellik 2008’den beri var ama pek kullanılmıyor.

Elimizde SALES isimli bir database var. Data boyutu 280 MB. Daha büyük veriler de kullanabilirdik ama konu kolay anlaşılsın diye böyle bir veriseti seçtim.

Şimdi bu database’in yedeğini alalım.

Database üzerinde  sağ tıklayıp Tasks>Backup diyoruz.

Add diyerek backup almak istediğimiz lokasyonu seçiyoruz.

Backup Type’ı full diyerek işaretliyoruz.

Options kısmında set backup compression kısmına “do not compress” seçiyoruz. Bu değer eğer değiştirilmediyse default olarak da böyledir zaten.

Burada “ok” butonuna basarak yedek alabileceğimiz gibi, bu işi script olarak da çalıştırabiliriz. Ben script olarak çalıştıracağım.

Bunun için “Script” menüsüne tıklayarak Script Action to New Query Window menüsüne tıklıyorum.

Oluşan script bu şekilde

BACKUP DATABASE [SALES] TO  DISK = N’c:\backup\SALES.BAK’

WITH NOFORMAT, NOINIT, 

NAME = N’SALES-Full Database Backup’,

SKIP, NOREWIND, NOUNLOAD, NO_COMPRESSION,  STATS = 10

GO

Şimdi F5 tuşuna ya da execute menüsüne basarak sorgumuzu çalıştırıyoruz.

İşlem tamamlandı. Dosyamıza bakalım. Dosyamız yaklaşık 272 MB büyüklüğünde.

Şimdi aynı işlemi gün içerisinde 4 kez yaptığımızı düşünürsek, bu scripti 3 kez daha çalıştırıyoruz. Dosya ismini farklı vererek çalıştırırsak yeni dosyalar oluşur.

BACKUP DATABASE [SALES] TO  DISK = N’c:\backup\SALES2.BAK’

WITH NOFORMAT, NOINIT, 

NAME = N’SALES-Full Database Backup’,

SKIP, NOREWIND, NOUNLOAD, NO_COMPRESSION,  STATS = 10

GO

BACKUP DATABASE [SALES] TO  DISK = N’c:\backup\SALES3.BAK’

WITH NOFORMAT, NOINIT, 

NAME = N’SALES-Full Database Backup’,

SKIP, NOREWIND, NOUNLOAD, NO_COMPRESSION,  STATS = 10

GO

BACKUP DATABASE [SALES] TO  DISK = N’c:\backup\SALES4.BAK’

WITH NOFORMAT, NOINIT, 

NAME = N’SALES-Full Database Backup’,

SKIP, NOREWIND, NOUNLOAD, NO_COMPRESSION,  STATS = 10

GO

Eğer dosya adını aynı verirsek tüm yedekleri üzerine yazar ve tek dosyada tutulur. Şimdi de onu yapalım. 4 kez aynı database i yedek alalım ve dosyaları sildikten sonra aşağıdaki scripti 4 kez çalıştıralım.

 BACKUP DATABASE [SALES] TO  DISK = N’c:\backup\SALES.BAK’

WITH NOFORMAT, NOINIT, 

NAME = N’SALES-Full Database Backup’,

SKIP, NOREWIND, NOUNLOAD, NO_COMPRESSION,  STATS = 10

GO

1 kez çalıştırma

4 kez çalıştırma

Görüldüğü gibi üstüne yazarak devam ediyor. Burada tek dosya olmasına rağmen içinde 4 farklı zamanda yedek hangi yedekten dönüleceği bilgisine yedekten dönerken biz kara veriyoruz.

Sırası gelmişken onu da görelim.

Yedekten dönme işlemi gerçekleştirelim.

Database üzerinde sağ tık Tasks>Restore>Database diyoruz.

Son alınan yedek görüldüğü gibi otomatik olarak geliyor.

Ama biz kendi backup dosyamızı göstereceğiz. Bunun için from device seçeneğini tıklıyoruz ve … yazan butona tıklıyoruz.

Açılan ekranda Add butonuna tıklıyoruz.

Yedek aldığımız dosyayı seçiyoruz.

Burada dosya seçiliyken contents butonuna basarsak içerisindeki yedekleri görebiliriz.

Close dedikten sonra aşağıda görüldüğü gibi tüm içerik burada da listeleniyor ve biz içinden bize uygun olan saati seçip OK tuşuna basıyoruz.

Options kısmında şayet aynı database’in üstüne yedekten dönecek isek Overrite the exitsting database kutucuğunu işaretliyoruz.

Şimdi dilerseniz burada da script alalım.

Script bu şekilde. Şimdi çalıştıralım.

RESTORE DATABASE [SALES] FROM  DISK = N’C:\backup\SALES.BAK’

WITH  FILE = 3,  NOUNLOAD,  REPLACE,  STATS = 10

GO

Gördüğümüz gibi çalışmadı. Çünkü mevcut database e bağlantılar var. İki seçenek var biri bu database e bağlı kullanıcıları çıkarmak, diğeri de bu database i silmek.

Biz ikincisini yapacağız.

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

Açılan ekranda close exitsting connection kutusunu işaretliyoruz.

Artık elimizde scriptimiz olduğu için sildikten sonra tekrar biraz önceki işlemleri yapmamıza gerek yok sadece scripti çalıştırıyoruz ve veritabanımızı yedekten döndük.Artık elimizde scriptimiz olduğu için sildikten sonra tekrar biraz önceki işlemleri yapmamıza gerek yok sadece scripti çalıştırıyoruz ve veritabanımızı yedekten döndük.

Temel anlamda full yedekten dönme işlemi bu şekilde gerçekleşiyor. Bunu öğrendikten sonra kaldığımız yerden devam edelim. Şimdi Sales.bak dosyasını siliyoruz tekrardan ve bu kez yedek alırken sıkıştırma özelliğini aktif hale getirerek yedek alıyoruz. Yazının yukarısında nasıl yapıldığını anlattığım için tekrar oraya dönmek istemiyorum script üzerinden compression özelliğini açarak yedek alacağım.

1 kez alınan yedekte boyut 88 MB’a düştü. Önceki 276 idi. Yaklaşık 3 kat sıkıştırdı. Veri boyutu büyüdükçe bu oradan biraz daha artıyor. Tabi veritabanında tutulan veririnin türü ile de alakalı bu oran. Yani standart bir öngörü veremiyorum  maalesef. Tamamen deneyip görme işi.

Kıyas olması açısından winrar ile sıkıştırılmış halini de paylaşıyorum. Oda 40 MB. Yani SQL Backup yaklaşık 3 kat, winrar yaklaşık 7 kat sıkıştırmış durumda. Tabi bu şekilde küçük dosyalar için rar sıkıştırma düşünülebilir ama 300-400 gb lık dosyalarda rar ile sıkıştırma çok uzun süren bir işlem olacaktır.

Şimdi 4 kez yedek alalım

Yani yaklaşık 300 MB’lık bir db yi günde 4 kez full yedek aldığımızda 1.05 GB sıkıştırarak aldığımızda 350 MB lık yer kaplıyor.

Bir de örnek olması açısından 27 GB’lık bir Logo Tiger Database’ini hem sıkıştırarak hem de sıkıştırmadan aldığım yedeklerin görüntülerini paylaşmak istiyorum.

Sıkıştırarak aldığımda yaklaşık 4.2 GB, sıkıştırmadan aldığımda yaklaşık 26.8 GB ediyor. Aradaki fark yaklaşık 6.4 kat.

Sıkıştırarak alırken backup alma süresi 1 dakika 30 saniye ve backup alma hızı 290 MB/saniye.

Sıkıştırmadan aldığımızda ise backup alma süresi 5 dakika 10 saniye. Backup alma hızı ise 85 MB/saniye.

Şimdi biz yedek alırken bu özelliği işaretledik. Ancak varsayılan olarak biz bu özelliği seçmesek de otomatik olarak sıkıştırması için Server üzerinde properties diyerek

Açılan ekranda Database Settings’te compression kutucuğunu işaretlediğimizde artık sistem otomatik olarak sıkıştırarak yedek alacaktır.

Sonuç olarak backup alırken compress özelliği kesinlikle seçilmelidir. Ortalama bir erp veritabanında yaklaşık olarak 6-7 kat sıkıştırarak yedek alabiliyorsunuz. Dediğim gibi database boyutu büyüdükçe bu oran %80-90 seviyesinde sıkıştırmaya kadar çıkabiliyor.

27 GB büyüklükteki bir dosyayı rar ile tekrar sıkıştırdığımız zaman ulaştığımız dosya boyutu yaklaşık 2.4 GB.

Tabi bu 2.4 GB ı elde etmek için

  • 27 GB’lık okuma (Yedek almak için database’in okunması)
  • 27 GB’lık yazma (Yedek almak için database’in diske yazılması)
  • 27 GB’lık okuma (Rarlamak için tekrar okunması)
  • 27 GB’ı sıkıştırma için yoğun bir cpu kullanımı
  • 2.4 GB’lık yazma (Rar haline getirilen dosyanın yazılması.)

Toplamda 110 GB’lık bir IO işlemi ve çok yoğun bir cpu işlemi gerekiyor. Yedek alma 5 dakika, Rar ile sıkıştırma yaklaşık 13 dakika toplamda 18 dakikalık bir zamanda gerçekleşiyor.

Ama SQL Backup ile compress ederek almada

  • 27 GB’lık okuma (Yedek almak için database’in okunması)
  • 4 GB’lık yazma (Yedek almak için database’in diske yazılması)
  • Winrar kadar yoğun olmayan bir cpu kullanımı ile sıkıştırma ile

Toplamda 31 GB’lık bir IO ve 1 dakika 30 saniyelik bir işlemci kullanımı söz konusu.

Bir diğer yöntem de compress edilen backup’ın tekrardan rar ile sıkıştırma olabilir. O da değer mi? Bence o da değmez.

Aşağıdaki görüntüde 27 GB’lık bir SQL datası için

  • Compress pasif ile backup alınan dosya (5 dakika 10 saniye, 26.5 GB)
  • Compress aktif ile backup alınan dosya (1 dakika 30 saniye,  4.2 GB)
  • Compress pasif ile backup alınan ve rar yapılan dosya (13 dakika,2.4 GB)
  • Compress aktif ile backup alınan ve rar yapılan dosya (12 dakika,4 GB)

Sonuçları görülmektedir. Bence bu verilerden sonra hangisini seçeceğinize siz rahatlıkla karar verebilirsiniz.

Sonraki yazıda görüşmek üzere.

Sağlıcakla…

İlgili Makaleler

8 Yorum

  1. Hocam çok güzel bir seri elinize sağlık, daha uzun olmasını temenni ediyorum. Özellikle network map edilerek farklı bir disk üzerine maintenance plan ile yedeklerin alınması gibi konulara değinilmeside faydalı olacaktır. Ek olarak bir sorum olacaktı, backup compression sanırım bir miktar CPU yükü getiriyor bunun dışında herhangi bir olumsuz yönü ya da riski var mıdır. Aldığımız yedekler için sıkıştırma yapılmamış haliyle arasında hiç bir fark yoktur, bir veri kaybı kesinlikle yaşanmaz diyebilir miyiz.

    1. Merhaba,
      Güzel yorum için öncelikle teşekkür ederim. Çok önemli bir konu ve içerisinde az bilinen çok fazla sayıda detaylar barındırıyor. Dediğin gibi uzunca bir seri olmayı hakediyor ve böyle yorumlar, böyle talepler olduğu müddetçe bu seriler olacak da inşallah.
      Backup compression aslında winrar kadar agresif olmadığı için cpu yu yormuyor. Sonuç itibariyle sadece yer olarak kazanç değil 4-5 kat daha az sürede alınan bir backup olayından bahsediyoruz bu da aslında daha az yorulduğu anlamına bile gelir totalde.
      “Aldığımız yedekler için sıkıştırma yapılmamış haliyle arasında hiç bir fark yoktur, bir veri kaybı kesinlikle yaşanmaz diyebilir miyiz.”
      sorusunun cevabı gönül rahatlığı ile evet.
      1. si Microsoft veritabanı gibi önemli bir konuda bunu test etmeden uygulamaz.
      2.si Ömer Çolakoğlu bu yapıyı 2008’den beri kullanıyor ve herhangi bir sorun yaşamadı. 🙂

      Network’e kopyalama, yedek alma konusu aklımda. Seriye ekleyeceğim inşallah.
      Selamlar…

      1. Hocam vakit ayırıp uzunca ve gayet net verdiğiniz cevap için çok teşekkür ederim. Sizi uzun zamandır bir çok platformdan takip ediyorum, sql brute force attack, sql always on ve daha bir çok konuda anlattıklarınızdan ciddi derecede faydalandım. Hem bu konuda hem de diğer tüm paylaşımlarınızı sabırsızlıkla bekliyorum, emeğinize sağlık.

Bir yanıt yazın

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

Başa dön tuşu