Backup’ın veritabanımızın yedeği olduğunu önceki makalemizde belirtmiştik. Yedeği alınan bu backup’ın kurulu olan sql server instance üzerine dönme işleminede restore olarak adlandırmaktayız.
Önceki makalemizde alınmış olan full diff ve log backupların gerçek veritabanımızda herhangi bir sorun olduğu için restore işlemine geçiyoruz.
SSMS üzerinde Databases sekmesine sağ tıklayıp Restore Database diyiyoruz.
Gelen ekranda Device bölümünde bulunan 3 noktaya tıklayıp veritabanımızın full backup’ını seçiyoruz.
Not: Database’i seçersek msdb üzerindeki alınmış backup tarihçesinden istediğimiz backup’ı seçerek restore işlemini gerçekleştirebiliriz. Fakat backup belirtilen path üzerinde hala bulunmuyorsa restore işlemi fail edecektir.
Gelen ekranda backup dosyamızın olduğu klasöre gidip ilgili backup dosyamızı seçiyoruz.
İlgili bak uzantısını seçtikten sonra gelen ekranda Destination kısmında farklı bir veritabanı ismi verebiliriz. Ben ismini AdventureWork2023 yaptım.
Restore to kısmında en son alınan backup zamanını göstermektedir. Bu kısımda sağ tarafta bulunan Timeline ifadesine tıklarsak en son alınan full backuptan önceki bir tarih veya saat dilimine manuel bir şekilde dönmüş oluruz. Sadece göstermek için herhangi bir değişiklik yapmıyorum.
Aşağıdaki ifade ise database recovery advisor olarak karşımıza çıkmaktadır. Full diff log backupları aynı anda yüklersek bize hangi an en uygunsa o ana dönmemiz sağlıyor. Log backup restore ederken point in time ifadesinin gelişmiş hali diyebiliriz.
Full diff ve log backup’ları yüklersek aşağıdaki resimde görmüş olduğumuz gibi istediğimiz ana dönebiliriz. Ben makalenin daha detaylı olması açısından uzun tutuyorum.
Sadece full diff ve log backup’ların aynı anda yüklenmesi için aynı path’te olması şart değildir full backup A diskinde log diff backup farklı disklerde olabilmektedir.
Yukarıdaki bilgilerden sonra kaldığımız yerden devam edelim. Aşağıdaki resimde Sağ alt tarafta bulunan Verify Backup Media ifadesi yukarıdaki seçmiş olduğumuz bak ifadesinin doğruluğunu teyit eder.
General sekmesinde sonra bir alt sekmesinde bulunan Files sekmesine geçiyoruz.
Bu sekmede default olarak mdf ve ldf dosyalarımızın konumlanacağı yollar belirtilmiştir. Yukarıdaki gibi default değerlerinin gelinmesini istemiyorsanız instance seviyesinde ayarlama yapılır veya sql server kurulumunda default path’lerin yolunun belirtilmesi gerekmektedir. AlwaysOn yapılarında iki sunucudada disk yollarının aynı uzantıda olması gerekir. Bu yüzden bu kısım gereksiz gözükse de hayati önem taşır. Çünkü primary veritabanında yeni bir data file veya filegroup eklenmesi yapının bozulmasına sebebiyet verecektir. Secondary veritabanı suspect moduna düşer.
Biz Relocate all files to folder diyerek belirlemiş olduğumuz path bilgilerini yazıyoruz.
DATA ve LOG dosyalarının aynı disk altında olmaması önerilir. Test ortamı olduğu için herhangi bir sakıncası yok.
Bu ayarlamaları yaptıktan sonra Options kısmına geçiyoruz. Overwrite the existing ile başlayan seçenek mevcut var olan bir veritabanının üzerine yazmak istediğinizde seçmeniz gereken seçenek.
Daha sonra Recovery State’den veritabanımızın hemen ayağa kalkmasını istiyorsak restore with recovery seçilir. Full backup’ı yükledikten sonra diff veya log backupları yükleyeceksek yani veritabanımızın ayağa kalkmasını istemiyorsak restore with norecovery kısmının seçilmesi gerekmektedir. Biz bu örneğimizde full backup’ı yükledikten sonra üzerine yedeklemeleri yükleyeceğimiz için restore with norecovery kısmı seçilir.
Bu işlemleri yaptıktan sonra sol üst köşede Script kısmına tıklanır.
USE [master]
RESTORE DATABASE [AdventureWorks2023] FROM DISK = N'C:\veritabanı\AdventureWorks2012.bak' WITH FILE = 1, MOVE N'AdventureWorks2012' TO N'C:\YY\AdventureWorks2023.mdf',
MOVE N'AdventureWorks2012_log' TO N'C:\YY\AdventureWorks2023_log.ldf', NORECOVERY, NOUNLOAD, STATS = 5
GO
Full backup yükleme işlemini tamamladık. Norecovery yaptığımı için veritabanımız restoring modunda bu moda almamızın sebebi üzerine bazı backupların daha geleceğini belirtiyoruz.
Diff backup işlemini yapmak için database üzerine sağ tıklayıp Task>Restore>Files and filegroups sekmesine tıklanır.
Gelen ekranda From device bölümünde diff backup’ımız seçilir.
Options kısmında mevcut database’in üzerine yazma işlemimiz olduğu ve veritabanımızın üzerine log backuplar yükleneceği için yani veritabanımızı hala restoring modunda kalmasını istiyorsak restore with norecovery kısmı seçilir.
Overwrite the existing database (WITH REPLACE) – Bu seçenek, mevcut veritabanının üzerine yazar. Eğer yedeklenmiş veritabanı dosyası hali hazırda kullanılan bir veritabanı ile aynı isimdeyse, mevcut veritabanı silinir ve yerine yedeklenmiş veritabanı yazılır.
WITH REPLACE komutu, veritabanını zorla geri yüklemeyi sağlar. Bu, özellikle var olan bir veritabanını geri yüklemek istediğinizde kullanılır, çünkü aksi takdirde SQL Server veritabanını korumak için bu işlemi engelleyebilir.
Prompt before restoring each backup Her bir yedek geri yüklenmeden önce kullanıcıdan onay isteyen bir seçenek. Çoklu yedek dosyalarını geri yüklerken her aşamada kullanıcıdan izin alınmasını sağlar.
Restrict access to the restored database (WITH RESTRICTED_USER) Geri yüklenen veritabanına yalnızca sınırlı sayıda kullanıcı (sysadmin, db_owner ve dbcreator gibi roller) erişebilir. Bu, geri yükleme işlemi sonrasında veritabanına genel erişimi kısıtlamak amacıyla kullanılır.
Leave the database ready for use by rolling back the uncommitted transactions (RESTORE WITH RECOVERY) Bu seçenek, geri yükleme işlemi bittikten sonra veritabanını kullanıma hazır hale getirir. Tamamlanmamış işlemler geri alınır ve veritabanı erişime açılır. Yedekleme işlemi bittiğinde veritabanı çalışır durumda olur ve başka log dosyalarının geri yüklenmesine izin verilmez.
Leave the database non-operational and don’t roll back the uncommitted transactions (RESTORE WITH NORECOVERY) Bu seçenek, geri yükleme işlemi tamamlandığında veritabanını çalışmaz halde bırakır ve tamamlanmamış işlemler geri alınmaz. Veritabanı “restoring” modunda kalır ve ek transaction log yedeklerinin geri yüklenmesine izin verir. Bu, genellikle ardışık transaction log yedeklerini geri yüklerken kullanılır.
Leave the database in read-only mode (RESTORE WITH STANDBY) Veritabanını yalnızca okuma modunda geri yükler. Tamamlanmamış işlemler geri alınır, ancak rollback (geri alma) bilgileri saklanır, böylece gerektiğinde işlemler geri alınabilir. Bu modda, veritabanına yalnızca okuma erişimi sağlanır ve gelecekteki transaction log yedeklerinin geri yüklenmesi mümkündür. Bu ayarlarla, geri yükleme işlemi sırasında veritabanının nasıl yönetileceğine karar verebilirsiniz. Bu modda veritabanı standby-readonly modda açılmakta kullanıcılar okuma işlemini yapabilir. Daha sonra veritabanı üzerine sağ tıklayıp task restore kısmından kalan log backupları recovery modda yüklenir.
Aşağıdaki adımda log backup standby modunda restore edilir.
Yukarıdaki yaptığımız işlemlerde veritabanı standby modunda açıldı tekrardan üzerine log backupları standby modunda yükleyebiliriz. Yada recovery modda yükleyip veritabanımızı ayağa kaldırabiliriz.
Şimdi kaldığımız yerden devam edelim.
Bu işlemleri yaptıktan sonra script’imizi alıyoruz.
RESTORE DATABASE [AdventureWorks2023] FILE = N'AdventureWorks2012' FROM DISK = N'C:\veritabanı\AdventureWork2012_DIFF.bak' WITH FILE = 1, NORECOVERY, NOUNLOAD, REPLACE, STATS = 10
GOVeritabanımızın hala restoring modda olduğunu görmüş oluyoruz.
Diff backup’ı yükledikten sonra şimdi ise log backuplarımı yükleyip veritabanımı ayağa kaldırmada.
İlgili database üzerine sağ tıklayıp Task>Restore>Transaction Log sekmesine tıklanır.
From previous backups of database: Bu seçenek, veritabanının daha önce alınmış transaction log yedeklerini geri yüklemeyi sağlar. SQL Server, mevcut veritabanı yedeklerinden transaction log yedeklerini alabilir. Bu verileri default olarak belirlenen alandan alır.
Gelen ekranda From device kısmından işaretli olan 3 noktaya tıklanır.
Gelen ekranda Add sekmesine tıklanır.
Burada önceden transaction log backup’ı nereye almışsak ilgili dizine gidilir. İlgili log dosyası seçilir.
Transaction log dosyaları halkanın bir zinciri gibi birbirlerine bağlıdır. Herhangi bir log dosyası atlanarak restore işlemi yapılamaz. Çünkü her log dosyasının bir LSN değeri vardır ve birbirlerini takip eder. Transaction log dosyalarıyla ilgili detaylı bilgi almak istiyorsak Transaction Log Dosyası Nedir adlı makaleyi okumanızı öneririm.
Yukarıdaki açıklamayı göstermek adına ilk dosyasını değil de ikinci log dosyasını restore edelim. Bakalım nasıl bir senaryoyla karşılaşacağız.
Ok tuşuna basıp restore etmeye çalıştığımızda hata mesajıyla karşılaşırız. Yukarıda bahsetmiştim. Bunun sebebi ise log backup dosyalarının birbirini bir zincir halkası gibi bağlı olmasıdır. Bununla ilgili makaleyi sayfamızın arama kısmında görebiliriz.
Tekrar kaldığımız yerden devam edip ilk log dosyamızı seçiyoruz. Log dosyası seçimi yaptıktan sonra işaretlenmiş olan restore kısmında checkboxs’ı işaretliyoruz.
Daha sonra alt kısımda bulunan point in time kısmının ne işe yaradığına değinelim.
Point in time işlemi örneğin bizim restoring modda olan database üzerine en son alınan log backup tarihinden önceki bir alana dönebiliriz. Point in time ifadesindeki 3 noktaya tıklıyoruz.
Bu ekranda log backup hangi tarihte alınmışsa o tarihten önceki yedeğe dönebiliriz.
Backup tarih ve zamanı öğrenmek için seçmiş olduğumuz log dosyasının yanındaki backup tarih ve zamanına bakabiliriz.
Sadece bir log backup alıp işlemi sonlandıra bilirdim. Elimden geldiğince seçenekleri açıklamaya çalışıyorum. Script’ini aldığımızda STOPAT komutuyla hangi ana dönüleceğini belirtiyoruz.
RESTORE LOG [AdventureWorks2023] FROM DISK = N'C:\veritabanı\AdventureWork2012_LOG.trn' WITH FILE = 1, NORECOVERY, NOUNLOAD,
STATS = 10, STOPAT = N'2024-09-13T22:20:32'
GOOptions kısmına geçmeden önce en alta bulunan seçeneğin ne olduğuna değinelim.
Marked transaction: Bu seçenek, bir işaretlenmiş transaction’ı geri yüklemek için kullanılır. SQL Server’da belirli transaction’lara işaret konulabilir ve bu seçenekle o işarete kadar olan transaction’lar geri yüklenir. Bu seçenekler, özellikle transaction log yedeklemelerinin geri yüklenmesinde ve bir veritabanının belirli bir anına geri dönülmesinde önemlidir.
Bu adımı açıkladıktan sonra sol tarafta bulunan Options seçeneğine gelip veritabanının recovery modu seçerek ayağa kalkmasını sağlıyoruz. No recovery mod seçip veritabanımızı restoring modda bırakıp üzerine diğer log’ları dönebilirdik. Veritabanımızı hemen ayağa kaldırıp sonucu gözlemleyelim.
Aşağıda seçilen işlemler haricinde diğer bölümlerin açıklamasını diff backup’ı restore ederken açıklamıştık.
Bu ifadeyi seçtikten sonra script’ini alıp çalıştıralım.
RESTORE LOG [AdventureWorks2023] FROM DISK = N'C:\veritabanı\AdventureWork2012_LOG.trn' WITH NOUNLOAD, STATS = 10
GOArtık veritabanımız restoring moddan çıktı.
Oluşturmuş olduğumuz BACKUP_TABLE tablomuza select çekelim bakalım en son hangi veriler elimizde var. Sorgu sonucumuzda 338 verimizin geldiğini görmüş oluyoruz.
Bir önceki backup makalemizde tabloya kayıt atan job’ı durdurmuştuk. Tabloda en son kaç veri olduğunu gözlemlemiştik. Şimdi önceki tablomuzdaki ekran resmini alıyoruz.
Gerçek veritabanımızda 383 veri olduğunu görüyoruz. Şimdi restore ettiğimiz veritabanına ikinci log backup’ı veya 3. Log backup’ı yüklemiş olsaydık daha fazla verimiz olmuş olacaktı ve veri kaybımızı minimize etmiş olacaktık.
İki makaleden oluşan bu makalelerimizde FULL-DIFF-LOG backup’ın nasıl alındığını ve RESTORE edildiğini görmüş olduk. Ayrıca backup ve restore işlemlerinde ne gibi ayarlamaların yapıldığını görmüş olduk.
NOT: Sorun Secondary sunucusuna diff backup restore edildikten sonra primary sunucusunda log backupların neden bazı durumlarda secondary sunucusuna restore etmeden Primary ve secondary sunucusunda senkron işlemi oluyor. Bunun açıklamasını yapalım. Bunun olası nedeni, Always On replikasyonunun DIFF restore sonrası direkt senkronizasyon yapmasıdır.
Soru aşağıdaki adımlarda belirtiliyor.
- Full Backup’ı ve DIFF Backup’ı NORECOVERY modunda Secondary’ye yükledin.
- DIFF restore devam ederken Primary’de 2 adet LOG backup alındı.
- Sen DIFF restore’ü tamamladığında, bu iki LOG backup’ı yüklemedin ama Secondary Always On’a dahil oldu.
- Herhangi bir LSN hatası almadan direkt olarak senkron oldu.
Bu senaryonun olası sebebi:
- DIFF backup yüklenirken, Primary ve Secondary sunucu zaten aynı Full Backup’tan başlatıldığı için LSN chain kopmadı.
- Always On, DIFF restore sonrası Secondary sunucuyu asenkron (catch-up) moduna alarak replikasyonu başlattı.
- Primary ile Secondary arasında DIFF sonrası oluşan fark, Always On’un redo log mekanizmasıyla otomatik olarak senkronize edildi.
- SQL Server, LOG backup restore etmek yerine, Always On’un kendi log gönderme mekanizmasını kullanarak Secondary’yi güncelledi.
Sonuç:
- Primary’de alınan 2 LOG backup’ı restore etmeden de Secondary, Always On’a dahil oldu çünkü Always On kendi log replike mekanizmasını kullandı.
- Bunun olmasını sağlayan temel mekanizma, DIFF restore sonrası LSN zincirinin bozulmaması ve Always On’un redo mekanizmasının devreye girmesidir.
- Bu yüzden, DIFF restore sonrası log backup restore etmene gerek kalmadan sistem otomatize şekilde güncellendi.
Not: FULL backup ardından log backuplar daha sonra bir full backup ve ardından tekrardan log backuplar alınırsa ilk full backuptan sonra tüm loglar yüklenerek veritabanı ayağa kaldırılır. Loglar birbirine bağlıdır. Arada full backup olması sıkıntı teşkil etmez. İkinci full backuptan sonra diğer loglarda devam ettirilir.
Başka bir makalede görüşmek dileğiyle. Kalın sağlıcakla.
“Size verilen her şey ancak dünya hayatının gelip geçici menfaatidir. Allah katındaki nimetler ise inanıp yalnızca Rablerine güvenip dayananlar için her bakımdan daha hayırlı ve daha devamlıdır.” Şûrâ -36
