SQL Server Backup Planı Nasıl Kurulur? RPO, RTO, Zamanlama ve Test Rehberi

SQL Server ortamlarının çoğunda backup vardır. Ama çok daha azında bir backup planı vardır. Aradaki fark en kötü günde ortaya çıkar: backup job’ı her gece çalışmıştır, ama restore’un ne kadar sürdüğünü kimse bilmez, log backup’ları hiç test edilmemiştir ya da tek kopya, az önce çöken sunucunun üzerindedir.

Gerçek bir backup planı, işin sahiplerine iki konuda verilmiş bir sözdür: ne kadar veri kaybedebileceğiniz ve ne kadar süre kapalı kalacağınız. Bu yazıda bu planı adım adım nasıl kuracağınızı anlatıyoruz: hedefleri belirlemek, backup tiplerini ve zamanlamayı seçmek, backup’ları güvenle saklamak, saklama süresini belirlemek ve bütün bunların çalıştığını kanıtlamak.

Zamanlamayla Değil, RPO ve RTO ile Başlayın

Herhangi bir zamanlama seçmeden önce her veritabanı için işin sahibiyle iki rakamda anlaşın:

• RPO (Recovery Point Objective): işin kabul edebileceği, zaman cinsinden en fazla veri kaybı. 15 dakikalık RPO, bir felaketten sonra en fazla son 15 dakikalık işin kaybolabileceği anlamına gelir.
• RTO (Recovery Time Objective): arızanın başladığı andan veritabanının tekrar hizmete girdiği ana kadar kabul edilebilir en uzun kesinti süresi.

RPO, log backup’larını ne sıklıkla alacağınızı belirler. RTO ise restore’un ne kadar hızlı olması gerektiğini belirler; bu da backup tiplerinin dengesini, depolama hızını, sıkıştırmayı ve yalnızca backup’ın yeterli olup olmadığını, yoksa yüksek erişilebilirliğe de ihtiyaç olup olmadığını etkiler.

Her veritabanının hedefleri aynı olmak zorunda değildir. Pratik bir yaklaşım veritabanlarını seviyelere ayırmaktır:

Neyin Mümkün Olduğunu Recovery Model Belirler

Point-in-time recovery ve dakikalarla ölçülen bir RPO, yalnızca full (ya da bulk-logged) recovery model ve düzenli log backup’larıyla mümkündür. Simple recovery model’de log backup yoktur: yalnızca son full ya da differential backup’a dönebilirsiniz, yani RPO bu backup’lar arasındaki süreye eşittir.

Her veritabanının recovery model’ini seviyesiyle karşılaştırın. Simple recovery’deki kritik bir veritabanı, ne kadar sık full backup alırsanız alın 15 dakikalık RPO’yu karşılayamaz. Full recovery’de olup log backup’ı alınmayan bir veritabanının sorunu ise farklıdır: log’u disk dolana kadar büyür. İkisini de SQL Server Simple Recovery Model: Ne Zaman Kullanılmalı, Ne Zaman Kullanılmamalı? ve SQL Server Transaction Log’unuz Çok mu Büyük? yazılarımızda anlattık.

Backup Tipleri ve Birlikte Nasıl Çalıştıkları

• Full backup: veritabanının tam kopyası ve onu tutarlı hale getirecek kadar log. Her restore dizisi bir full backup ile başlar.
• Differential backup: son full backup’tan bu yana değişen bütün extent’ler. Differential’lar kümülatiftir, yani her zaman yalnızca en sonuncusuna ihtiyaç duyarsınız; ama bir sonraki full backup’a kadar her gün büyürler.
• Transaction log backup: bir önceki log backup’tan bu yana yazılan bütün log kayıtları. Log backup’ları bir zincir oluşturur ve belirli bir ana dönmek için zincirin her halkası gerekir. Ayrıca log’un truncate edilip yeniden kullanılmasını sağlarlar.
• Copy-only backup: normal backup dizisini etkilemeyen full ya da log backup. Örneğin bir test ortamını yenilemek için alınan geçici kopyalarda kullanın; böylece differential tabanını ya da log zincirini bozmazsınız.

Zamanlamayı Kurmak

Yönettiğimiz iş veritabanlarının çoğunda başlangıç noktamız şudur:

• Full backup: haftada bir, en sakin zaman aralığında (örneğin pazar gecesi).
• Differential backup: diğer gecelerde, her gün.
• Log backup: günün her saati, 15 dakikada bir.

Bu zamanlamayla perşembe 14:20’de yaşanan bir arıza, pazar günkü full backup, çarşamba gecesi alınan differential ve o andan sonraki log backup’larıyla restore edilir; log dosyasına hâlâ erişilebiliyorsa buna bir tail-log backup da eklenir. En kötü durumda 15 dakikaya kadar veri kaybedersiniz; başarılı bir tail-log backup ile çoğu zaman hiç kaybetmezsiniz.

Zamanlamayı seviyeye ve iş yüküne göre ayarlayın:

• Daha sıkı RPO: log backup aralığını 5 dakikaya, hatta 1 dakikaya indirin. Sakin bir veritabanının log backup’ları küçüktür, bu yüzden sık backup almanın maliyeti düşüktür.
• Daha sıkı RTO: uygulanacak log backup zinciri ne kadar uzunsa restore o kadar uzun sürer. Günlük full backup’lar ya da gün içinde ek differential’lar zinciri kısaltır.
• Yoğun yazma alan veritabanları: differential’lar hafta sonuna doğru neredeyse bir full backup kadar büyüyebilir. Böyle bir durumda günlük full backup daha basittir.
• Küçük veritabanları: günlük full backup ve log backup’lar çoğu zaman en basit plandır.

Sistem veritabanlarını unutmayın. master ve msdb‘yi düzenli yedekleyin (login’ler, job’lar, backup geçmişi ve SSIS paketleri buradadır); özelleştirdiyseniz model‘i de.

Doğru seçeneklerle backup komutları

-- Haftalık full
BACKUP DATABASE [SalesDB]
TO DISK = N'\\backupsrv\sql\SalesDB\SalesDB_FULL_20261004.bak'
WITH COMPRESSION, CHECKSUM, STATS = 10;

-- Günlük differential
BACKUP DATABASE [SalesDB]
TO DISK = N'\\backupsrv\sql\SalesDB\SalesDB_DIFF_20261007.bak'
WITH DIFFERENTIAL, COMPRESSION, CHECKSUM;

-- 15 dakikada bir log backup
BACKUP LOG [SalesDB]
TO DISK = N'\\backupsrv\sql\SalesDB\SalesDB_LOG_20261007_1415.trn'
WITH COMPRESSION, CHECKSUM;

CHECKSUM, backup okunurken sayfa checksum’larını doğrular ve hasarlı bir sayfa bulursa backup’ı durdurur. COMPRESSION genellikle biraz CPU karşılığında backup’ları hem küçültür hem hızlandırır; SQL Server Backup Compression Rehberi yazımıza bakabilirsiniz. Aynı dosyaya çok sayıda backup eklemek yerine, adında tarih ve saat bulunan, her backup için ayrı bir dosya kullanın.

Always On: Backup’lar Nerede Alınmalı?

Bir availability group’ta backup’ları secondary replica’ya taşıyarak primary’nin yükünü azaltabilirsiniz. Hangi replica’ların tercih edileceğini availability group’un backup preference ve priority ayarlarıyla belirleyin, backup job’larını her replica’da oluşturun ve job içinde sys.fn_hadr_backup_is_preferred_replica() kontrolünü kullanın; böylece backup’ı yalnızca tercih edilen replica alır.

Sınırları bilin. SQL Server 2022’ye kadar secondary replica’larda yalnızca copy-only full backup ve normal log backup alınabilir; differential backup desteklenmez. SQL Server 2025, secondary replica’larda full ve differential backup desteği ekler. Log backup’ı hangi replica alırsa alsın log zinciri tutarlı kalır; ama backup geçmişi, backup’ı alan replica’nın msdb‘sine yazılır, bu yüzden izleme her replica’ya bakmalıdır. Mimari için SQL Server Always On Nedir? yazımıza bakabilirsiniz. Yüksek erişilebilirlik backup’ın yerini tutmaz: yanlışlıkla çalıştırılan bir DELETE saniyeler içinde bütün secondary’lere taşınır.

Backup’lar Nerede Durmalı? Sunucunun Dışında ve Erişilemez Yerde

Veritabanıyla aynı diskte, hatta aynı sunucuda duran bir backup çok az şeye karşı koruma sağlar. Yaygın kullanılan bir kural 3-2-1‘dir: verinizin üç kopyası, iki farklı depolama tipinde ve bir kopyası farklı bir lokasyonda. Pratikte:

• Backup’ları veritabanı sunucusunun kendi disklerine değil, ayrı bir backup sunucusuna ya da ağ paylaşımına yazın.
• Onları ikinci bir lokasyona kopyalayın: başka bir veri merkezi, bulut depolama (SQL Server, BACKUP ... TO URL ile doğrudan Azure Blob Storage’a backup alabilir) ya da teyp.
• En az bir kopyayı fidye yazılımına ve yanlışlıkla silinmeye karşı koruyun: değiştirilemez (immutable) depolama ya da SQL Server servis hesabının ve domain yöneticilerinin silemediği bir depolama.

Backup’ları şifrelemek

Saklama Süresi: Backup’lar Ne Kadar Tutulmalı?

Saklama süresi yalnızca bir disk alanı kararı değildir. En az süreyi üç şey belirler:

• Ne kadar geriye dönmeniz gerekebileceği: bir hafta sonra fark edilen bir veri hatası, bir haftadan eski bir backup gerektirir.
• Bütünlük kontrolleri: başarılı iki DBCC CHECKDB arasındaki süre saklama sürenizden kısa olmalıdır; yoksa bozulma elinizdeki bütün backup’larda olabilir. SQL Server’da DBCC CHECKDB yazımıza bakabilirsiniz.
• Yasal ve sözleşmesel gereklilikler: mevzuat, denetimler ve sözleşmeler bazı veriler için daha uzun saklama gerektirebilir.

Test Restore: Bir Backup’ın Çalıştığının Tek Kanıtı

Başarılı bir backup job’ı yalnızca bir dosyanın yazıldığını kanıtlar. RESTORE VERIFYONLY backup’ın eksiksiz ve okunabilir olduğunu kontrol eder, ama içindeki verinin tutarlı olduğunu kanıtlamaz. Tek gerçek kanıt gerçek bir restore’dur:

• Düzenli olarak restore edin (kritik veritabanları için en az ayda bir), ayrı bir sunucuya ve log backup’larıyla point-in-time restore dahil.
• Restore edilen kopyada DBCC CHECKDB çalıştırın; böylece backup’ın tutarlı bir veritabanı içerdiğini kanıtlarsınız.
• Süreyi ölçün. Restore dört saat sürüyor ve RTO bir saatse, backup’lar ne kadar düzgün alınırsa alınsın plan hedefini karşılamıyor demektir.
• Runbook’u yazın: kim restore edecek, nereden, hangi sırayla ve uygulamalar nasıl yeniden bağlanacak. Bunu kesintinin ortasında düşünmek için doğru zaman değildir.

Restore adımlarının kendisi için SQL Server Restore rehberimize bakabilirsiniz.

İzleme: Her Veritabanının Gerçekten Backup’ı Alınıyor mu?

Job’lar devre dışı kalır, sessizce hata alır ya da geçen ay eklenen bir veritabanını atlar. Bu sorgu, instance’taki her veritabanı için son full, differential ve log backup’ı gösterir:

SELECT d.name,
       d.recovery_model_desc,
       MAX(CASE WHEN b.type = 'D' THEN b.backup_finish_date END) AS last_full,
       MAX(CASE WHEN b.type = 'I' THEN b.backup_finish_date END) AS last_diff,
       MAX(CASE WHEN b.type = 'L' THEN b.backup_finish_date END) AS last_log
FROM sys.databases AS d
LEFT JOIN msdb.dbo.backupset AS b
       ON b.database_name = d.name
WHERE d.database_id <> 2   -- tempdb
GROUP BY d.name, d.recovery_model_desc
ORDER BY last_full;

Hiç full backup’ı olmayan, zamanlamanızın izin verdiğinden eski full backup’ı olan ve last_log değeri RPO’dan eski olan full recovery’deki veritabanlarını arayın. Bunu günlük bir kontrole ya da bir alert’e dönüştürün. Availability group’larda sorguyu her replica’da çalıştırın, çünkü her replica’nın msdb‘si yalnızca kendi aldığı backup’ları kaydeder. Backup job hataları da SQL Server Agent üzerinden DBA ekibine bildirilmelidir.

Backup Planı Kontrol Listesi

1. Her veritabanı için RPO ve RTO üzerinde anlaşılmış ve yazıya dökülmüş.
2. Recovery model, seviyeyle uyumlu.
3. Full, differential ve log backup zamanlaması RPO ve RTO’yu karşılıyor.
4. Sistem veritabanları (master, msdb, model) dahil.
5. Backup’lar CHECKSUM ve faydalı olduğu yerde COMPRESSION ile alınıyor.
6. Backup’lar veritabanı sunucusunun dışına yazılıyor; farklı lokasyonda bir kopya ve silinmeye karşı korunan en az bir kopya var.
7. Şifreleme sertifikaları yedeklenmiş ve ayrı bir yerde saklanıyor.
8. Saklama süresi CHECKDB aralığını ve yasal gereklilikleri kapsıyor; temizlik bütün setleri siliyor.
9. RTO’ya göre süresi ölçülen, restore edilen kopyada CHECKDB çalıştırılan düzenli test restore’lar yapılıyor.
10. Son backup zamanları her gün izleniyor ve job hataları için alert var.

Sık Sorulan Sorular

Bu zamanlama gerçek bir olayda sınandı. Üretim sektöründeki bir müşterimizde, eski bir backup yanlışlıkla canlı production veritabanının üzerine restore edildi. Haftalık full, günlük differential ve 15 dakikalık log backup’lardan oluşan doğrulanmış zincir sayesinde veri kaybını bir dakikayla sınırladık. Hikayenin tamamını okuyun: Hatalı SQL Server Restore İşlemi Sonrası 1 Dakikalık RPO ile Kurtarma.