SQL Server Backup Türleri: Full, Differential, Log, Tail-Log ve Copy-Only Rehberi

SQL Server, çoğu ekibin kullandığından daha fazla backup türü sunar ve bunlar arasındaki farklar neyi restore edebileceğinizi, ne kadar geriye gidebileceğinizi ve restore’un ne kadar süreceğini belirler. Sık yapılan birçok hata bu türlerin yanlış anlaşılmasından doğar: gece alınan differential’ları sessizce bozan elle alınmış bir full backup, her gece full backup alınmasına rağmen büyümeyi durdurmayan bir log ya da restore’un bağlı olduğu tek backup’ın aslında “test için alınmış bir kopya” çıkması.

Bu rehberde her SQL Server backup türünü, birbirlerine nasıl bağlı olduklarını ve hangisinin ne zaman kullanılacağını anlatıyoruz.

Bir Bakışta SQL Server Backup Türleri

Full Backup

Full backup, veritabanındaki bütün veriyi ve restore edildiğinde bu veriyi tutarlı hale getirecek kadar transaction log’u içerir. Backup, veritabanını backup’ın bittiği andaki haliyle temsil eder ve backup sürerken kullanıcılar çalışmaya devam edebilir.

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

Full backup’ın yapmadığı iki şey sıkça yanlış anlaşılır:

• Transaction log’u truncate etmez. Full recovery model’de log alanını yeniden kullanıma yalnızca log backup açar. Her gece full backup’ı alınan ama log backup’ı alınmayan bir veritabanının log’u disk dolana kadar büyür. SQL Server Transaction Log’unuz Çok mu Büyük? yazımıza bakabilirsiniz.
• Log zincirini kırmaz. Log backup’ları full backup’lar boyunca sırasını korur; bu sayede bir restore daha eski bir full backup’tan başlayıp sonraki bütün log backup’larıyla ileri sarılabilir.

Differential Backup

Differential backup yalnızca differential base‘den, yani en son (copy-only olmayan) full backup’tan bu yana değişen veri extent’lerini içerir. SQL Server değişen extent’leri bir bitmap’te takip eder; bu yüzden differential, neyin değiştiğini bulmak için bütün veritabanını okumak zorunda kalmaz.

BACKUP DATABASE [SalesDB]
TO DISK = N'\\backupsrv\sql\SalesDB\SalesDB_DIFF_20261007.bak'
WITH DIFFERENTIAL, COMPRESSION, CHECKSUM;

Differential’lar kümülatiftir: perşembe günkü differential, pazartesi, salı ve çarşamba günkülerin içerdiği her şeyi içerir. Restore için yalnızca full backup’a ve en son differential’a ihtiyacınız vardır, aradakilerin hepsine değil. Bedeli şudur: bir sonraki full backup tabanı sıfırlayana kadar her differential bir öncekinden büyüktür.

Tuzak: elle alınan bir full backup differential base’i taşır

Transaction Log Backup

Log backup, bir önceki log backup’a dahil edilmemiş bütün log kayıtlarını içerir. Yalnızca full ve bulk-logged recovery model’de kullanılabilir ve ilk log backup için mevcut bir full backup gerekir. Log backup’lar üç iş görür:

• Point-in-time recovery: kesintisiz bir log backup zinciriyle herhangi bir ana dönebilirsiniz; örneğin hatalı bir DELETE‘ten bir saniye öncesine.
• Düşük RPO: log backup aralığı en fazla veri kaybını belirler. 15 dakikada bir alınıyorsa en fazla 15 dakikalık iş kaybolur.
• Log truncation: log backup’tan sonra log’un aktif olmayan kısmı yeniden kullanılabilir; bu da log dosyasının boyutunu sabit tutar.

BACKUP LOG [SalesDB]
TO DISK = N'\\backupsrv\sql\SalesDB\SalesDB_LOG_20261007_1415.trn'
WITH COMPRESSION, CHECKSUM;

Her log backup bir zincirin halkasıdır. Bir dosya kaybolur ya da bozulursa, onun ötesine ileri saramazsınız. Bu yüzden log backup’lar da full backup’lar kadar özen ister: sunucu dışında saklama, izleme ve saklama süresi. Simple recovery model’de log backup yoktur; bunun sonuçlarını SQL Server Simple Recovery Model: Ne Zaman Kullanılmalı, Ne Zaman Kullanılmamalı? yazımızda anlattık.

Tail-Log Backup

Tail-log backup, restore’dan hemen önce henüz yedeklenmemiş log kayıtlarını, yani log’un “kuyruğunu” alır. Bir veri dosyası arızalandıysa ama log dosyası hâlâ okunabiliyorsa, tail-log backup hiç veri kaybetmeden restore etmenizi sağlar:

-- Veritabanı online: kuyruğu yedekle ve veritabanını RESTORING durumunda bırak
BACKUP LOG [SalesDB]
TO DISK = N'\\backupsrv\sql\SalesDB\SalesDB_TAIL.trn'
WITH NORECOVERY;

-- Veritabanı hasarlı: kuyruğu yine de yedeklemeyi dene
BACKUP LOG [SalesDB]
TO DISK = N'\\backupsrv\sql\SalesDB\SalesDB_TAIL.trn'
WITH NO_TRUNCATE, CONTINUE_AFTER_ERROR;

Copy-Only Backup

Copy-only backup, normal backup dizisinden bağımsızdır:

• Copy-only full backup differential base’i değiştirmez, bu yüzden zamanlanmış differential’larınızı etkilemez. Kendisi differential base olarak kullanılamaz.
• Copy-only log backup normal log backup’ların sırasını etkilemez ve ardından log truncate edilmez.

Zamanlamanın dışındaki her şey için copy-only kullanın: test ya da geliştirme ortamını yenilemek, bir tedarikçiye kopya göndermek ya da bir deployment öncesinde güvenlik kopyası almak.

BACKUP DATABASE [SalesDB]
TO DISK = N'\\backupsrv\adhoc\SalesDB_COPY_before_release.bak'
WITH COPY_ONLY, COMPRESSION, CHECKSUM;

COPY_ONLY, DIFFERENTIAL ile birlikte kullanıldığında etkisizdir. Always On availability group’larda SQL Server 2022’ye kadar secondary replica’lardaki full backup’lar copy-only olmak zorundadır.

File, Filegroup ve Partial Backup

Birden fazla filegroup’a bölünmüş çok büyük veritabanlarında her seferinde her şeyi yedeklemek bakım penceresine sığmayabilir. SQL Server tek tek dosyaları ya da filegroup’ları yedekleyebilir. Partial backup (BACKUP DATABASE ... READ_WRITE_FILEGROUPS) ise primary filegroup’u ve bütün read/write filegroup’ları içerir, read-only olanları atlar. Yaygın bir yöntem, geçmiş veriyi read-only bir filegroup’a taşıyıp onu bir kez yedeklemek, ardından yalnızca aktif kısmı düzenli olarak yedeklemektir. Bu stratejiler restore’u karmaşıklaştırır; bu yüzden gerçekten ihtiyaç duyan veritabanlarına ayrılmalı ve dikkatle test edilmelidir.

Her Backup’ta Kullanmaya Değer Seçenekler

• CHECKSUM: backup veriyi okurken sayfa checksum’larını doğrular ve hasarlı bir sayfa bulursa backup’ı durdurur. Backup’ın kendisine de bir checksum ekler.
• COMPRESSION: biraz ek CPU karşılığında backup’ları genellikle küçültür ve hızlandırır. Enterprise sürümde ve SQL Server 2016’dan itibaren Standard sürümde desteklenir. SQL Server Backup Compression Rehberi yazımıza bakabilirsiniz.
• ENCRYPTION: SQL Server 2014’ten itibaren backup dosyalarını korur. Sertifikayı yedekleyin, yoksa backup’lar restore edilemez.

Hangi Backup Türlerine İhtiyacınız Var?

• Kritik ya da önemli veritabanları (full recovery model): full + differential + sık log backup. Tipik zamanlama haftalık full, günlük differential ve 15 dakikada bir log backup’tır.
• Küçük veritabanları: günlük full backup ve log backup’lar çoğu zaman differential eklemekten daha basittir.
• Yeniden yüklenebilir veritabanları (simple recovery model): günlük full backup, isteğe bağlı olarak differential’larla.
• Geçici her şey: copy-only.

Bunu RPO ve RTO’nuza uyan bir zamanlamaya nasıl dönüştüreceğinizi, backup’ları nerede saklayacağınızı ve nasıl test edeceğinizi SQL Server Backup Planı Nasıl Kurulur? yazımızda anlattık.

Gerçekte Hangi Backup’larınız Var? Kontrol Edin

Bu sorgu son yedi günün backup’larını tür, boyut ve copy-only olup olmadıkları bilgisiyle listeler:

SELECT b.database_name,
       CASE b.type
            WHEN 'D' THEN 'Full'
            WHEN 'I' THEN 'Differential'
            WHEN 'L' THEN 'Log'
            WHEN 'F' THEN 'File / filegroup'
            WHEN 'P' THEN 'Partial'
       END AS backup_type,
       b.is_copy_only,
       b.backup_start_date,
       b.backup_finish_date,
       CAST(b.compressed_backup_size / 1048576.0 AS decimal(18, 1)) AS size_mb,
       m.physical_device_name
FROM msdb.dbo.backupset AS b
JOIN msdb.dbo.backupmediafamily AS m ON m.media_set_id = b.media_set_id
WHERE b.backup_start_date > DATEADD(DAY, -7, GETDATE())
ORDER BY b.database_name, b.backup_start_date DESC;

Zamanlamanızdan gelmeyen normal (copy-only olmayan) full backup’lara dikkat edin. Her biri differential base’i taşır; physical_device_name sütunu da nereye yazıldığını gösterir.

Sık Sorulan Sorular