Sql & Veritabanı İle Uygulamalar İçin Veri Kurtarma Senaryosu Nasıl Yapılır?

Gereksinimler ve Ön Hazırlık

Veri kurtarma süreçlerine başlamadan önce, üretim (production) ortamınızda aşağıdaki bileşenlerin hazır olduğundan emin olmalısınız. Yanlış yapılandırılmış bir yedekleme sistemi, kurtarma aşamasında verilerin tamamen kaybedilmesine yol açabilir.

• Düzenli alınan tam (Full), fark (Differential) ve işlem günlüğü (Transaction Log) yedekleri.
• Veritabanı sunucusuna yönetici (SA veya Superuser) erişimi.
• Kurtarma işlemlerini test etmek için izole edilmiş bir "Staging" veya "Test" ortamı.
• SQL komut satırı araçları (sqlcmd, psql veya mysql client).

İşlemlere başlamadan önce veritabanı sunucunuzun "Recovery Model" ayarlarını kontrol etmelisiniz. Örneğin, SQL Server üzerinde "Full Recovery Model" kullanmıyorsanız, işlem günlüğü üzerinden veri kurtarma yapmanız mümkün olmayacaktır.

Adım 1: Felaket Anında Veritabanı Durumunu Analiz Etme

Veri kaybı yaşandığı fark edildiğinde ilk yapılması gereken, veritabanını daha fazla veri kaybından korumaktır. Eğer bir tablo veya satır silinmişse, hemen veritabanını "Read-Only" (Salt Okunur) moduna alarak üzerine yeni veri yazılmasını engellemelisiniz.

-- Veritabanını tek kullanıcı moduna alarak işlemleri kısıtlayın
ALTER DATABASE MusteriDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE;

-- Veritabanını salt okunur moda getirin
ALTER DATABASE MusteriDB SET READ_ONLY;

Bu komutlar, veritabanı üzerindeki aktif bağlantıları keser ve yeni yazma işlemlerini durdurur. Böylece, kurtarma işlemi sırasında verinin değişmediğinden emin oluruz.

Adım 2: Transaction Log (İşlem Günlüğü) ile Nokta Atışı Kurtarma

Tüm veritabanını geri yüklemek yerine, sadece silinen veriyi kurtarmak isteyebilirsiniz. Transaction Log dosyaları, veritabanında gerçekleşen her değişikliği (INSERT, UPDATE, DELETE) kaydeder. Bu dosyaları inceleyerek silme komutunun tam zamanını tespit edebiliriz.

-- İşlem günlüğündeki silme operasyonunu bulmak için log analizi
SELECT 
    [Transaction ID], 
    [Operation], 
    [Begin Time], 
    [Transaction Name]
FROM sys.fn_dblog(NULL, NULL)
WHERE [Operation] = 'LOP_DELETE_ROWS';

Bu sorgu, veritabanınızdaki silme işlemlerini listeler. [Begin Time] sütununu kullanarak, verinin silinmeden hemen önceki anına (Point-in-Time) dönmek için gerekli zaman damgasını not almalısınız.

Adım 3: Full Backup ve Log Dosyalarıyla Geri Yükleme

Veritabanını belirli bir ana geri döndürmek için önce son tam yedeği, ardından log dosyalarını sırayla uygulamamız gerekir. Bu işlem, "Point-in-Time Recovery" olarak adlandırılır.

-- Son tam yedeğin geri yüklenmesi
RESTORE DATABASE MusteriDB_Kurtarma
FROM DISK = 'C:\Yedekler\MusteriDB_Full.bak'
WITH NORECOVERY, MOVE 'MusteriDB_Data' TO 'C:\Data\MusteriDB_Kurtarma.mdf';

-- Belirli bir zamana kadar log dosyasının uygulanması
RESTORE LOG MusteriDB_Kurtarma
FROM DISK = 'C:\Yedekler\MusteriDB_Log.trn'
WITH STOPAT = '2026-05-20 14:30:00', RECOVERY;

Burada STOPAT parametresi kritik öneme sahiptir. Silme işleminin gerçekleştiği saniyeden hemen öncesini belirterek verilerinizi kurtarabilirsiniz.

Adım 4: Veri Kurtarma Yöntemlerinin Karşılaştırılması

Hangi yöntemi seçeceğiniz, veri kaybının boyutuna ve veritabanı yapınıza bağlıdır. Aşağıdaki tablo, yaygın kurtarma stratejilerini özetlemektedir.

Adım 5: Kurtarılan Verilerin Doğrulanması

Veritabanı geri yüklendikten sonra, verilerin tutarlılığını kontrol etmelisiniz. Özellikle ilişkisel veritabanlarında (Foreign Key), silinen kayıtların bağlı olduğu diğer tablolardaki verilerin durumu bozulmuş olabilir.

-- Kurtarılan verilerin kontrolü
SELECT COUNT(*) FROM Siparisler WHERE SiparisTarihi > '2026-05-20';

-- Veritabanı bütünlük kontrolü
DBCC CHECKDB ('MusteriDB_Kurtarma');

DBCC CHECKDB komutu, fiziksel ve mantıksal hataları tarar. Eğer bu komut hata verirse, veritabanı yapısında bozulma var demektir ve kurtarma işlemi başarısız sayılır.

Adım 6: Güvenlik ve Önleyici Tedbirler

Veri kurtarma senaryoları, veritabanı güvenliği ile doğrudan ilişkilidir. SQL Injection saldırıları, verilerin toplu halde silinmesine neden olabilir. Uygulama katmanında parametreli sorgular kullanarak bu riskleri minimize etmelisiniz.

-- SQL Injection'a karşı güvenli parametreli sorgu örneği
DECLARE @MusteriID INT = 105;
DELETE FROM Siparisler WHERE MusteriID = @MusteriID;

Kritik Uyarı: Üretim ortamında yapılacak her türlü kurtarma işlemi öncesinde, mevcut veritabanının bir "Emergency Backup" yedeğini mutlaka alın. Yanlış bir komut, mevcut durumu daha da kötüleştirebilir.

Sıkça Sorulan Sorular

Log dosyalarım yoksa veriyi nasıl kurtarırım?

Eğer log dosyalarınız (Transaction Log) silinmiş veya üzerine yazılmışsa, veritabanı yedeğinizin olmadığı durumlarda veri kurtarma yazılımları veya veritabanı dosya (MDF/LDF) onarım araçları kullanmanız gerekir. Bu işlem garanti değildir.

Veritabanını geri yüklerken "Transaction Log full" hatası alıyorum, neden?

Bu hata, veritabanı log dosyasının dolduğunu gösterir. İşlem günlüğünü yedekleyip (backup log) boşaltmanız veya disk alanını genişletmeniz gerekir.

Point-in-Time kurtarma neden her zaman çalışmaz?

Eğer veritabanınız "Simple Recovery Model" modunda çalışıyorsa, log dosyaları sürekli temizlendiği için belirli bir ana geri dönemezsiniz. Sadece tam yedeklerinize dönebilirsiniz.

Kurtarılan veriyi ana veritabanına nasıl aktarırım?

Kurtarılan veritabanından eksik olan satırları INSERT INTO ... SELECT ... FROM ... komutuyla ana veritabanına taşıyabilirsiniz. Aktarım sırasında Primary Key çakışmalarına dikkat edin.

Yedekleme stratejimi nasıl doğrularım?

Ayda en az bir kez, aldığınız yedekleri farklı bir sunucuya restore ederek (Restore Test) yedeklerin çalışıp çalışmadığını manuel olarak kanıtlamalısınız.

Felaket Kurtarma Senaryosu: Uygulamalı Bir Örnek Senaryo

Teorik bilgilerin pratiğe dökülmesi, bir felaket anında panik yapmadan hareket etmenizi sağlar. Aşağıdaki senaryo, bir e-ticaret veritabanında yanlışlıkla silinen kritik bir tabloyu kurtarma sürecini ele almaktadır. Senaryomuzda saat 14:00'te alınan bir "Full Backup" ve ardından 14:30'da gerçekleşen "Drop Table" komutu bulunmaktadır.

Bu durumda izlenmesi gereken strateji, veritabanını 14:29:59 noktasına kadar geri döndürmektir. İşte bu işlem için kullanacağınız SQL komut dizisi:

-- 1. Adım: Mevcut veritabanının kuyruğunu yedekleyin (Tail-Log Backup)
BACKUP LOG [E-TicaretDB] 
TO DISK = 'C:\Yedekler\TailLog_Kurtarma.trn' 
WITH NORECOVERY, CONTINUE_AFTER_ERROR;

-- 2. Adım: Full backup dosyasını geri yükleyin
RESTORE DATABASE [E-TicaretDB] 
FROM DISK = 'C:\Yedekler\FullBackup_1400.bak' 
WITH NORECOVERY;

-- 3. Adım: Belirli bir zaman noktasına kadar logları geri yükleyin
RESTORE LOG [E-TicaretDB] 
FROM DISK = 'C:\Yedekler\Log_1400_1430.trn' 
WITH STOPAT = '2023-10-27 14:29:59', RECOVERY;

Veritabanı Kurtarma Süreçlerinde Performans ve Hata Ayıklama

Büyük ölçekli veritabanlarında kurtarma işlemleri saatler sürebilir. Bu süreyi optimize etmek ve olası hataları önceden tespit etmek için aşağıdaki teknikleri uygulayabilirsiniz:

• Checksum Kullanımı: Yedekleme sırasında WITH CHECKSUM parametresini kullanmak, verinin yazılma aşamasında bozulup bozulmadığını doğrular.
• Paralel Yedekleme: Büyük veritabanlarında BUFFERCOUNT ve MAXTRANSFERSIZE parametrelerini optimize ederek yedekleme hızını artırabilirsiniz.
• Hata Ayıklama: Eğer RESTORE işlemi sırasında "Log sequence number (LSN)" hatası alıyorsanız, bu durum yedekleme zincirinizin koptuğunu gösterir. Bu durumda RESTORE HEADERONLY komutu ile yedek dosyalarınızın başlık bilgilerini kontrol etmelisiniz.

Aşağıdaki sorgu, yedekleme zincirinizin kopuk olup olmadığını anlamanıza yardımcı olacak temel bir kontrol mekanizmasıdır:

-- Yedekleme geçmişini kontrol ederek zincir bütünlüğünü sorgulayın
SELECT 
    backup_start_date, 
    backup_finish_date, 
    type, 
    first_lsn, 
    last_lsn 
FROM msdb.dbo.backupset 
WHERE database_name = 'E-TicaretDB' 
ORDER BY backup_start_date DESC;

Bu sorgu, son yedeklerinizin LSN (Log Sequence Number) değerlerini listeler. Eğer last_lsn değeri bir sonraki yedeğin first_lsn değeri ile eşleşmiyorsa, yedekleme zincirinizde bir boşluk var demektir. Bu durumda, kurtarma senaryonuzun başarısız olacağını önceden anlayabilirsiniz.

Profesyonel İpucu: Kurtarma süresini (RTO - Recovery Time Objective) kısaltmak için, veritabanı dosyalarınızı (MDF/LDF) farklı fiziksel diskler üzerinde konumlandırın. Bu, I/O darboğazlarını azaltarak kurtarma hızını %30'a kadar artırabilir.

Sonuç

Sql & veritabanı ile uygulamalar için veri kurtarma senaryosu hazırlamak, sadece bir teknik beceri değil, aynı zamanda bir sorumluluktur. Adım adım uyguladığınız bu süreçler, sisteminizin dayanıklılığını artıracaktır. Bir sonraki adım olarak, veritabanı yedekleme süreçlerinizi otomatize eden "Maintenance Plan" yapılandırmalarını araştırmanızı ve felaket kurtarma simülasyonları yapmanızı öneririm.

Sorumluluk Reddi: Bu makaledeki kod örnekleri ve yöntemler genel eğitim amaçlıdır. Üretim ortamlarında uygulama yapmadan önce mutlaka yedek alınız ve test ortamlarında doğrulama yapınız. Olası veri kayıplarından yazar sorumlu tutulamaz.