BACKUP İŞLEMİ
Merhaba arkadaşlar, Sql server’da Backup işlemleri her ne kadar basit görünse de aslında senaryolar değiştiğinde ve önemli veriler üzerinde düşünüldüğünde hayati öneme sahip bir olay olduğu anlaşılmaktadır. İnternet dökümanlarında Backup ile ilgili fazlaca kaynak bulma şansımız olsa da ben de çorbada benim de karabiberim olsun deyip bu yazıyı yazmaya karar verdim.
Backup işlemine giriş yapmadan önce SQL Server Recovery Model konusuna kısaca değinmemiz gerekir çünkü Backup alma senaryolarımız bu seçenekler çerçevesinde değişebilmektedir.Kullandığınız veri tabanının hangi modelde olduğunu veri tabanı üstüne sağ tıklayıp properties kısmından Options seçeneği altında Recovery Model alanında buabilirsiniz. Sql serverda 3 farklı recovery model vardır;
1- Full : Production ortamlarda genellikle tercih edilen yöntemdir çünkü transaction log tutma konusunda işimize en çok Full recovery model yaramaktadır. Full recovery modelde transaction logların tamamı tutulduğu için herhangi bir problem oluştuğunda ve veri tabanımızda bozulmalar gerçekleştiğinde olayın olduğu son ana ulaşabilmek için transaction loglara kesinlikle ihtiyacımız olacaktır. Full recovery modelde Transaction Loglar manual olarak silinmediği sürece kaybolmazlar.
2- Bulk-Logged: Bulk Logged Recovery Modelde Full Recovery modelden farklı olarak bulk işlmeler dışında tüm işlemler loglanırken herhangi bir bulk işlem yapıldığında tüm işlem için tek bir kayıt log dosyasına yazılır. Bu gibi durumlarda veritabanımızı herhangi bir zamana restore etmek mümkün olmaz. Bulk Logged Recovery Modelde bulk işlemler tek tek transaction log dosyasına yazılmadığı için Full Recovery modele göre bulk işlemler daha hızlı yapılır. Yani kısacası Bulk işleminden önce backup alınmayan tüm log işlemleri kaybedilir dersek çok yanlış olmasa gerek.
3-Simple: Bilinenin aksine Transaction log ları tutan fakat her checkpoint işleminden sonra transaction logları sildiği için transaction log backup alma şansımızın olmadığı modeldir bu nedenle herhangi bir veri tabanı kayıp senaryosunda istediğimiz ana ulaşma şansımız yoktur.
Dışardan aldığınız bazı Backup dosyaları Simple modda olabilir bu nedenle restore ettikten sonra özelliklerden kontrol edebilir ve isterseniz değiştirebilirsiniz. Sql serverda oluşturduğumuz yeni veri tabanları sistem veritabanımız olan Model veritabanını örnek model olarak kullandığı için yeni bir veritabanı oluşturduğumuzda Model veritabanımız hangi recovery modda ise yeni veritabanımız da aynı modda olacaktır.
Full Backup:
Şimdi Backup alma işlemlerine geçiş yapabiliriz. Management studioya giriş yaptıktan sonra Backup almak için Backup işlemini gerçekleştireceğimiz Veri tabanının üstüne sağ tıklayıp Tasks bölümünden Backup seçeneğine tıklıyoruz. Eğer Full ve Differantial backup dışında Transaction log backup alacaksanız yukarıda belirttiğimiz gibi öncelikle veritabanımızın Full recovery modda olduğuna dikkat etmemiz gerekmektedir. Küçük bir not: eğer full backup aldığınızda veritabanı simple modda olsa bile daha sonra log backup almak isterken full moda çekip devam edebilirsiniz, simple modda aldığınız backuplar mundar olmaz, ancak simple moddayken backup seçenekleri arasında Transaction log seçeneğini göremezsiniz.
Tasks kısmından Backup seçeneğini tıkladıktan sonra karşınıza aşağıdaki gibi bir pencere çıkacaktır. Ben örnek olarak AdventreWorks2016 veritabanını kullanıyor olacağım ve görüldüğü üzere Recovery modeli Full durumda. (Backup alma işleminin sadece Full Backup kısmını görsellerle anlatıp Differantial ve Transaction Log backupları sadece yazıyla anlatmaya çalışacağım)
Bu ekranda seçeneklere teker teker değinmeye çalışacağım fakat Copy-only Backup seçeneğini en son anlatacağım çünkü öncelikle backup çeşitlerinin çalışma mantığını anlamamız gerek ki böylece Copy-only backupın asıl amacını öğrenmemiz daha kolay olsun. Database kısmında hangi veritabanının backupını alacağımız görülmektedir burada sağ tık backup işlemini başka veritabanında başlatmış olsak da sonradan veritabanımızı değiştirebilir ve başka bir veritabanı için backup alabiliriz. Alt kısımda veritabanımızın modelini göstermektedir burada değişiklik yapamıyoruz, onun altında backup type seçeneğinde Full, Differantial ve Transaction log seçeneklerinden ihtiyacımız olanı seçiyoruz.
Burada şuna da değinmek istiyorum ki eğer bir Full Backup yedeğiniz yoksa aldığınız Differantial ve Transaction log backuplarınız işe yaramayacaktır çünkü her iki backup Full backup dosyasını takip etmektedir. Bu konuya Differantial ve Transaction log backup seçeneklerinde detaylı değineceğiz.
Backup component kısmında veritabanımızda nelerin backupını almak istediğimizi belirtiyoruz yani bu demek oluyor ki veritabanı için backup alırken bütün veritabanı yedeği dışında istersek oluşturduğumuz File ve Filegrouplarının da backupını alabiliriz. Biz database seçeneği ile veritabanımızın tam backupını alacağımızı belirtiyoruz.
Destination bölümünde alacağımız veritabanı backupını nereye kaydedeceğimizi soruyor disk ve url seçenekleri arasında biz diske kaydetmek istediğimiz için disk seçeneğine tıklıyoruz.
Bir alttaki kısım bize veritabanı yedeğimizin hangi adreste ve hangi isimle kayıt edileceğini göstermektedir. istersek bu adresi remove edip kendimiz yeni bir alan belirtebiliriz ancak bunu yapmazsak orada belirtmiş olduğu adresin üzerine yazıp aynı isimde olan veritabanının üstüne bizim aldığımız backupı yükleyecektir. Eğer aldığınız tüm veritabanı yedeklerinin farklı isimde görünmesini ve ayrı ayrı tutulmasını istiyorsanız buradaki adresi değiştirmeniz gerekmektedir.
Contents seçeneği çoğumuzun pek dokunmadığı, kullanmadığı bir seçenektir
Adres bilgilerini seçtiğimiz veritabanımızı seçip contents seçeneğine tıkladığımızda yukarıda bahsettiğimiz veritabanının daha önceki full backupının üzerine yazma işleminin detaylarına ulaşıyoruz, görselde de görüldüğü üzere veritabanının ilk backupından sonra üzerine yazılan backuplar görülmektedir. Bunu Backup dosyasının ‘İçindekiler’ penceresi olarak düşünebiliriz.
Media Options kısmında bize veritabanımızın backupı şekillendirme konusunda birkaç seçenek daha göstermektedir. Append to the existing backup set seçeneği seçili olduğunuzda aldığınız backup daha önce aldığınız backupın üstüne yazılır yani bir Media Set oluşturur. Bu durum contents seçeneğinde bahsettiğimiz durumu ortaya çıkarır. Ancak bu durum şöyle bir dezavantaja sebep olacaktır diyelim ki ilk aldığınız backup 1 GB boyutunda sonra backup aldığınızda eklenen verilerle veritabanı boyutunuz 1.5 GB olduysa backupı öncekinin üstüne yazdığınızda yeni backup dosyanız 2.5 GB boyutunda olacaktır.
Eğer böyle bir ihtiyacınız yoksa ve backup dosyanızın veritabanınızın şuanki boyutunda olmasını istiyorsanız bir alttaki Overwrite all existing backup set seçeneğini seçebilirsiniz böylece veritabanınızın son hali bir önceki veritabanı backup dosyanızı ezerek gerçek boyutunu oluşturacaktır. Tekrar backup seçeneklerinde contents seçeneğine tıklarsanız artık tek bir backup dosyasının olduğunu görebilirsiniz.
Alttaki media set seçenekleri de daha önce bahsettiğimiz veritabanı backuplarının üst üste alınması ve bir öncekini ezmemesi durumudur bu birkaç bacupın tek dosya içinde barındırılması media set olarak tanımlanmaktadır.
En alttaki Reliability kısmında ise backup alınırken ya da alındıktan sonra yapılması istenen durumları belirler Verify when backup finished seçeneği backup işlemi bittiğinde bu bitimi doğrulamak için kullanılır. Perform checksum before writing to media seçeneği Backup alınmadan önce hata kontrolü yapılmasını sağlar. Continue on error seçeneği ise backup alımında hata olsa bile işlemi bitirmesi istenir
Backup Options kısmına geldiğimizde ilk sırada aldığımız backupa bir isim vermemizi ister sonraki description kısmına istediğimiz açıklamayı yazabiliriz.
Backup set will expire: seçeneği genellikle backupın expire edileceği yani kendini imha edeceği tarihi belirlemek olarak anlaşılsa da aslında öyle değildir, bu seçenek daha önce bahsettiğimiz media set konusu ile alakalı yani eğer bir media setimiz var ise ve veritabanı yedeklerimiz bir öncekini ezmeden üzerine ekleniyorsa burada belirttiğimiz tarih geldiği taktirde artık üstüne ekleme daha önce bu media set içine alınan tüm backupları ezip tek backup olarak oluştur demek anlamına gelir. 0 day yazdığımız taktirde herhangi bir sınır belirtmemiş oluruz.
Compress backup: Alacağımız backupın sıkıştırılması dolayısıyla diskte çok daha az yer kaplamasını sağlar. Ancak unutulmamalıdır ki bu seçenek seçili olsa bile Sql server önce veritabanının Full backupını alır ve aldığı backupı sıkıştırıp diske yazar yani şöyle ki eğer veritabanınız 2 GB ise ve diskinizde 1 GB yer varsa ” nasılsa MBlere kadar sıkıştıracak” diyerek backup alma şansımız olmuyor çünkü sql server öncelikle 2 GB alana ihtiyaç duyacaktır.
Tüm ayarlamaları yaptıktan sonra OK seçeneğine tıkladığımız takdirde backup işlemimizin sonuç bildirimi karşımıza çıkacaktır. SQL serverda beklenmedik zamanlarda Buglarla karşılaştığımız için mümkün olduğu sürece bu tarz işlemlerinizi tüm ayarlamaları yaptıktan sonra SCRİPT seçeneğini tıklayarak işlemin scriptini çıkarıp execute ederek gerçekleştirmenizi tavsiye ederim.
Differantial Backup:
Backup işlemlerinde bir sonraki konumuz olan Differantial backup işlemine geldik. bu backup tipi bizim aldığımız son Full backuptan sonra yapılan işlemlerin backupını alır yani diyelim ki 10 gün önce Full backup aldıysak bugün alacağımız bir Differantial backup 10 gün önceki Full backuptan itibaren Differantial backup aldığımız son ana kadarki değişiklikleri içinde barındıracaktır. Yani bu 10 gün süre boyunca arada başka differantial backup almış olsanız dahi son aldığınız backup aradaki tüm Differantial backupların toplamı olarak tanımlanabilir, bu da demek oluyor ki senaryonuza göre isterseniz öncesinde aldığınız Differantial backup dosyalarınızı silebilirsiniz.
Transaction Log Backup:
Transaction Log backup işlemi yine en başında bir Full backup gerektiriyor, alınan Full backuptan sonraki Log backup Full backuptan sonra yapılan işlemlerin Logunu tutar. İlk Transaction Log backuptan sonra alınan her Log backup kendinden önceki Log backuptan sonra yapılan işlemlerin Logunu tutar. Burada sistemi bir zincir olarak düşünüp her Log dosyasını bir halka olarak ele alabiliriz bu da demek oluyor ki herhangi bir halka yani Log backup dosyası kaybolursa sonrasında gelen Log backupların hiçbir anlamı olmayacaktır. Diğer bir konu olarak; Log backuplar Full ve kendinden önceki Log backupları baz aldığı için aldığınız Differantial backuplar iki log arasındaki bağlantıya herhangi bir etki etmeyecek ve Differantial backuptan sonra alınan Transaction Log backup yine Differantial Backuptan önce alınan son Log backup ile kendi arasındaki değişikliklerin kaydını tutacaktır.
RESTORE İŞLEMİ
Backup işlemlerimiz bittikten sonra herhangi bir veri kaybı ya da veritabanı bozulması durumunda veritabanımızda istediğimiz duruma gelmek için Restore işlemlerini gerçekleştirebiliriz. Önce Restore işleminin nasıl ve hangi seçenekler çerçevesinde alındığını inceleyelim daha sonra tüm bunları bir örnekle daha iyi anlamak için değerlendiririz.
Öncelikle restore işlemimizi Full Backup Restore işlemini görselerle anlatıp kalan Restore işlemleri yazılı olarak anlatmaya çalışalım. Databases üzerine sağ tık Tasks sekmesinden Restore Database kımsında Full seçeneğini tıklıyoruz karşımıza çıkan ekranda Device seçeneğinde Restore işlemini yapacağımız backup dosyamızı belirten adresi seçiyoruz ve .bak dosyamızı ekliyoruz.
İhtiyacımız olan yani Restore edeceğimiz veritabanını seçtikten sonra karşımızda yukarıdaki gibi bir ekran ve Restore edeceğimiz veritabanının bilgilerini gösteren bir ekran görünüyor olacaktır.
Restore ekranında Files seçeneğine tıkladığımız zaman Restore edeceğimiz veritabanının veri ve log dosyalarının nerede tutulacağını belirten ekran gelmektedir. Burada sizin Sql server’ı kurarken belirttiğiniz default adres gelecektir, isterseniz Relocate all files to folder seçeneği altında bu veritabanınızın dosyaları için farklı bir yol belirtebilirsiniz. Hatta isterseniz veri ve log dosyalarınızı ayrı klasör ya da disklerde saklayabilirsiniz bu performans açısından size fayda sağlayacaktır çünkü veri giriş çıkışlarında disk I\O oranı daha az olacak verilerin diske yazılması ya da diskten okunması daha hızlı olacaktır.
Restore işleminin Options kısmında karşımıza yukarıdaki ekran çıkmaktadır. Burada Overwrite the existing database(WITH REPLACE) seçeneği restore ettiğiniz veritabanı zaten var ise yüklediğiniz restore dosyasının var olan veritabanını ezmesini sağlar. İkinci seçenek de tail log backup almasına yardımcı olur. Tail Log backup konusuna yazının devamında değineceğiz. son seçenekte restore işleminde kullanıcıların üzerine yazdığımız veritabanına olan erişimlerini kısıtlamak için kullanılabilir.
Recovery State kısmında ise eğer restore işlemimiz tek adımlık bir işlemse o zaman Restore With Recovey seçeneği ile devam ediyoruz fakat Full backupımızın üzerine Diff veya Tran Log backupları da yükleyeceksek o zaman son adıma kadar gerçekleştirdiğimiz son restore işlemine kadar her seferinde Restore With Norecovery seçeneğini seçiyoruz, bu veritabanımızın Restor modda olduğunu ve işlemin bitmediğini temsil eder ta ki son Log backupı yükleme kısmına geçene kadar son adımda tekrar Restore With Recovery seçeneğinde bırakıp restore işlemini sonlandırıyoruz ve veritabanımızın son haline ulaşmış oluyoruz.
Gelin isterseniz Full Backup, Differantial Backup ve Transaction Log Backup işlemlerini bir örnek üzerinde değerlendirelim ki anlamak daha kolay olsun.
Örneğin; Sisteminiz veritabanınızın önemi dolayısıyla her sabah 07:00’da Full backup ve her yarım saatte bir Transaction Log backup almanızı gerektiriyor ek olarak Öğlen 12:00’da ve gece 22:00’da Differantial Backup alıyorsunuz.
Diyelim ki saat 21:48’de sisteminizde bir arıza oluştu veritabanınıza hiçbir şekilde erişemiyorsunuz ve Backuplar ile veritabanınızı güncel haline getirmeniz gerekiyor; İlk adım zaten olmazsa olmaz dediğimiz Full Backupı yüklemek olacak ve sonra her yarım saatte bir Transaction Log Backup aldığımızı söylemiştik istersek adım adım sırarıyla 21:30’a kadar olan tüm Transaction Log Backupları yükleyebiliriz fakat biz saat 12:00’da Differantial Backup aldığımız için saat 07:00 ile 12:00 arasındaki tüm işlemler zaten bu Backupta kayıtlı olacağı için aradaki Transaction Log backuplarla uğraşmamız gerekmeyecek ancak 12:00 ile 22:00 arasında başka Differantial backup olmadığı ve problemi 21:48’de yaşadığımız için 12:00’dan sonraki tüm Transaction Log Backupları sırasını karıştırmadan ve herhangi birini atlamadan yüklememiz gerekmektedir.
Peki madem her yarım saatte bir Log backup alıyoruz ve problem öncesi son Log backupımız 21:30’da alınmış durumda o zaman 21:30 ile 21:48 arasındaki verilerimiz ne olacak kayıp mı etmiş oluruz diye bir soru sorulabilir. İşte bu evrede karşımıza Tail Log Backup kavramı çıkmaktadır.
Tail Log Backup: Veritabanımızda herhangi bir sorunla karşılaştığımız zaman aldığımız backuplardan geri dönmek isteriz ve ilk olarak Full backupı restore ederiz Sql server restore işlemine başladığımız zaman bize bu işlem başlatılmadan önce Tail Log Backup alma seçeneği sunar bu da son Log backupımızdan sonra yapılan değişiklikleri kapsayan backup anlamına gelir eğer restore işlemine başlamadan önce son olarak bir Log backup daha alma şansımız olursa o zaman Tail log backupa herhangi bir ihtiyacımız olmaz çünkü zaten veritabanımızın son haline kadar tüm kayıtları yedeklemiş oluruz. Restore işlemine başlarken Options kısmında Tail Log Backup seçeneğini tıklarsak Sql server belirttiğimiz klasöre bir log dosyası daha yazar bu aslında Full- Diff-Tran backuplarımızın tamamının son adımı anlamına gelir yani restore işlemlerinde en son bu dosyayı yükleyip veritabanımızı Recovery moda çekebiliriz.
Copy-Only Backup: Veritabanı için Log backup aldığımızda her backup bir lsn zincirine dahil edilir ve birbirini takip eder bu nedenle restore işleminde herhangi bir Transaction Log backupı eksik bırakma şansımız yoktur çünkü sql server bize lsn zincirinde eksik bir backup olduğu için restore işlemini gerçekleştiremediğini belirtir. bu yüzden eğer acil bir Log veya Full backup ihtiyacımız olursa ve var olan lsn zincirine etki etmek istemiyorsak Copy-only backup alırız. Şöyle düşünelim; bir firmada full ve log backuplar alınıyor biz bu firmaya danışmanlığa gittiğimizde bir log backup alıp işimiz bitince sileceğiz eğer normal tarzda bir log backup alıp sonra işimiz biitnce silersek ileri bir tarihte veritabanında bir problem çıktığında firmanın ilgili veritabanı sadece bizim log backup aldığımız tarihe kadar yüklenebilir ondan sonraki tüm log backuplar işlenemez hale gelecektir. işte böyle bir durumda eğer aldığımız Log yada Full backupımızı Copy-only tarzda alırsak işimiz bittiğinde silsek ya da başka klasöre taşısak dahir sonraki durumarda restore işleminde herhangi bir sorun olmayacaktır.
Celal Akay 