SQL Server Veritabanı Yedeği Geri Yükleme (Restore) Rehberi

SQL Server'da veri güvenliğinin ve iş sürekliliğinin en kritik adımı, olası bir kriz anında (donanım arızası, siber saldırı veya kullanıcı hatası) yedekleri doğru ve hızlı bir şekilde geri yükleyebilmektir.

Bu rehberde, SQL Server'da Restore işleminin mantığını, kurtarma modellerini (Recovery Models) ve adım adım veritabanı geri yükleme senaryolarını detaylıca inceleyeceğiz.

1. SQL Server Geri Yükleme (Restore) Mantığı

SQL Server'da bir yedeği geri yüklemek, sadece dosyaları kopyalamaktan ibaret değildir. Veritabanının tutarlı (consistent) bir duruma getirilmesi için arka planda ACID kurallarına uygun bir süreç işler.

Bir Restore işlemi temel olarak üç ana aşamadan oluşur:

1. Data Copy (Veri Kopyalama): Yedek dosyasındaki (.bak) tüm veri, indeks ve log sayfaları hedef veritabanı dosyalarına (.mdf, .ldf) kopyalanır.
2. Redo (Roll Forward / İleri Sarma): Yedekleme işlemi sırasında gerçekleşmiş ve onaylanmış (committed) tüm işlemler veritabanına eksiksiz uygulanır.
3. Undo (Roll Back / Geri Alma): Yedekleme bittiği sırada yarıda kalmış ve onaylanmamış (uncommitted) tüm işlemler geri alınarak veritabanının tutarlı bir ana donmesi sağlanır.

2. Kurtarma Modelleri (Recovery Models) ve Restore İlişkisi

Geri yükleme stratejinizi belirleyen en önemli unsur, veritabanınızın Recovery Model ayarıdır.

3. Adım Adım SQL Server Restore Yöntemleri

Bir veritabanını kurtarırken üç temel yedek türünü sırasıyla yüklemeniz gerekir: Full Backup $\rightarrow$ Differential Backup $\rightarrow$ Log Backups.

Senaryo: Sıralı Yedekleri Geri Yükleme

Elinizde pazar günü alınmış bir Full, çarşamba alınmış bir Differential ve her saat başı alınan Log yedekleri olsun. Perşembe saat 10:00'daki bir hatadan donmek için izlenecek yol:

Adım 1: Full Yedeğin Geri Yüklenmesi (WITH NORECOVERY)

İşleme her zaman tam yedekle başlanır. Arkadan başka yedekler geleceği için veritabanı erişime açılmamalı, yani NORECOVERY modunda bırakılmalıdır.

SQL

Adım 2: En Son Differential Yedeğin Geri Yüklenmesi (WITH NORECOVERY)

Full yedekten sonra, hataya en yakın olan en güncel differential yedek yüklenir. (Aradaki eski differential yedekleri yüklemenize gerek yoktur).

SQL

Adım 3: Sırasıyla Log Yedeklerinin Yüklenmesi (WITH RECOVERY)

Differential yedekten sonra, hedeflenen ana (Perşembe 10:00) kadar olan tüm log yedekleri sırasıyla yüklenir. En son log yedeğinde RECOVERY komutu kullanılarak veritabanı kullanıma açılır.

SQL

4. Kritik Parametreler: RECOVERY vs NORECOVERY

Restore esnasında SQL Server'a veritabanının durumunu nasıl bırakması gerektiğini söylemeniz gerekir. Bu durumlar kriz anında hayat kurtarır:

1. WITH RECOVERY: SQL Server'a "Başka yükleyecek yedeğim kalmadı, Undo aşamasını çalıştır ve veritabanını kullanıcılara aç" der. (Varsayılan ayardır).
2. WITH NORECOVERY: SQL Server'a "Arkadan başka yedek dosyaları (Diff veya Log) yüleyeceğim, veritabanını Restoring... modunda tut, erişime açma" der.
3. WITH STANDBY: Veritabanını salt okunur (Read-Only) modda açar. Arkadan log yedeği yüklemeye devam etmenize izin verirken, içerideki veriyi kontrol etmenizi sağlar.

5. SQL Server Management Studio (SSMS) ile UI Üzerinden Restore

Kod yerine arayüz kullanmak isterseniz, SSMS üzerinde adımlar şu şekildedir:

1. SSMS'te Databases klasörüne sağ tıklayıp Restore Database... seçeneğini seçin.
2. Source kısmından Device seçerek .bak dosyanızı sisteme gösterin.
3. Options sayfasına geçerek veritabanının durumunu (Recovery State) belirleyin:
4. RESTORE WITH RECOVERY (Kullanıma hazır aç)
5. RESTORE WITH NORECOVERY (Yedek almaya devam et)

6. En Çok Karşılaşılan Restore Hataları ve Cözümleri

Hata 1: "The log or differential backup cannot be restored because no files are ready to roll forward."

1. Sebebi: Bir önceki yedeği (Full veya çizgideki bir önceki logu) WITH NORECOVERY moduyla yüklemediniz veya bir sıralama atladınız.
2. Cözüm: Zinciri bozmadan, en baştaki Full yedekten itibaren tüm adımları NORECOVERY ile tekrar yükleyin.

Hata 2: "Exclusive access could not be obtained because the database is in use."

1. Sebebi: Üzerine yazmaya çalıştığınız veritabanında aktif kullanıcı bağlantıları var.
2. Cözüm: Restore etmeden önce veritabanını tek kullanıcı moduna alın veya bağlantıları koparın:
3. SQL
4. 
   

Özet

SQL Server'da başarılı bir geri yükleme süreci, doğru kurgulanmış bir yedekleme zincirine dayanır. Felaket anlarında panik yapmamak adına canlı ortamınızın yedeklerini düzenli olarak farklı bir test sunucusunda Restore ederek test etmeniz, veritabanı yöneticiliğinin (DBA) altın kuralıdır.