SQL Server Yedekleme Stratejisi: Recovery Model ve Log Yedekleri

Muhasebeden telefon gelir: “Saat 14:20’de birisi yanlış bir güncelleme çalıştırdı, o ana dönebilir miyiz?” Elinizde yalnızca gece alınmış VM imajı varsa cevap “dün geceye dönebiliriz”dir ve bu çoğu zaman kabul edilmez. İmaj yedeği sunucunun tamamen kaybını karşılar; belirli bir ana dönüşü değil. Aşağıda recovery model seçimini, tam, fark ve transaction log yedeklerinin birlikte nasıl çalıştığını, belirli ana dönüşü, log dosyasının neden büyüdüğünü ve imaj yedeğiyle yerel SQL yedeğinin çakıştığı noktaları T-SQL örnekleriyle anlatıyoruz.

Recovery model seçimi

Recovery model, transaction log’un nasıl yönetileceğini ve hangi geri yükleme seçeneklerinin mümkün olduğunu belirler. Yanlış model, yanlış RPO demektir.

Karar kuralı basit: veritabanının RPO’su tam veya fark yedeği aralığından kısaysa FULL model gerekir. Bir günlük RPO kabul ediliyorsa SIMPLE modelde kalıp log yönetimi yükünden kurtulursunuz. Sahada sık rastladığımız tablo ise tersidir: model FULL, ama log yedeği işi hiç kurulmamış. Modeli kontrol etmek ve değiştirmek için:

SELECT name, recovery_model_desc, log_reuse_wait_desc
FROM sys.databases;

ALTER DATABASE [Satis] SET RECOVERY FULL;

SIMPLE’dan FULL’a geçiş log zincirini hemen başlatmaz. Zincir, geçişten sonra alınan ilk tam (veya fark) yedekle başlar; o yedek alınana kadar veritabanı fiilen SIMPLE gibi davranır. Modeli değiştirdikten hemen sonra tam yedek alın.

Yedek türleri ve zinciri

• Tam yedek: Veritabanının tamamını ve tutarlı geri yükleme için gereken log bölümünü içerir. Diğer yedeklerin başlangıç noktasıdır.
• Fark (differential) yedek: Son tam yedekten bu yana değişen extent’leri içerir. Kümülatiftir: geri yüklemede yalnızca en son fark yedeği gerekir.
• Transaction log yedeği: Bir önceki log yedeğinden bu yana yazılan log kayıtlarını içerir. Kesintisiz bir zincir oluşturur; aradaki tek bir log yedeğinin kaybı, sonraki tüm log yedeklerini geri yüklemede kullanılamaz hale getirir. Bir halka eksikse zincir orada biter.
• COPY_ONLY yedek: Zincirin sıralamasını etkilemeyen bağımsız yedek. Copy-only tam yedek fark yedeğinin tabanını değiştirmez; copy-only log yedeği log’u kesmez.

Fark yedekleri her zaman son normal tam yedeğe göre alınır. Başka bir araçla alınan ve copy-only olmayan bir tam yedek, fark yedeklerinizin tabanını sessizce değiştirir; geri yükleme gününe kadar kimse fark etmez. İmaj yedeği bölümünde buna döneceğiz.

Örnek yedekleme planı

RPO’su 15 dakika olan bir üretim veritabanı için tipik bir plan: haftada bir tam, her gece fark, her 15 dakikada log yedeği. Yedekler sunucunun yerel diskinde değil, ayrı bir depoda durmalı. Sunucuyla birlikte kaybolan yedek, yedek değildir.

-- Pazar 01:00 tam yedek
BACKUP DATABASE [Satis]
  TO DISK = N'\\yedek01\sql\Satis\Satis_FULL_20261108.bak'
  WITH COMPRESSION, CHECKSUM, STATS = 10;

-- Pazartesi–Cumartesi 01:00 fark yedeği
BACKUP DATABASE [Satis]
  TO DISK = N'\\yedek01\sql\Satis\Satis_DIFF_20261110.bak'
  WITH DIFFERENTIAL, COMPRESSION, CHECKSUM;

-- Her 15 dakikada log yedeği
BACKUP LOG [Satis]
  TO DISK = N'\\yedek01\sql\Satis\Satis_LOG_202611101415.trn'
  WITH COMPRESSION, CHECKSUM;

Dosya adlarını SQL Server Agent iş adımında tarih-saatle üretebilir veya yaygın kullanılan bakım betiklerinden yararlanabilirsiniz. Şart olan iki şey var: her yedek ayrı dosyaya yazılır ve CHECKSUM kullanılır. CHECKSUM ile SQL Server sayfa sağlama toplamlarını yedek sırasında doğrular ve yedeğe kendi sağlama toplamını ekler. İlk kurulumda en sık gördüğümüz arıza ise yetkidir: işi çalıştıran SQL Server servis hesabının hedef paylaşıma yazma izni yoksa yedek “Operating system error 5 (Access is denied)” hatasıyla düşer. Planın yedek depolama boyutuna etkisini hesaplamak için yedek depolama kapasite hesabı yazısındaki yöntem kullanılabilir.

Belirli bir ana geri dönüş

Senaryo: 10 Kasım 14:22’de hatalı bir UPDATE çalıştırıldı ve yaklaşık bir saat sonra fark edildi. İlk refleks üretim veritabanının üzerine geri yüklemek olur. Yapmayın. Veriyi ayrı bir adla 14:21 anına geri yükleyin ve etkilenen kayıtları karşılaştırarak düzeltin; aradaki bir saatte girilen doğru kayıtlar böylece korunur.

1. Önce son log yedeğini alın; böylece olay anını kapsayan log kayıtları zincire girer.
2. Son tam yedeği NORECOVERY ile yeni bir veritabanı adına geri yükleyin.
3. Son fark yedeğini NORECOVERY ile uygulayın.
4. Fark yedeğinden sonraki log yedeklerini sırayla uygulayın; olay anını içeren log yedeğinde STOPAT kullanın.
5. Veritabanını RECOVERY ile açın ve veriyi karşılaştırın.

RESTORE DATABASE [Satis_1421]
  FROM DISK = N'\\yedek01\sql\Satis\Satis_FULL_20261108.bak'
  WITH MOVE N'Satis' TO N'D:\Data\Satis_1421.mdf',
       MOVE N'Satis_log' TO N'L:\Log\Satis_1421.ldf',
       NORECOVERY, STATS = 10;

RESTORE DATABASE [Satis_1421]
  FROM DISK = N'\\yedek01\sql\Satis\Satis_DIFF_20261110.bak'
  WITH NORECOVERY;

-- 01:00 sonrasındaki log yedekleri sırayla...
RESTORE LOG [Satis_1421]
  FROM DISK = N'\\yedek01\sql\Satis\Satis_LOG_202611101430.trn'
  WITH STOPAT = '2026-11-10T14:21:00', NORECOVERY;

RESTORE DATABASE [Satis_1421] WITH RECOVERY;

MOVE ile kullanılacak mantıksal dosya adlarını RESTORE FILELISTONLY ile öğrenin. Tüm veritabanı olay anına döndürülecekse (örneğin fidye veya ciddi bozulma) son log yedeği BACKUP LOG ... WITH NORECOVERY ile alınır; bu “tail-log” yedeği veritabanını geri yükleme durumuna alır ve son işlemlerin kaybolmasını önler. Veri dosyaları hasarlıysa NO_TRUNCATE seçeneği eklenir. Tail-log’u atlamak, son dakikaları kendi elinizle silmektir.

Log dosyası neden büyür

Gece yarısı “L: diski doldu” alarmı geldiğinde sebep çoğunlukla aynıdır: FULL modelde log yedeği alınmıyor. Ama tek sebep bu değil. Tahmin etmeyin; SQL Server, log’un neden yeniden kullanılamadığını log_reuse_wait_desc sütununda zaten söylüyor:

Log kullanım oranını görmek için DBCC SQLPERF(LOGSPACE);, sanal log dosyası (VLF) sayısını görmek için SQL Server 2016 SP2 ve sonrasında SELECT COUNT(*) FROM sys.dm_db_log_info(DB_ID('Satis')); kullanılabilir. Küçük otomatik büyüme adımları binlerce VLF üretir ve geri yükleme ile açılıştaki kurtarma süresini uzatır. Log dosyasının başlangıç boyutunu ve büyüme adımını sabit MB değerleriyle planlayın; yüzdelik büyüme ayarını kaldırın.

İmaj yedeği ile yerel yedeğin birlikte kullanımı

Birçok sistem altyapısında SQL Server VM’i Veeam gibi bir araçla uygulama farkında (VSS tabanlı) imaj olarak yedeklenir, DBA ekibi de yerel SQL yedekleri alır. İki yöntem birlikte çalışır, ama kimin neyi yönettiği yazılı olmalıdır. İki sahipli zincir sahipsiz kalır.

• Fark yedeği tabanı: VSS yazıcısı üzerinden alınan imaj yedeği, copy-only olarak işaretlenmedikçe SQL Server açısından normal bir tam yedektir ve fark yedeklerinin tabanını değiştirir. Yerel fark yedekleri kullanılıyorsa imaj aracında copy-only seçeneğini etkinleştirin.
• Log sahipliği: Log yedeklerini yalnız bir araç almalıdır. İmaj aracı log kesme (truncate) veya kendi log yedeği seçeneğiyle yapılandırılmışken yerel log yedekleri de alınıyorsa zincir iki farklı konuma bölünür ya da kırılır. Ya imaj aracı logları yönetir ve yerel log yedeği alınmaz ya da imaj aracı log’a dokunmayacak şekilde ayarlanır.
• Geçmişin kontrolü: Hangi aracın ne zaman yedek aldığını msdb geçmişinden görebilirsiniz.

SELECT TOP (50) bs.database_name, bs.type, bs.is_copy_only,
       bs.backup_start_date, bs.first_lsn, bs.last_lsn,
       bmf.device_type, bmf.physical_device_name
FROM msdb.dbo.backupset AS bs
JOIN msdb.dbo.backupmediafamily AS bmf
  ON bs.media_set_id = bmf.media_set_id
WHERE bs.database_name = N'Satis'
ORDER BY bs.backup_start_date DESC;

type sütununda D tam, I fark, L log yedeğini gösterir. device_type 7 olan kayıtlar sanal cihaz üzerinden, yani genellikle VSS veya üçüncü taraf yazılımla alınmış yedeklerdir. Fark yedeği zincirinin beklenmedik bir tam yedekle kırılıp kırılmadığını anlamak için konsolda ilk çalıştırdığımız sorgu budur.

Doğrulama ve test

RESTORE VERIFYONLY, yedek dosyasının okunabilir ve eksiksiz olduğunu kontrol eder; CHECKSUM ile birlikte kullanıldığında sayfa sağlama toplamlarını da doğrular:

RESTORE VERIFYONLY
  FROM DISK = N'\\yedek01\sql\Satis\Satis_FULL_20261108.bak'
  WITH CHECKSUM;

VERIFYONLY veritabanının mantıksal tutarlılığını kanıtlamaz. Dosya okunuyor, o kadar. Gerçek doğrulama, yedeği ayrı bir sunucuda geri yükleyip ardından DBCC CHECKDB çalıştırmaktır. Kontrol listesi:

• Her üretim veritabanı için recovery model ve RPO eşleşiyor mu?
• Log yedeği işi her 15 dakikada başarıyla çalışıyor ve hata durumunda alarm üretiyor mu?
• Yedekler SQL sunucusundan ayrı bir depoya ve ikinci bir konuma kopyalanıyor mu?
• Log sahipliği ve copy-only ayarı imaj aracıyla netleştirildi mi?
• Ayda en az bir kez test sunucusunda tam + fark + log zinciri geri yüklenip DBCC CHECKDB çalıştırılıyor mu?
• Geri yükleme süresi ölçülüp RTO ile karşılaştırılıyor mu?

Hedeflerin teknoloji karşılığı için RPO/RTO hedefine göre teknoloji seçimi, kopya sayısı ve test disiplini için 3-2-1-1-0 yedekleme kuralı yazılarına bakabilirsiniz. SQL Server ortamlarında yedek zincirini ve işletimi nasıl ele aldığımız yedekleme ve felaket kurtarma ile sunucu ve bulut yönetimi sayfalarımızda. Ayrıntılı başvuru için Microsoft’un SQL Server yedekleme ve geri yükleme belgesi temel kaynaktır.

Sık sorulan sorular

SQL Server için hangi recovery model seçilmeli?

Veritabanının RPO’su tam veya fark yedeği aralığından kısaysa FULL model ve düzenli log yedeği gerekir. Bir günlük veri kaybının kabul edildiği test ve raporlama veritabanlarında SIMPLE model yeterlidir.

Transaction log dosyası neden sürekli büyüyor?

FULL modelde en yaygın neden log yedeği alınmamasıdır. Uzun açık işlemler, geride kalan AG replikası veya replikasyon da log’un yeniden kullanılmasını engeller. Gerçek nedeni sys.databases içindeki log_reuse_wait_desc sütunu gösterir.

Veeam imaj yedeği varken ayrıca SQL yedeği almak gerekir mi?

Gerekebilir; belirli ana dönüş ve DBA ihtiyaçları karar verir. Birlikte kullanılacaksa imaj yedeği copy-only olmalı ve log yedeklerini yalnız bir araç almalıdır. Aksi halde fark tabanı değişir veya log zinciri bölünür.

RESTORE VERIFYONLY yedeğin sağlam olduğunu kanıtlar mı?

Hayır. Yedek dosyasının okunabilir ve eksiksiz olduğunu, CHECKSUM ile birlikte sayfa sağlama toplamlarını doğrular. Mantıksal tutarlılık için yedeği test sunucusuna geri yükleyip DBCC CHECKDB çalıştırın.