Merhaba, bu makalemizde sql server’da backup işleminin nasıl yapıldığını ve nasıl senaryolarının olduğunu ele almış olacağız. Uygulamalı bir şekilde işin özünü anlayarak işlemlerimizi yapmış olacağız. Uygulamalı bir şekilde işlemlerimize geçmeden önce mssql server’da backup konusuna değinelim. Elimizde bulunan 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 gelmeli. Bunlar FULL, DIFF ve LOG backup olarak karşımıza çıkmaktadır. Şimdi bu backup türlerinin ne işe yaradığını açıkladıktan sonra uygulamalı bir şekilde işlemlerimize başlayalım.
Full Backup: Veritabanının tamamının yedeğini alma işlemidir. Genellikle büyük sistemlerde haftada bir backup işlemi alınmaktadır. İhtiyaca göre değişkenlik gösterilir.
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.
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.
Not: İ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.
NOT olarak şunu da belirtmek gerekir. 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.
Not: Simple recovery modda full ve diff 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.
Bu kavramın ne olduğunu tam olarak kavramak için Transaction Log Dosyası nedir makalesinin okunmasını tavsiye ediyorum.
Şimdi uygulamalı bir şekilde FULL, DIFF ve LOG backup alalım.
Bunun için elimde bulunan AdventureWorks2012 veritabanı altında BACKUP_TABLE adında bir table oluşturuyorum. Oluşturmuş olduğum bu tabloya anlık veriler atıyorum. Bu verileri tanımlamış olduğum bir job aracılığıyla atıyorum.
Verilerimiz job aracılığıyla tablomuza gelmeye devam ederken bir full backup alıyorum. Tablomuzun olduğu veritabanı üzerine sağ tıklayıp Tasks> Back Up.. kısmına tıklanır.
Gelen ekranda Backup Type kısmında full backup alacağımız için FULL seçilir.
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.
Backup component kısmında herhangi bir file group’un backup’ını almayıp tüm database’in backup’ını alacağımız için Database sekmesini seçiyoruz. Veritabanı file grouplara bölünmüş olabilir ve bölünmüş bu backupların bazıları okuma modunda olabilir. Sadece yazma modunda aktif olan filegroupların backupları alınmaya çalışıldığında bu sekme seçilebilir.
Backup up to kısmında backup dosyamızı hangi disk ve klasör altına almak istiyorsak o yol seçilir. Backup up to kısmında disk seçmeyip herhangi bir azure ile entegre URL bağlantısı da seçilebilir. Buda network hızınıza göre backup süresinin uzun olmasına sebebiyet verecektir. 
Localimiz de bulunan disk üzerine backup alacağımız için Disk seçimi yapıyoruz.
Daha sonra Destination bölümünde sağ alt tarafta bulunan Add kısmına tıklayıp backup klasörümüzü nereye kaydetmek istiyorsak o uzantıyı seçiyoruz.
İlgili uzantıyı seçtikten sonra backup dosyamıza bir isim veriyoruz. Full backup aldığımız için uzantısını .bak yapıyoruz.
Not olarak şunu belirtmek gerekirse Full ve Diff backup’larda uzantısı .bak olarak oluşturulmaktadır. Log Backup’larda uzantısı .trn olarak oluşturulması gerekmektedir.
General sekmesinde işlemleri bitirdikten sonra Media Options kısmına geçilir.
Bu kısımda Reliability kısmında Verify backup when finished kısmına seçersek backup bittikten sonra backup işleminin doğru alındığının teyitini yapmaktadır. Backup bittikten sonra restore süresi kadar işlemimiz uzayacaktır. Bu ifadenin seçilerek işlem yapılması verileriniz doğruluğu için gereklidir.
Perform checksum before writing to media: Yedekleme işlemi yapılmadan önce kontrol işlemi yapar. Yedekleme işlemi sırasında veri bozulmalarını engellemek için kullanılır.
Continue on error: Hata durumunda yedeklemeye devam eder. Normalde bir hata olduğunda yedekleme durur. Bu seçenek aktifse hata olsa bile yedeklemeye devam eder.
Overwrite media kısmında bulunan seçenekler ne işe yarar bunlara değinelim.
Backup to the existing backup sets mevcut backup dosyasına yedekleme yapılır
Append to the existing backup sets mevcut backup dosyasına yedekleme yapılır. Eski yedekleme korunmaktadır.
Aşağıdaki resimde dikkat ederseniz yukarıdaki iki seçenek seçilerek iki farklı backup’ın aynı dizin altında bulunmasına denk gelmektedir. İlgili bölüme ulaşmak için aşağıdaki numaralar dikkate alınarak istenilen kısma ulaşılabilir.
Overwrite all existing backup sets ifade ise tüm mevcut yedeklemeleri siler ve yeni yedek bu setin üzerine yazılır. Önceki yedeklemeler bu işlemde silinir. Aşağıdaki resimde dikkate ederseniz önceki yedeklenmeler silindiği görülmektedir.
Bu bölümdeki gerekli ayarlamaları yaptıktan sonra Backup Options kısmında bazı ayarlamaları yaparak full backup işlemimizi sonlandırabiliriz.
Backup set kısmında restore ederken hangi isim ve açıklamanın gelmesini istiyorsak bu seçenek doldurabilir. Ya da aşağıdaki gibi default şekilde bırakmada fayda vardır.
Backup set will expire kısmında ise alınmış olan backup’ın kaç gün sonra silinmesini istiyorsak After kısmına yazılması gerekmektedir. On kısmında ise belirtilen tarihten sonra After ifadesindeki gün ifadesinin eklenmesini sağlayabiliriz.
Compression kısmında ise alınan backup’ın sıkıştırılarak alınıp alınmayacağını belirleyebiliriz.
Burada 3 seçenek karşımıza çıkmaktadır. İnstance seviyesinde hangi ayar yapılmışsa o ayarın kullanması isteyebiliriz. Bunun için Use the default server setting kısmının işaretlenmesini sağlayabiliriz. Default olarak gelen değerde budur. Sql server sıkıştırmalarda %60-70 arası disk alanı kazancı sağlar. Cpu kullanımında %10-20 bir artış sağlamaktadır.
Not: Sql server verileri sıkıştırırken hangi teknolojileri kullandığı genellikle açıklanmaz. Temel prensip LZ tabanlı veri farkı sıkıştırmasıdır.(pattern matching+run-length) Sql serverın veri sıkıştırırken kullandığı benzer teknolojiler LZ77 ve Deflate benzeri yapıyı kullanmaktadır.
İnstance properties kısmında Database Settings kısmında bu ifadenin default olarak düzenlenmesi yapılabilir. Ya da sp_configure makalesinden bu işlemin nasıl yapıldığını görebiliriz.
Backup arayüzünde default olarak bırakmış olsaydık full backup’ı sıkıştırarak almamış olacaktı. Backup arayüzünde compress backup ibaresini seçiyoruz. Bu ifade ne kadar boyutu düşürsede CPU’ya ekstra bir yük getirmektedir. Eğer herhangi bir ifade seçmesini istemiyorsak Do not compress backup seçmemiz gerekiyordu.
Not: Önceden compression olmayan bir backup’ın üzerine compression şeklinde backup almak istersek hata ile karşılaşırız. Aşağıda ilgili resmi görebilirsiniz.
SELECT *
FROM msdb..backupsetYukarıdaki komut ile alınmış olan backupların gerçek boyutunu ve sıkıştırılmış halini görebiliriz.
Aşağıdaki komut ile backup başlangıç-bitiş tarihini veritabanı gerçek boyutunu ve sıkıştırıldıktan sonraki boyutu görebiliriz.
SELECT backup_start_date,backup_finish_date, backup_size,compressed_backup_size
FROM MSDB..backupset WHERE database_name='AdventureWorks2014' order by backup_finish_date desc
Not: 10 GB’lık bir veri sıkıştırılmak istenirse ilk başta yedek almak için 10 GB’lık bir okuma daha sonra sıkıştırılmış dosya boyutu kadar yazma işlemi yapar. Tabi bu işlem yoğun bir cpu kullanımı ile olmaktadır.
Database üzerinde herhangi bir Encryption ifadesi aktif edilmişse aşağıdaki kısım aktif bir şekilde gelmektedir.
Sayfada paylaşılan şifreli backup alma makalesini detaylı bir şekilde okuyabilirsiniz.
Tüm bu backup adımlarını yaptıktan sonra Ok tuşuna basıp işlemlerimiz tamamlayabiliriz. Veya en sağlıklı yöntem olan sol üst köşede bulunan scprit kısmından kod çıktısı alınıp çalıştırılır. Önerilen yöntem budur çünkü arayüzde donmalara sebebiyet verebilir.
Backup’ın çıktısını alıyoruz.
BACKUP DATABASE [AdventureWorks2012] TO DISK = N'C:\veritabanı\AdventureWorks2012.bak' WITH NOFORMAT, NOINIT, NAME = N'AdventureWorks2012-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10
GO
declare @backupSetId as int
select @backupSetId = position from msdb..backupset where database_name=N'AdventureWorks2012' and backup_set_id=(select max(backup_set_id) from msdb..backupset where database_name=N'AdventureWorks2012' )
if @backupSetId is null begin raiserror(N'Verify failed. Backup information for database ''AdventureWorks2012'' not found.', 16, 1) end
RESTORE VERIFYONLY FROM DISK = N'C:\veritabanı\AdventureWorks2012.bak' WITH FILE = @backupSetId, NOUNLOAD, NOREWIND
GOScprit’i çalıştırdıktan sonra Full backup’ın başarılı bir şekilde alındığını görmüş oluyoruz.
Not: Full backup işlemleri sırasında backup devam ederken veritabanı üzerine yazma işlemi gerçekleşmektedir.
Not: 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. 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.
Örneğin:
Son log backup LSN: 100
Şu anki LSN: 150
Yeni log backup: 100–150 arasındaki log kayıtlarını yedekler.
Backup başladıktan sonra gelen LSN = 151 → bu yedek dosyasına dahil edilmez.log backup da başladığı anda hangi aralık yedeklenecekse onu kilitler. Bu aralık dışında kalan işlemler bir sonraki log backup’a kalır.
Not: 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.
Not: N ifadesi eğer Türkçe ve özel karakterler varsa N tek tırnak şeklinde kullanılır. Unicode ifadesine karşılık gelmektedir.
Backup’ın ilgili klasör altına alındığını görmüş oluyoruz.
Differential ve Log Backup için aynı işlemleri gerçekleştiriyoruz. İlgili veritabanı üzerine sağ tıklayıp Task->Backup.. dedikten sonra Backup Type kısmından Log Backup için Transaction Log’u, Differential Backup için Differential’ı seçiyoruz. Differential Backup’ın uzantısı .bak, Transaction Log’un uzantısı .trn olarak değiştirmemiz gerekiyor.
Şimdi sırasıyla Diff ve Log backup alalım.
AdventureWorks2012 veritabanının üzerine sağ tıklayıp Task->Backup dedikten sonra Backup Type kısmında Differential seçilir ve Destination kısmında ise diff backup’ın ismi ve uzantısı yazılır. Media options ve Backup Options kısmındaki ayarlamaların hepsi full backup’da yapıldığı gibi yapılabilir.
BACKUP DATABASE [AdventureWorks2012] TO DISK = N'C:\veritabanı\AdventureWork2012_DIFF.bak' WITH DIFFERENTIAL , NOFORMAT, NOINIT, NAME = N'AdventureWorks2012-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10
GONot: Backup alırken Maxdop kullanılmaz. Sql server engine kendisi karar verir.
Tekrar arayüzün script’ini alıp çalıştırıyorum. Diff backup’ın işlemimiz başarılı bir şekilde alınmış oldu.
Makalenin başında açıklama kısmında belirtmiştik diff backup full backup ile arasındaki farkı alır.
Diff backup’ıda aldıktan sonra şimdi ise log backup alma işlemine geldi. Bu ifadenin önceki backuplardan farkı uzantısının .trn olması ve Backup Type kısmında log ifadesinin seçilmesi gerekmektedir.
AdventureWorks2012 veritabanının üzerine sağ tıklayıp Task->Backup dedikten sonra Backup Type kısmında Transaction Log seçilir ve Destination kısmında ise log backup’ın ismi ve uzantısı yazılır.
Tekrar arayüzün script’ini alıp çalıştırıyorum. Log backup işlemimiz başarılı bir şekilde alınmış oldu.
BACKUP LOG [AdventureWorks2012] TO DISK = N'C:\veritabanı\AdventureWork2012_LOG.trn' WITH NOFORMAT, NOINIT,
NAME = N'AdventureWorks2012-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10
GOLog backup işlemini yaptıktan sonra belirli aralıklarla log backup işlemini yapıyorum.
Bu backup işlemlerinden sonra veritabanımızın yanlışlıkla silinmesi, bozulması veya başka bir ortama taşınma işleminde yedeklerden dönülerek restore işlemine tabi tutulur. Bir sonraki makalede restore işlemini ele almış olacağız. Makalemizi bitirmeden elimizde bulunan en son verinin ekran görüntüsünü alalım.
Not: Sql server arayüzünde alınan bir backup script’inde ifadelerin ne işe yaradığına değinelim.
BACKUP DATABASE [AdventureWorks2012] TO DISK = N'\\S3\backup\AdventureWorks2012.bak' WITH NOFORMAT, NOINIT,
NAME = N'AdventureWorks2012-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10
GOBACKUP DATABASE [AdventureWorks2012]: “AdventureWorks2012” adlı veritabanını yedeklemek için kullanılan komut.
TO DISK = N’\\S3\backup\AdventureWorks2012.bak’: Yedeğin kaydedileceği dosya yolu belirtilmiş. Bu örnekte, yedekleme dosyası UNC yolunda “\\S3\backup\AdventureWorks2012.bak” adlı bir dosya olarak saklanacak.
WITH NOFORMAT: Bu seçenek, hedefteki yedekleme dosyasının formatlanmamasını sağlar. Önceki yedekleme ortamı bozulmadan kalır.
WITH NOINIT: Yedekleme dosyasına eklenmesini sağlar, dosyayı sıfırlamaz. Yani, var olan yedek dosyasının üzerine yazılmaz, yedekleme yeni bir yedekleme seti olarak eklenir.
Not: Yukarıdaki iki komut aynı isimde backup dosyasının içirişinde birden fazla aynı database bulunmaktadır. Buda With file ifadesiyle ilgili dosya seçilmektedir. Aynı backup üzerine birden fazla yedek varsa SSMS arayüzünde restore sırasında her zaman en son yedek görülür.
Backup alınan veritabanını restore edeceğimiz zaman Device bölümünden ilgili Backup uzantısını seçtikten sonra Contents dersek backup dosyasının üzerine alınmış tüm backup’ları görebiliriz.
Buradan ilgili backup dosyamızı seçerek restore işlemini yapabiliriz.
NAME = N’AdventureWorks2012-Full Database Backup’: Yedekleme işlemi için açıklayıcı bir isim. Yedekleme bu isimle etiketlenir.
SKIP: Yedekleme işlemi sırasında ortam kontrollerinin atlanmasını sağlar. Yani, dosyanın üzerine yazılıp yazılmayacağına dair sorular sormaz.
NOREWIND: Yedekleme işlemi bittikten sonra tape kasetini başa sarmayıp aynı pozisyonda bırakılır. Böylece ilk backup’tan sonra tape başa sarılmaz ve ikinci backup hemen arkasından yazılır.
NOUNLOAD: Yedekleme veya restore işlemi bittikten sonra tape ortamı (backup cihazı) dışarı çıkarılmasın. Disk yedeklemelerinde etkisi: YOK. Çünkü fiziksel bir kaset çıkartma işlemi zaten yok.
STATS = 10: Yedekleme işlemi ilerledikçe her %10’luk artışta bir istatistik bilgisi görüntülenir. Bu komut, “AdventureWorks2012” veritabanını belirtilen dosya yoluna tam yedekleme olarak kaydetmektedir.
Not: Herhangi bir AG altında bulunan veritabanımızın backup’ını almak istiyorsak backup alma işlemini sadece AG yapımızı belirterek backup almamız gerekmektedir. Ne kadar AG properties ekranından backup alınacak sunucuyu değiştirsek bile secondary sunucusudan backup işlemi gerçekleşmez. Secondary sunucusunda full backup sadece copy only yöntemiyle alınmaktadır. Secondary sunucusunda log backup hem copy only hem de normal bir şekilde alınmaktadır. Diff backup ise ne copy only nede normal bir diff backup şekilde alınmaz. Tabi bunlar ag altında bulunan veritabanları için geçerli bir özelliktir.
Not: Full backuptan sonra log backuplar sadece restore edilerek veritabanı açılabilir. Bu log aralarında istediğimiz kadar full diff alalım herhangi bir sorun teşkil etmez
Yukarıdaki vermiş olduğum backup bilgilerinden sonra bir sonraki FULL-DIFF-LOG Backup ve Restore-2 makalemizde görüşmek dileğiyle..
“Onlar her türlü boş söz ve faydasız işlerden yüz çevirirler.” Mü’minûn- 3
