SQL Server Restore Rehberi: SSMS ve T-SQL ile Veritabanı Geri Yükleme

Bir backup’ın gerçekten işe yarayıp yaramadığını yalnızca restore gösterir. SQL Server’da restore işlemi; silinen verileri geri getirmekten bir veritabanını yeni bir sunucuya taşımaya, test ortamı hazırlamaktan bozulmuş bir veritabanını kurtarmaya kadar her senaryoda DBA’in elindeki son güvencedir. Ancak baskı altında, doğru sırayı ve doğru seçenekleri bilmeden yapılan bir restore, sorunu çözmek yerine kalan verinin de üzerine yazabilir.

Bu rehberde SQL Server restore işlemini baştan sona ele alıyoruz: restore öncesinde bilinmesi gerekenler, SSMS ve T-SQL ile adım adım restore, full + differential + log zinciri, belirli bir ana geri dönüş (point-in-time), tail-log backup, en sık karşılaşılan restore hataları ve restore sonrasında mutlaka yapılması gereken kontroller.

SQL Server Restore Ne Zaman Gerekir?

Restore işlemi, bir veritabanını backup dosyalarından yeniden oluşturur. En sık karşılaşılan senaryolar şunlardır:

• Kullanıcı veya uygulama hatası: filtresiz bir UPDATE ya da DELETE, yanlışlıkla silinen bir tablo. Burada amaç genellikle hatadan hemen önceki ana dönmektir.
• Donanım veya depolama arızası: disk kaybı, bozulmuş veri dosyaları, 823/824 hatalarıyla gelen corruption.
• Sunucu taşıma ve upgrade: veritabanını yeni bir sunucuya veya daha yeni bir SQL Server sürümüne backup/restore ile taşımak.
• Test ve geliştirme ortamları: production verisinin güncel bir kopyasını test ortamına almak.
• Restore testi: backup’ların gerçekten geri yüklenebildiğini ve ne kadar sürdüğünü düzenli olarak doğrulamak.

Restore Öncesinde Bilinmesi Gerekenler

Backup türleri ve restore sırası

SQL Server’da bir veritabanını geri yüklemek çoğu zaman tek bir dosyadan ibaret değildir. Restore zinciri üç tür backup’tan oluşur:

• Full backup: zincirin başlangıç noktasıdır. Her restore bir full backup ile başlar.
• Differential backup: son full backup’tan bu yana değişen her şeyi içerir. Yalnızca en son differential’ı geri yüklemeniz yeterlidir.
• Transaction log backup: son log backup’tan bu yana yapılan tüm işlemleri içerir. Differential’dan sonraki her log backup’ı, alındığı sırayla ve hiçbirini atlamadan geri yüklemeniz gerekir.

Doğru sıra her zaman şudur: full → en son differential (varsa) → sonraki tüm log backup’lar → recovery. Log zincirindeki tek bir eksik dosya, o noktadan sonrasının geri yüklenememesi demektir.

Recovery model neyi belirler?

Veritabanının recovery model’i hangi noktaya kadar dönebileceğinizi belirler. Simple recovery model’de log backup alınamaz, dolayısıyla yalnızca son full veya differential backup’ın alındığı ana dönebilirsiniz. Belirli bir saate, dakikaya dönebilmek (point-in-time restore) için full recovery model ve kesintisiz bir log backup zinciri gerekir. Bulk-logged model’de ise bulk işlem içeren bir log backup’ın ortasındaki bir ana dönülemez. Bu konuyu SQL Server’da Simple Recovery Model yazımızda ayrıntılı ele aldık.

RECOVERY, NORECOVERY ve STANDBY

Her RESTORE komutunun sonunda veritabanının hangi durumda kalacağını siz seçersiniz:

• WITH RECOVERY (varsayılan): commit edilmemiş işlemleri geri alır ve veritabanını kullanıma açar. Bundan sonra başka backup geri yüklenemez.
• WITH NORECOVERY: veritabanını RESTORING durumunda bırakır, böylece sıradaki differential veya log backup uygulanabilir. Zincirin son adımı hariç her adımda bunu kullanın.
• WITH STANDBY: veritabanını salt okunur açar ama yeni log backup’ları uygulamaya devam etmenize izin verir. Doğru geri dönüş anını ararken verinin durumunu kontrol etmek için çok kullanışlıdır.

En sık yapılan hata, zincirin ortasında yanlışlıkla RECOVERY kullanmaktır. Bu durumda kalan log backup’lar artık uygulanamaz ve restore’a baştan başlamak gerekir.

Backup Dosyasını Restore Etmeden Önce İnceleyin

Bir backup dosyasını geri yüklemeden önce içinde ne olduğunu görmek, hem hataları önler hem de zaman kazandırır. Üç komut bu iş için yeterlidir:

-- Dosyadaki backup set'leri: tür, veritabanı adı, tarih, LSN'ler, SQL Server sürümü
RESTORE HEADERONLY FROM DISK = N'E:\Backup\SalesDB_FULL.bak';

-- Backup'taki veri ve log dosyalarının logical isimleri ve orijinal yolları
RESTORE FILELISTONLY FROM DISK = N'E:\Backup\SalesDB_FULL.bak';

-- Backup set'in eksiksiz ve okunabilir olduğunu kontrol et
RESTORE VERIFYONLY FROM DISK = N'E:\Backup\SalesDB_FULL.bak' WITH CHECKSUM;

FILELISTONLY çıktısındaki LogicalName değerleri, veritabanını farklı bir klasöre veya farklı bir isimle geri yüklerken MOVE seçeneğinde kullanacağınız isimlerdir. VERIFYONLY ise backup’ın eksiksiz ve okunabilir olduğunu, varsa checksum’ları ve hedefte yeterli alan olduğunu kontrol eder. Ancak Microsoft’un da belirttiği gibi, backup içindeki verinin yapısını doğrulamaz. Bir backup’ın gerçekten sağlam olduğunu kanıtlamanın tek yolu onu geri yükleyip DBCC CHECKDB çalıştırmaktır.

SSMS ile SQL Server Restore İşlemi (Adım Adım)

Tek seferlik restore’lar için SQL Server Management Studio’nun Restore Database ekranı pratik bir seçenektir. Aşağıdaki örnekte AdventureWorks2014 veritabanını bir .bak dosyasından geri yüklüyoruz.

1. Restore ekranını açın. Object Explorer’da Databases klasörüne sağ tıklayın ve Restore Database… seçeneğini seçin. Var olan bir veritabanının üzerine geri yükleme yapıyorsanız veritabanına sağ tıklayıp Tasks → Restore → Database yolunu da kullanabilirsiniz.

2. Backup kaynağını seçin. Source bölümünde Device seçeneğini işaretleyin ve yanındaki … düğmesine tıklayın. Database seçeneği yalnızca bu sunucunun msdb backup geçmişinde bulunan veritabanlarını listeler; backup başka bir sunucuda alındıysa Device kullanmanız gerekir.

3. Backup dosyasını ekleyin. Select backup devices penceresinde Add düğmesine tıklayın.

4. Dosyayı seçin. .bak dosyasının bulunduğu klasöre gidip dosyayı seçin ve OK ile onaylayın. Bu pencerede yalnızca SQL Server servis hesabının erişebildiği klasörler görünür; dosyanızı göremiyorsanız sorun büyük olasılıkla klasör yetkisidir.

5. Restore planını kontrol edin ve scripti alın. SSMS, Backup sets to restore tablosunda geri yüklenecek backup’ları listeler. Göndermeden önce Files sayfasında dosyaların hangi klasörlere yazılacağını, Options sayfasında ise şu seçenekleri kontrol edin:

• Overwrite the existing database (WITH REPLACE): var olan bir veritabanının üzerine yazar. Yanlış veritabanında işaretlemek geri dönüşü olmayan bir hatadır.
• Recovery state: başka log backup uygulayacaksanız RESTORE WITH NORECOVERY seçin.
• Take tail-log backup before restore: var olan veritabanının henüz backup’ı alınmamış son işlemlerini korur (aşağıda anlatıyoruz).
• Close existing connections: restore için gereken özel erişimi sağlamak üzere açık bağlantıları kapatır.

OK‘a basmak yerine üstteki Script düğmesine tıklayarak SSMS’in üreteceği T-SQL komutunu yeni bir sorgu penceresinde görmenizi öneririz. Böylece tam olarak neyin çalışacağını okuyabilir, saklayabilir ve aynı işlemi tekrar yapmanız gerektiğinde kullanabilirsiniz.

T-SQL ile SQL Server Restore

Production ortamında restore’u T-SQL ile yapmak daha güvenlidir: komut tekrarlanabilir, kontrol edilebilir ve bir runbook’a yazılabilir.

Tek bir full backup’tan restore

Veritabanını farklı bir sunucuya veya farklı klasörlere geri yüklerken MOVE ile her logical dosyanın yeni fiziksel yolunu belirtin:

USE [master];

RESTORE DATABASE [AdventureWorks2014]
FROM DISK = N'C:\Backup\AdventureWorks2014.bak'
WITH FILE = 1,
     MOVE N'AdventureWorks2014_Data' TO N'D:\SQLData\AdventureWorks2014_Data.mdf',
     MOVE N'AdventureWorks2014_Log'  TO N'L:\SQLLog\AdventureWorks2014_Log.ldf',
     RECOVERY,
     STATS = 5;

STATS = 5, ilerlemeyi her %5’te bir mesaj olarak gösterir. Veritabanını farklı bir isimle (örneğin AdventureWorks2014_Test) geri yüklemek için yalnızca RESTORE DATABASE sonrasındaki ismi değiştirin ve MOVE ile yeni dosya adları verin. Aksi halde SQL Server orijinal veritabanının dosyalarının üzerine yazmaya çalışır.

Full + differential + log zinciri

Gerçek bir kurtarma senaryosunda genellikle bir zinciri geri yüklersiniz. Son adım hariç her adım NORECOVERY ile çalışır:

-- 1) Full backup
RESTORE DATABASE [SalesDB]
FROM DISK = N'E:\Backup\SalesDB_FULL_20261005.bak'
WITH NORECOVERY, STATS = 10;

-- 2) En son differential backup
RESTORE DATABASE [SalesDB]
FROM DISK = N'E:\Backup\SalesDB_DIFF_20261006_0600.bak'
WITH NORECOVERY, STATS = 10;

-- 3) Differential'dan sonraki tüm log backup'lar, sırasıyla
RESTORE LOG [SalesDB] FROM DISK = N'E:\Backup\SalesDB_LOG_20261006_0615.trn' WITH NORECOVERY;
RESTORE LOG [SalesDB] FROM DISK = N'E:\Backup\SalesDB_LOG_20261006_0630.trn' WITH NORECOVERY;

-- 4) Veritabanını kullanıma aç
RESTORE DATABASE [SalesDB] WITH RECOVERY;

Point-in-time restore: belirli bir ana geri dönmek

Saat 10:42’de birisi filtresiz bir DELETE çalıştırdıysa, veritabanını 10:41’e geri getirmek için log backup’ları STOPAT ile uygularsınız. Microsoft’un önerisine uygun olarak aynı STOPAT değerini zincirdeki her RESTORE LOG komutunda belirtin:

RESTORE DATABASE [SalesDB_Recovery]
FROM DISK = N'E:\Backup\SalesDB_FULL_20261005.bak'
WITH NORECOVERY,
     MOVE N'SalesDB'     TO N'D:\SQLData\SalesDB_Recovery.mdf',
     MOVE N'SalesDB_log' TO N'L:\SQLLog\SalesDB_Recovery_log.ldf';

RESTORE LOG [SalesDB_Recovery]
FROM DISK = N'E:\Backup\SalesDB_LOG_20261006_1030.trn'
WITH NORECOVERY, STOPAT = N'2026-10-06T10:41:00';

RESTORE LOG [SalesDB_Recovery]
FROM DISK = N'E:\Backup\SalesDB_LOG_20261006_1045.trn'
WITH NORECOVERY, STOPAT = N'2026-10-06T10:41:00';

RESTORE DATABASE [SalesDB_Recovery] WITH RECOVERY;

Tail-log backup: son işlemleri kaybetmeyin

-- Veritabanı çevrimiçiyse: tail'i yedekle ve veritabanını RESTORING durumuna al
BACKUP LOG [SalesDB]
TO DISK = N'E:\Backup\SalesDB_TAIL.trn'
WITH NORECOVERY;

-- Veritabanı açılamıyor veya hasarlıysa
BACKUP LOG [SalesDB]
TO DISK = N'E:\Backup\SalesDB_TAIL.trn'
WITH NO_TRUNCATE, CONTINUE_AFTER_ERROR;

Tail-log backup, zincirin en son uygulanan log backup’ı olur. Yalnızca veritabanını taşıyor veya bilinçli olarak üzerine yazıyorsanız ve son backup’tan sonraki işlemlere ihtiyacınız yoksa tail-log backup gerekmez.

Var olan veritabanı için özel erişim almak

Restore, veritabanına özel (exclusive) erişim gerektirir. Uygulamalar bağlıysa 3101 hatası alırsınız. Bağlantıları kesmek ve restore’u aynı oturumda, hemen ardından çalıştırmak gerekir; aradaki boşlukta başka bir bağlantı veritabanını kapabilir:

USE [master];
ALTER DATABASE [SalesDB] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;

RESTORE DATABASE [SalesDB]
FROM DISK = N'E:\Backup\SalesDB_FULL_20261005.bak'
WITH REPLACE, RECOVERY, STATS = 10;

ALTER DATABASE [SalesDB] SET MULTI_USER;

WITH REPLACE, SQL Server’ın sizi yanlış veritabanının üzerine yazmaktan koruyan güvenlik kontrollerini devre dışı bırakır. Yalnızca hedefin doğru olduğundan emin olduğunuzda kullanın.

Sık Karşılaşılan SQL Server Restore Hataları

Restore başarısız olduğunda SQL Server genellikle iki mesaj üretir: asıl nedeni söyleyen hata ve ardından gelen genel “Msg 3013: RESTORE DATABASE is terminating abnormally” mesajı. 3013’ün kendisi bir şey anlatmaz; her zaman ondan önceki mesaja bakın.

Restore Sonrası Kontrol Listesi

RESTORE komutunun başarıyla bitmesi işin sonu değildir. Özellikle başka bir sunucuya yapılan restore’lardan sonra şu kontrolleri yapın:

1. Bütünlük kontrolü: geri yüklenen veritabanında DBCC CHECKDB çalıştırın. Backup bozuk bir sayfayı da yedeklemiş olabilir. Ayrıntılar için DBCC CHECKDB’nin önemi yazımıza bakabilirsiniz.
2. Orphaned user’lar: login’ler veritabanında değil master‘da tutulur. Yeni sunucuda aynı SID ile login yoksa veritabanı kullanıcıları “sahipsiz” kalır ve uygulama bağlanamaz.
3. Veritabanı sahibi: yeni bir sunucuya restore edilen veritabanının sahibi genellikle restore’u çalıştıran login olur. Standart sahibi ALTER AUTHORIZATION ile geri verin.
4. TRUSTWORTHY: Microsoft’un belirttiği gibi, restore veya attach sonrasında bu özellik her zaman OFF olur. Uygulama buna ihtiyaç duyuyorsa bilinçli olarak tekrar açılmalıdır.
5. Compatibility level: daha yeni bir sürüme restore edilen veritabanı eski compatibility level’ı korur. Bu genellikle bilinçli bir tercih olmalıdır; değiştirmeden önce test edin.
6. Veritabanı dışındaki nesneler: SQL Server Agent job’ları, linked server’lar, login’ler, sertifikalar (TDE kullanılıyorsa sertifika restore’dan önce gerekir) backup’ın içinde değildir ve ayrıca taşınmalıdır.

USE [SalesDB];

-- Sunucuda karşılığı olan bir login'i bulunmayan kullanıcılar
SELECT dp.name AS user_name, dp.type_desc, dp.authentication_type_desc
FROM sys.database_principals AS dp
LEFT JOIN sys.server_principals AS sp ON dp.sid = sp.sid
WHERE sp.sid IS NULL
  AND dp.authentication_type_desc IN (N'INSTANCE', N'WINDOWS')
  AND dp.principal_id > 4;

-- Bir kullanıcıyı aynı isimli login'e yeniden bağlamak
ALTER USER [app_user] WITH LOGIN = [app_user];

-- Veritabanı sahibini standart hesaba vermek
ALTER AUTHORIZATION ON DATABASE::[SalesDB] TO [sa];

Restore Süresini Kısaltmak

Büyük bir veritabanında restore süresi, gerçek RTO’nuzu (kurtarma süresi hedefi) belirler. Bu süreyi en çok etkileyen faktörler şunlardır:

• Instant file initialization: SQL Server servis hesabına Perform volume maintenance tasks yetkisi verildiğinde veri dosyaları sıfırlarla doldurulmadan oluşturulur. Büyük veritabanlarında bu, restore’dan dakikalar hatta saatler kazandırır. Durumu sys.dm_server_services görünümündeki instant_file_initialization_enabled sütunundan kontrol edebilirsiniz.
• Transaction log boyutu: log dosyaları instant file initialization’dan yararlanmaz ve restore sırasında sıfırlanır. Gereğinden büyük bir log dosyası restore süresini doğrudan uzatır. Bu konuyu Transaction log’unuz çok mu büyük? yazımızda anlattık.
• Backup compression ve birden fazla dosya: sıkıştırılmış backup’lar daha az veri okur. Backup’ı birden fazla dosyaya bölmek (striping) de farklı disklerden paralel okumayı mümkün kılar.
• Kaynak konumu: yavaş bir ağ paylaşımından restore etmek, yerel diske kopyalayıp oradan restore etmekten çoğu zaman daha uzun sürer.

Uzun süren bir restore’un ilerlemesini başka bir oturumdan şu sorguyla izleyebilirsiniz:

SELECT session_id,
       command,
       percent_complete,
       estimated_completion_time / 60000 AS est_minutes_left
FROM sys.dm_exec_requests
WHERE command LIKE N'RESTORE%';

Restore Testi: Backup’ın Gerçek Sınavı

Hiç geri yüklenmemiş bir backup, bir umuttan ibarettir. Restore testini rutin hale getirmenizi öneririz:

• Kritik veritabanlarını en az ayda bir, production dışındaki bir sunucuya geri yükleyin ve ardından DBCC CHECKDB çalıştırın.
• Restore süresini ölçün ve kayıt altına alın. Kağıt üzerindeki RTO hedefiniz değil, bu ölçüm gerçek kurtarma süreniz olur.
• Test sırasında log zincirini de geri yükleyin. Yalnızca full backup’ı test etmek, log backup’lardaki sorunları ortaya çıkarmaz.
• Geçmiş restore’ları msdb üzerinden takip edin:

SELECT TOP (20)
       rh.destination_database_name,
       rh.restore_date,
       rh.restore_type,          -- D = database, I = differential, L = log
       rh.user_name,
       bs.backup_finish_date,
       bmf.physical_device_name
FROM msdb.dbo.restorehistory AS rh
JOIN msdb.dbo.backupset AS bs ON rh.backup_set_id = bs.backup_set_id
JOIN msdb.dbo.backupmediafamily AS bmf ON bs.media_set_id = bmf.media_set_id
ORDER BY rh.restore_date DESC;

Backup stratejinizi kurgularken en iyi backup planı nasıl kurulur ve SQL Server backup güvenliği için best practice’ler yazılarımız da yol gösterici olacaktır. Restore sırasında bir sorun çıkarsa ilk bakılacak yer SQL Server error log‘dur.

Sık Sorulan Sorular