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.

Makalemin bir önceki bölümünü incelemek için;

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

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.

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

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