SQL Server'da çalışan bir Database üzerinde Backup (yedekleme) ve Restore (geri yükleme) işlemleri, veri kaybını önlemek ve iş sürekliliğini sağlamak açısından kritik bir önem taşır. Özellikle üretim ortamında aktif olarak kullanılan bir Database'de bu işlemleri gerçekleştirmek dikkat ve planlama gerektirir. Full Backup ve Differential Backup stratejileri, çalışan bir Database'de veri kaybı yaşamadan bu işlemleri yapabilmeyi mümkün kılar. SQL Server, yedekleme ve geri yükleme işlemlerini, Database'in kullanıma kapatılmasına gerek kalmadan gerçekleştirebilir.
Full Backup, bir Database'in tamamının yedeklenmesi anlamına gelir ve çalışan bir Database'de bu işlem sırasında Database aktif olarak kullanılmaya devam edebilir. SQL Server, yedekleme işlemi sırasında Copy-on-Write mantığını kullanır; yani, yedekleme işlemi başladığında o anki Database durumu korunur ve bu esnada Database'de yapılan değişiklikler yedeklemeyi etkilemez. Bu sayede, Database üzerinde çalışan kullanıcılar veya işlemler yedekleme süresince kesintisiz devam ederken, Database'in tam bir kopyası oluşturulabilir. Ancak, büyük Database'lerde Full Backup işlemi uzun sürebileceğinden, genellikle haftalık ya da aylık olarak planlanır.
Differential Backup ise, son alınan Full Backup'tan bu yana değişen verilerin yedeklenmesini sağlar. Çalışan bir Database'de bu işlem, Full Backup'tan çok daha hızlı gerçekleşir ve daha az disk alanı kullanır. Bu durum, özellikle büyük veri setlerinde performansı artırır ve yedekleme işlemlerinin minimum kaynak kullanımıyla tamamlanmasını sağlar. Differential Backup, Database'in sürekli aktif olduğu ortamlarda veri kaybını minimize eder ve daha sık aralıklarla yedek alınmasına olanak tanır.
Restore işlemi, veri kaybı durumunda veya eski bir Database sürümüne geri dönme ihtiyacı olduğunda kullanılır. Çalışan bir Database'de geri yükleme işlemi genellikle Database'i kısa bir süreliğine Offline duruma getirir. Geri yükleme işlemi sırasında, en son alınan Full Backup ve ardından en güncel Differential Backup kullanılarak Database eksiksiz bir şekilde geri yüklenir. Bu işlem dikkatle planlanmalı ve iş sürekliliğini en az kesintiye uğratacak şekilde gerçekleştirilmelidir. Özellikle kritik Database'lerde Restore işlemi öncesinde test ortamında işlem doğrulanmalı ve tüm yedekler sağlıklı bir şekilde alınmış olmalıdır.
SQL Server'ın sağladığı online yedekleme ve geri yükleme özelliği, çalışan bir Database üzerinde operasyonel kesintiler olmadan veri güvenliğini sağlayabilir. Bu özellik, veritabanı yöneticilerine esneklik kazandırır ve Database'in kullanıma kapatılmasına gerek kalmadan düzenli yedekleme yapılmasına olanak tanır. Ancak Restore işlemi sırasında Database genellikle kısa süreliğine erişime kapatılacağından, bu işlemin iş yüküne göre dikkatlice zamanlanması önemlidir.
Çalışan bir Database'e, herhangi bir zaman diliminde tekrar Database Backup (veri tabanı yedek alma) işlemi uyguladığınızı varsayalım. Bu yedeği de mevcutta çalışmakta olan Ör. Database001 isimli çalışan veri tabanım üzerinde sağ tıklayıp sırası ile Taks > Restore > Database... seçeneklerini seçerek Restore Database – Database001 penceresi açılıp, Database Restore adımlarını tekrar uyguladığımda;
Restore of Database Failed Hatası
SQL Server arayüzünde Restore işlemi sırasında ekrana gelen Restore of database DATABASE001 failed uyarısı, genellikle işlem yapılmak istenen veritabanının o anda kullanımda olması ya da gerekli izinlerin verilmemiş olması gibi nedenlerle Restore işleminin tamamlanamamasından kaynaklanır. Backup dosyasının içeriği doğru olsa bile, hedef veritabanı aktif durumdaysa ve WITH REPLACE parametresi kullanılmadan işlem başlatıldıysa bu ekran karşına çıkar.
Bu hata genellikle var olan bir veritabanı üzerine yeniden yazılmaya çalışıldığında, işlem başlamadan önce bağlantıların kesilmemesi ya da veritabanının recovery state'inin uygun olmaması durumlarında görülür. SQL Server bu durumda otomatik olarak işlemi durdurur ve Restore penceresinin üst kısmında gösterdiği bu sarı uyarı bandı ile işlemin tamamlanamadığını belirtir.
Bu aşamada en sık atlanan detay, hedef veritabanının o anda açık olup olmadığıdır. Eğer başka bir oturumdan bağlantı varsa ya da Restore edilecek veritabanı SQL Server tarafından kilitli durumdaysa, işlem arka planda başlamış gibi görünse de tamamlanamaz. Özellikle GUI üzerinden yapılan işlemlerde bu gibi durumlarda SQL Server detaylı hata dökümünü göstermediği için kullanıcı sadece bu Progress ekranında failed mesajıyla karşılaşır.
Böyle bir durumda yapılması gereken en temel adım, veritabanına ait tüm aktif bağlantıları sonlandırmak ve Restore işlemine WITH REPLACE seçeneği ile devam etmektir. Ayrıca Backup Set'in bütünlüğü, LSN zinciri ve Restore sıralaması da bu sürecin doğru işlemesi açısından önemlidir. Geri yükleme yapılacak database daha önce NORECOVERY ile Restore edilmişse ya da tail-log alınmadan işlem yapılmaya çalışılıyorsa, SQL Server yine bu Progress penceresinde benzer bir başarısızlık mesajı gösterir.
Her ne kadar bu ekran sadece sarı bir uyarı çubuğu gibi görünse de, arkasındaki neden çoğu zaman veritabanı erişim hakları, bağlantı durumu ya da Backup yapısındaki uyumsuzluklardır. Bu yüzden Restore işlemi başlamadan önce hedef database'in durumu dikkatle kontrol edilmelidir. Hatalı her Restore denemesi, hem zaman kaybına hem de sonraki işlemlerin bozulmasına neden olabilir. Bu uyarı ekrana düştüğünde, konunun sadece GUI tarafında kalmadığını, SQL Server Engine seviyesinde işlem reddi oluştuğunu bilmek gerekir.
Restore of Database Failed Hata Çözümü
SQL Server üzerinde yapılan Restore işlemlerinde WITH REPLACE ve Restore WITH RECOVERY seçeneklerinin nasıl çalıştığını tam olarak anlamadan işlem başlatmak çoğu zaman hatayla sonuçlanır. Hedef Database zaten varsa ve aktif durumdaysa, bu seçeneklerin işaretlenip işaretlenmemesi doğrudan sürecin sonucunu belirler. Özellikle aynı isimde bir Database'e ikinci kez geri yükleme yapılacaksa, WITH REPLACE olmadan bu mümkün olmaz. Geri yükleme tamamlandıktan sonra veritabanının online olması içinse Restore WITH RECOVERY mutlaka aktif hale getirilmelidir.
Çalışır durumdaki bir Database üzerinde yedekten geri dönme işlemi yapılacaksa, Restore Database penceresinde sol menüde yer alan Select a page başlığından Options alanına geçiş yapılmalı. Bu bölümde, Restore options altında birkaç önemli seçim yer alıyor.
1- Overwrite the existing database (WITH REPLACE)
Bu seçenek, geri yükleme işlemi sırasında mevcut Database'in üzerine yazılmasını sağlar. Yani, eğer aynı isimde bir Database zaten varsa, bu Database silinir ve geri yüklenecek olan yedekle değiştirilir. WITH REPLACE komutu, mevcut Database'i zorla değiştirmek için kullanılır.
2- Recovery state: Restore WITH RECOVERY
Bu seçenek, geri yükleme işlemi tamamlandıktan sonra Database'i erişilebilir duruma getirir. Yani, geri yüklenen Database hemen erişilebilir hale gelir ve daha fazla geri yükleme işlemi yapılamaz. Restore WITH RECOVERY, Database'i normal çalışma moduna geri döndürür ve geri yüklenecek başka işlem kalmadığını belirtir.
Bu iki seçenek birlikte kullanıldığında, mevcut Database'in üzerine yazılır ve geri yükleme işlemi tamamlandıktan sonra Database, erişime açık hale gelir.
WITH REPLACE Seçeneği Seçilmezse
✔ Database Adı Çakışması: Geri yüklenecek olan yedek ile hedef Database aynı isimdeyse, SQL Server mevcut veritabanının üzerine yazmaya çalışır. Ancak WITH REPLACE seçeneği kullanılmadığında, SQL Server bunu bir çakışma olarak değerlendirir ve geri yükleme işlemini durdurur. Bu çakışmanın sonucu olarak geri yükleme işlemi başarısız olur ve mevcut Database'in korunması amacıyla üzerine yazılmasına izin verilmez.
✔ Yedek Dosyasının İkinci Defa Yüklenememesi: Aynı veritabanının yedeklerini tekrar tekrar geri yüklemeniz gerekiyorsa, her geri yüklemede WITH REPLACE seçeneğinin kullanılmaması, işlemde tutarsızlıklara ve hatalara neden olabilir. Özellikle test ortamlarında sıkça geri yükleme yapılıyorsa, bu seçeneğin atlanması işlemin sürekliliğini engeller.
WITH REPLACE seçeneği, mevcut veritabanını tamamen silip yerine yedekten geri yükleme işlemi yapmak için zorunludur. Bu seçenek işaretlenmediğinde SQL Server mevcut Database'in üzerine yazmayı engeller, bu da geri yükleme işleminin başarısızlıkla sonuçlanmasına neden olur.
Restore WITH RECOVERY Seçeneği Seçilmezse
✔ Database’in Erişime Kapatılması: Geri yükleme işlemi tamamlandıktan sonra veritabanı erişime açılmaz ve NORECOVERY modunda kalır. Bu durumda veritabanı, veritabanı yönetim sisteminde Restoring modunda görünür ve herhangi bir işlem yapılamaz. Yani, veritabanı geri yüklenmiş olsa dahi SQL Server, geri yükleme işleminin devam edeceğini düşünür ve veritabanını erişime açmaz.
✔ İşlemin Tamamlanmaması: Geri yükleme işlemi tamamlandıktan sonra Restore WITH RECOVERY komutunun verilmemesi, işlemin bitmemiş gibi algılanmasına yol açar. Veritabanını erişime açmak için bu komutun mutlaka işlenmesi gerekir. Aksi takdirde SQL Server, veritabanını geri yükleme aşamasında bırakır ve başka Transaction Log dosyalarının yükleneceğini varsayar.
Differential Backup ile Database Üzerine Restore İşlemi
Eğer elinde Differential Backup varsa ve daha öncesinde Full Backup alınmışsa, bu Full Backup üzerine Differential Backup ile alınan değişiklikleri geri yükleyebilmek için doğru adımlarla ilerlemek gerekir.
İlk geri yüklemede RESTORE WITH RECOVERY seçeneği işaretlenmemeli çünkü bu seçim yapıldığında Database erişime açılır ve başka bir backup yüklenemez. O yüzden burada RESTORE WITH NORECOVERY seçeneğini kullanıyoruz. Çünkü Differential Backup ya da Transaction Log Backup gibi ek yedekleri de yüklemeye devam etmemiz gerekiyor.
RESTORE WITH NORECOVERY seçeneği SQL Server'a yapılan restore işleminin henüz tamamlanmadığını bildirir. Bu sayede Database erişime açılmaz ve yeni yedekler sırayla yüklenebilir. Eğer burada RESTORE WITH RECOVERY seçilmiş olsaydı, işlem tamamlanmış kabul edilir ve başka backup eklenmesine izin verilmezdi.
Bu geçişi doğru yönetmek önemli. Full Backup yüklendikten sonra Differential Backup yüklenebilmesi için Database'in NORECOVERY modunda kalması gerekir. Bu durum Database'in açık işlemlerden etkilenmemesini ve veri tutarlılığının bozulmamasını sağlar.
Bu makalede, SQL Server 2014 üzerinde aktif durumda olan bir database'in üzerine, aynı isimde bir backup dosyasının GUI üzerinden nasıl overwrite edileceği adım adım gösterildi. SSMS arayüzü kullanılarak yapılan bu işlemde, Restore sihirbazı üzerinden WITH REPLACE seçeneğinin nasıl aktif hale getirileceği ve var olan .mdf ile .ldf dosyalarının değişmeden korunarak nasıl yeniden yapılandırılacağı net bir şekilde anlatıldı.
Database'in Restore işleminden önce Offline moda alınması gerektiği, aksi halde SQL Server tarafından erişim engeli nedeniyle Restore işleminin gerçekleştirilemeyeceği detaylandırıldı. İşlem sırasındaki tüm ekran görüntüleri ve yönlendirmeler, okuyucunun aynı adımları birebir uygulayabilmesi için kurgulandı.
Tüm anlatım, doğrudan pratik senaryolar üzerinden ilerleyerek, kullanıcıya herhangi bir script bilgisi gerektirmeden Restore işlemini güvenli ve hatasız şekilde tamamlama imkanı sunuyor. Bu içerik, özellikle test ortamlarında veya yeniden kurulum gereksinimlerinde aynı database'i geri yüklemek isteyen kullanıcılar için yol gösterici bir kaynak niteliğinde.
Faydalı olması dileğiyle...