Bu makalede bir önceki makalede almış olduğumuz FULL-DIFF VE LOG backup’ı restore konusunu detaylı bir şekilde görmüş olacağız. 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 nasıl yapıldığını görmüş olacağız.
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.
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. Aşağıdaki resimde dikkat edilirse ilgili veritabanı seçiminden sonra veritabanı backupları hangi türden alınmışsa gelmektedir. Sunucu üzerinde hangi dizinde olursa olsun gelmektedir. msdb..backupset tablosundan bulunabilir.
Restore işleminin ikinci seçeneği olan Device bölümünden devam edelim. Bu dizinde ise Restore edeceğimiz backup’ın hangi dizinde olduğunu kendimiz belirliyoruz.
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 restore edilecek full-diff ve log backup’taki bir tarih veya saat dilimine manuel bir şekilde dönmüş oluruz.
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 sunucuda da 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 veritabanı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 database (WITH REPLACE):
- Eğer geri yüklemek istediğin isimde bir veritabanı zaten sunucuda varsa, SQL Server normalde hata verir. Bu kutucuğu işaretlemek, “Eskisini sil, üzerine bu yedeği yaz” demektir.
- İçerideki mevcut verileri kalıcı olarak kaybedersin.
Preserve the replication settings (WITH KEEP_REPLICATION):
- Eğer veritabanın bir Replication (çoğaltma) mekanizmasına dahilse, bu ayar geri yükleme sonrasında replikasyon ayarlarının bozulmamasını sağlar.
Restrict access to the restored database (WITH RESTRICTED_USER):
- Geri yükleme bittiğinde veritabanını sadece
db_owner,dbcreatorveyasysadminyetkisine sahip kullanıcıların açabilmesini sağlar. - Veriyi açmadan önce son kontrolleri yapmak ve genel kullanıcı trafiğini engellemek için.
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 diff ve log backup’ların 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 database kısmında mevcut veritabanımızı seçtikten sonra veritabanı altında alınan tüm backup işlemlerini göstermektedir.
Manuel bir şekilde backup dizinimizi seçmek için 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): Sunucuda aynı isimle bir veritabanı zaten varsa, SQL Server normalde güvenliğiniz için geri yüklemeyi reddeder.Bu seçenek, mevcut
Restoringmodundaki yapıyı “temizlemez”, sadece o an yüklediğiniz Differential (Diff) backup’ın hedef veritabanına yazılmasına izin verir. - Prompt before restoring each backup: Birden fazla yedek dosyasını (örneğin 10 tane log yedeği) sırayla yüklüyorsan, her dosyadan önce onayını ister.
- Restrict access to the restored database (WITH RESTRICTED_USER): Geri yükleme bittiğinde veritabanını sadece yetkili kullanıcıların (
db_owner,sysadmin) girebileceği kısıtlı modda açar. Genel kullanıcılara kapatı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.
- 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.
- 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. 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 da herhangi bir ana dönüş yapabiliriz.
Options kısmına geçmeden önce en alta bulunan Marked transaction seçeneğinin ne olduğuna değinelim. Bu seçenek, bir işaretlenmiş transaction’ı geri yüklemek için kullanılır. Sayfamızda ilgili makale okunabilir.
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.
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
