SQL Server Yedekleme Stratejisi: Tam, Fark ve Log Yedekleriyle Güvenli Kurgu

Muhasebe, stok, personel ya da yemekhane verisi tutan bir kurumda en kritik varlık çoğu zaman tek bir sunucudaki SQL Server veritabanlarıdır. Disk arızası, hatalı bir güncelleme sorgusu veya fidye yazılımı aynı sonucu doğurur: veri yoksa iş durur. Bu yazıda doğru bir SQL Server yedekleme stratejisinin parçalarını; tam, fark ve log yedeklerini, 3-2-1 kuralını, RPO/RTO hedeflerini ve en çok ihmal edilen adım olan geri dönüş testini somut örneklerle anlatıyoruz.

Önce hedef: RPO ve RTO

Yedekleme planı teknik bir ayarla değil, iki iş sorusuyla başlar:

• RPO (Recovery Point Objective – kurtarma noktası hedefi): En fazla ne kadarlık veri kaybını kabul edebilirsiniz? "Dünkü veriye dönmek sorun değil" diyorsanız RPO 24 saattir. "En fazla 15 dakikalık kayıt kaybolabilir" diyorsanız log yedeği zorunludur.
• RTO (Recovery Time Objective – kurtarma süresi hedefi): Sistem çöktüğünde ne kadar sürede tekrar çalışır hale gelmelisiniz? Bir saatlik kesintiye tahammül eden bir işletme ile vezne veya kartlı geçiş sistemi çalıştıran bir kurumun ihtiyacı aynı değildir.

Bu iki hedef belli olduğunda hangi yedek türünü hangi sıklıkla alacağınız, yedeklerin nerede duracağı ve ne kadar donanıma ihtiyaç olduğu kendiliğinden netleşir.

Üç yedek türü ve ne işe yaradıkları

Tam yedek (Full)

Veritabanının o anki tamamını ve tutarlı geri yükleme için gereken log kısmını içerir. Tek başına geri yüklenebilir; tüm zincirin başlangıç noktasıdır. Büyük veritabanlarında süre ve disk alanı açısından en maliyetli yedektir.

Fark yedeği (Differential)

Son tam yedekten bu yana değişen veri sayfalarını içerir. Her fark yedeği bir öncekini değil, son tam yedeği baz alır; bu yüzden gün ilerledikçe boyutu büyür. Geri yüklemede tam yedek + en son fark yedeği yeterlidir, bu da RTO'yu kısaltır.

Transaction log yedeği

Son log yedeğinden bu yana yapılan tüm işlemleri içerir. Belirli bir dakikaya geri dönmeyi (point-in-time restore) mümkün kılar ve log dosyasının kontrolsüz büyümesini engeller. Bunun için veritabanının FULL (veya BULK_LOGGED) kurtarma modelinde olması gerekir. SIMPLE modelde log yedeği alınamaz.

Orta ölçekli bir işletme için yaygın ve dengeli bir kurgu şöyledir: Pazar gecesi tam yedek, diğer gecelerde fark yedeği, mesai saatlerinde 15–30 dakikada bir log yedeği. Veritabanı küçükse (birkaç GB) her gece tam yedek almak da makul ve daha basittir.

T-SQL ile örnek yedek komutları

Aşağıdaki örnek; sıkıştırılmış ve sağlama toplamlı (checksum) tam, fark ve log yedeği almayı, ardından yedek dosyasını doğrulamayı gösterir. Yol ve veritabanı adlarını kendi ortamınıza göre değiştirin.

-- Tam yedek
BACKUP DATABASE [Muhasebe]
TO DISK = N'D:\Yedek\Muhasebe_FULL.bak'
WITH COMPRESSION, CHECKSUM, INIT, STATS = 10;

-- Fark yedeği
BACKUP DATABASE [Muhasebe]
TO DISK = N'D:\Yedek\Muhasebe_DIFF.bak'
WITH DIFFERENTIAL, COMPRESSION, CHECKSUM, INIT;

-- Log yedeği (FULL kurtarma modeli gerekir)
BACKUP LOG [Muhasebe]
TO DISK = N'D:\Yedek\Muhasebe_LOG_1430.trn'
WITH COMPRESSION, CHECKSUM;

-- Yedek dosyasının okunabilirlik ve bütünlük kontrolü
RESTORE VERIFYONLY
FROM DISK = N'D:\Yedek\Muhasebe_FULL.bak'
WITH CHECKSUM;

CHECKSUM, yedek alınırken sayfa sağlama toplamlarını kontrol eder ve bozuk bir sayfayı daha yedek aşamasında yakalamanızı sağlar. RESTORE VERIFYONLY ise dosyanın eksiksiz ve okunabilir olduğunu doğrular; ancak bir sonraki bölümde anlatacağımız gerçek geri yükleme testinin yerini tutmaz.

3-2-1 kuralı: Yedeğin yeri en az türü kadar önemli

Aynı sunucunun D: diskinde duran yedek, sunucu çalındığında, yandığında veya fidye yazılımı tüm diskleri şifrelediğinde veriyle birlikte kaybolur. 3-2-1 kuralı bu riski basit bir formülle azaltır:

• 3 kopya veri (canlı veri + 2 yedek),
• 2 farklı ortam (ör. sunucu diski ve NAS ya da yedekleme sunucusu),
• 1 kopya kurum dışında (uzak veri merkezi, farklı bina veya bulut).

Bugün buna sıklıkla bir madde daha eklenir: kopyalardan en az biri çevrimdışı veya değiştirilemez olmalıdır. Ağdaki bir paylaşıma sürekli bağlı duran yedek klasörü, fidye yazılımı için yalnızca bir başka hedeftir. Yedeklerin uzak sunucuya gönderilmeden önce şifrelenmesi de, dosyalar yanlış ellere geçtiğinde veri sızıntısını önler.

Geri dönüş (restore) testi: Yedeğiniz gerçekten var mı?

Sahada en sık gördüğümüz sorun, yedeklerin aylarca "başarılı" görünüp ihtiyaç anında açılamamasıdır. Nedenleri genellikle şunlardır: kopmuş bir log zinciri, dolu disk yüzünden yarım kalmış dosyalar, şifre anahtarının kaybolması veya yanlış veritabanının yedeklenmesi. Bunu önlemek için:

1. Ayda en az bir kez, yedeği ayrı bir test sunucusuna farklı bir adla geri yükleyin (RESTORE DATABASE ... WITH MOVE).
2. Geri yüklenen veritabanında DBCC CHECKDB çalıştırarak mantıksal ve fiziksel bütünlüğü kontrol edin.
3. Uygulamayı (muhasebe, ERP vb.) bu kopyaya bağlayıp son günün kayıtlarının yerinde olduğunu görün.
4. Geri yüklemenin ne kadar sürdüğünü ölçün; bu süre sizin gerçek RTO'nuzdur.
5. Sonucu ve tarihi kayıt altına alın. Test edilmemiş yedek, plan değil umuttur.

Sık yapılan hatalar

• Veritabanını FULL modelde tutup hiç log yedeği almamak: log dosyası diski doldurana kadar büyür.
• Yalnızca kullanıcı veritabanlarını yedekleyip master ve msdb'yi unutmak (oturum açma bilgileri ve zamanlanmış iş tanımları bu veritabanlarındadır).
• Eski yedekleri hiç silmemek ya da tam tersine yalnızca son yedeği tutmak. Bozulma geç fark edilirse birkaç gün öncesine dönebilmek gerekir.
• Yedekleme işinin hata verdiğini kimsenin fark etmemesi. Başarısız yedek için e-posta veya SMS uyarısı mutlaka kurulmalıdır.

Otomasyon ve izleme

Birden fazla sunucu ve onlarca veritabanı olan ortamlarda komutları elle yönetmek sürdürülebilir değildir. Kendi geliştirdiğimiz Veritabanı Yedekleme Yazılımı, her gün belirlenen saatte sistemdeki tüm SQL Server, MySQL ve Firebird veritabanlarını yedekler, yedekleri şifreler ve üç farklı lokasyondaki yedekleme sunucularına gönderir. Böylece 3-2-1 kuralının "kurum dışı kopya" ayağı insan hatasına bırakılmaz.

Sunucu tarafında kurtarma modellerinin doğru ayarlanması, disk planlaması, bakım planları ve düzenli restore testleri için sunucu kurulum ve bakım hizmetlerimiz kapsamında destek veriyoruz. Mevcut yedekleme düzeninizi birlikte gözden geçirmek isterseniz bize ulaşabilirsiniz; ilk adım, RPO ve RTO hedeflerinizi netleştirmek olacaktır.