Bu makalemizde sql server’da backup işleminin nasıl yapıldığını 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.
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ürlerini uygulamalı bir şekilde alıp işlemlerimize başlayalım.
Full Backup: Veritabanının tamamının yedeğini alma işlemidir. Full backup bittikten sonra diğer yedek türleri referans alınmaktadır. Bu tamamen sizlerin ihtiyacına kalmış bir işlemdir.
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.
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.
Not: Sql Server backuplarımız MS_XPRESS algoritmasıyla alınmaktadır.
Şimdi uygulamalı bir şekilde FULL, DIFF ve LOG backup alalım.
Gerçek hayattaki yapıya uygun olması açısından mevcutta 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.
Gelen Ekranda Backup Type kısmında Full backup alınacağı için Full backup seçilir.
Not: 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.
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. Filegroup backup için ilgili makale okunabilir.
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.
URL kısmı seçilirse Azure hesabımıza giriş yapıldıktan sonra backup işlemi gerçekleştirilir. Azure ortamına veritabanı backup işlemlerinin nasıl yapıldığını öğrenmek için sayfada bulunan Azure makalesinden detaylı bir şekilde öğrenilebilir. URL kısmını seçip Add dedikten sonra New container diyerek azure hesabına giriş yapılır.
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.
Birden Fazla veritabanı aynı disk altına backup işlemi yapılacaksa teker teker disk uzantısını seçmeyip sayfamızda bulunan Backup Device özelliği ile default bir uzantı set edebiliriz. Server Object kısmından ilgili bölüme erişilebilir.
File name kısmında bulunan 3 noktaya tıklayınca manuel şekilde backup yolumuzu seçip 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 sekmesinden 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. SQL Server bu seçenekle aslında yedek dosyasını “sanal olarak” geri yüklemeye çalışır. Ancak bunu yaparken verileri diske yazmaz; sadece dosyanın okunabilirliğini ve bütünlüğünü kontrol eder. 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. Bu, doğrulama işleminin en güçlü kısmıdır. Eğer yedek alırken WITH CHECKSUM seçeneğini de Verify backup when finished seçeneği ile kullanılırsa , doğrulama işlemi şunlara bakar:
- Her veri sayfası (8 KB) yazılırken bir matematiksel “parmak izi” (Checksum) oluşturulur ve sayfanın içine gömülür.
- Doğrulama sırasında SQL Server yedeği okur, sayfanın Checksum’ını o an tekrar hesaplar ve dosyanın içindeki orijinal değerle karşılaştırır.
- Eğer tek bir bit bile değişmişse (disk hatası, bit-rot vb.), Checksum’lar eşleşmez ve doğrulama “Verification Failed” hatası verir.
Eğer veritabanınızda bir tablo zaten bozuksa (Corruption varsa), SQL Server bu bozuk tabloyu “sağlam bir şekilde” yedekler ve Verify işlemi de “Her şey yolunda, bu bozuk veriyi başarıyla yedekledim” der. Bu sorunun önüne geçmek için sık sık restore yapılması veya DBCC CHECKDB komutunun çalıştırılması gerekmektedir.
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. Kullanılmaz.
Overwrite media kısmında bulunan seçenekler ne işe yarar bunlara değinelim.
Backup to the existing backup sets, seçtiğiniz hedef dosyayı (örneğin C:\veritabani\AdventureWorks2012.bak) mevcut bir “media set” olarak kabul eder ve üzerine işlem yapar.
- Append to the existing backup set:
- Mevcut yedek dosyasının sonuna yeni yedeği ekler. Eski yedekleri silmez.
- Dosya boyutu sürekli büyür. Tek bir .bak dosyasının içinde birden fazla yedek (örneğin Pazartesi, Salı ve Çarşamba yedekleri) bir arada durur.
- Geçmişe dönük farklı yedekleri tek bir dosyada toplamak içindir.
- Overwrite all existing backup sets:
- Hedef dosyanın içindeki tüm eski yedekleri siler ve sadece o anki yeni yedeği yazar.
- Dosya boyutu sadece en son yedek kadar olur.
- Disk alanından tasarruf etmek için. Genellikle “her gün sadece en son yedek kalsın” mantığında kullanılır.
Check media set name and backup set expiration, Yanlışlıkla önemli bir yedek dosyasının üzerine yazmanızı engeller. Bu bir güvenlik kilididir. Eğer dosya oluşturulurken bir “Media Set Name” verildiyseniz, isim tutmuyorsa yedekleme hata verir ve durur. Ayrıca yedeğin bir “son kullanma tarihi” (expiration) varsa ve bu tarih henüz dolmamışsa, üzerine yazılmasına izin vermez.
İlk olarak aşağıdaki resimde görüldüğü gibi Back up to a new media set… adında bir media set yapısı oluşturuyoruz.
Farklı bir zamanda Aynı dizin altında backup alacağımız zaman Check media set name and backup set expiration bölümüne yukarıda oluşturulan Media set ismini doğru girmeyince hata almamıza sebep olacaktır.
Yukarıda görüldüğü gibi media set ismi belirtmezsek backup işlemi başarılı bir şekilde alınmaktadır.
İlgili backup seçildiğinde Contents kısmında mevcut backup Media Set ismini görebiliriz.
Aşağıdaki resimde dikkat ederseniz yukarıdaki iki seçenek olan Backup to the existing backup sets ve Append to the existing backup set 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.
Yukarıda bahsettiğimiz gibi 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.
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.
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.
Full backup işlemleri sırasında backup devam ederken veritabanı üzerine yazma işlemi gerçekleşmektedir.
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.
Yukarıdaki komutla 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
GO- NOFORMAT: Bu seçenek, hedefteki yedekleme dosyasının formatlanmasını önler. Ö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.
Backup script’imizde ilgili iki ifadenin gelmesi Backup to the existing backup sets ve Append to the existing backup set ifadelerinden dolayıdır.
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.
Script’te kaldığımız yerden devam edecek olursak:
- NAME =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 teyp (tape)kasetini başa sarmayıp aynı pozisyonda bırakılır. Böylece ilk backup’tan sonra teyp başa sarılmaz ve ikinci backup hemen arkasından yazılır. Disklerde (Harddisk/SSD) veriye her an her noktadan erişebiliriz, ancak teypler bir müzik kaseti veya video kaseti gibi sıralı (sequential) çalışır.
- NOUNLOAD: Yedekleme veya restore işlemi bittikten sonra teyp ortamı (backup cihazı) dışarı çıkarılmasın. Disk yedeklemelerinde etkisi: YOK. Çünkü fiziksel bir kaset çıkartma işlemi zaten yok. Yukarıdaki NOREWIND işlemiyle bağlantılıdır.
- 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: 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: Veritabanının backup’ını alınca Restore verify only modunda olunca veritabanı backup başka bir ortama restore edilebilir. Burada olan risk veritabanı doğruluğu tam kontrol edilmediği için restore ederken hata almanıza sebep olabilir.
Yukarıdaki SSMS arayüzünden yapmış olduğumuz FULL-DIFF-LOG backup’dan sonraki belirtilen makale ile restore işlemlerimizi gerçekleştirelim. 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
