Kurumsal ortamlarda veritabanı, işletmenin dijital hafızasıdır. SQL Server üzerinde çalışan ERP, CRM, muhasebe ya da özel geliştirilmiş uygulamaların arkasındaki veri katmanı korunmadığında, bir donanım arızası, fidye yazılımı saldırısı ya da insan hatası şirketin günlerce çalışamamasına yol açabilir. AFN Teknoloji olarak 2008'den bu yana İstanbul merkezli 500'den fazla kurumsal müşteride SQL Server altyapılarının yedeklenmesi, test edilmesi ve felaket senaryolarına hazırlanması konusunda çalışıyoruz. Bu yazıda, gerçek saha deneyimlerimizden yola çıkarak doğru bir SQL Server yedekleme stratejisinin nasıl kurulması gerektiğini ele alıyoruz.
Yedekleme Türleri ve Doğru Kombinasyon
SQL Server üç temel yedekleme türü sunar: full backup, differential backup ve transaction log backup. Full backup, veritabanının tüm verisini kapsar ve genellikle günlük ya da haftalık periyotlarda alınır. Örneğin 200 GB'lık bir üretim veritabanı için full backup süresi diskin I/O performansına bağlı olarak 20-40 dakika arasında değişebilir. Differential backup, son full backup'tan sonra değişen blokları yedekler ve boyutu genellikle full backup'ın %5-15'i kadardır; bu sayede yedekleme penceresi kısalır. Transaction log backup ise en kritik katmandır: recovery model FULL olarak ayarlandığında, her 15 dakikada bir alınan log yedekleri, RPO'yu (Recovery Point Objective) dakikalar seviyesine indirir.
Sahada en çok gördüğümüz hata, recovery model'in SIMPLE bırakılmasıdır. Bu durumda transaction log yedeği alınamaz ve son full/differential yedekten sonraki tüm değişiklikler kurtarılamaz hale gelir. Bir müşterimizde bu ayar hatası nedeniyle 6 saatlik veri kaybı yaşanmış, biz devreye girdiğimizde recovery model FULL'a çevrilip 15 dakikalık log yedekleme döngüsü kurulmuştu.
RPO, RTO ve Gerçekçi Hedefler
Yedekleme stratejisi kurarken en çok atlanan nokta, teknik kapasiteyle iş beklentisinin örtüşmemesidir. Bir finans departmanı "veri kaybını sıfıra indirin" derken, altyapı sadece günde bir kez full backup alıyorsa aradaki fark 24 saate kadar çıkabilir. AFN Teknoloji'nin ilk adımı, müşteriyle RPO ve RTO hedeflerini birlikte netleştirmektir. Kritik üretim veritabanları için genellikle 15 dakikalık log backup, günlük full backup, 4 saatte bir differential backup önerimizdir. Bu kombinasyon, ortalama 150-300 GB büyüklüğündeki veritabanlarında hem storage maliyetini kontrol altında tutar hem de RTO'yu 1-2 saate indirir.
RTO tarafında ise sadece yedeğin varlığı yetmez; restore süresinin de test edilmiş olması gerekir. 500 GB'lık bir veritabanının restore işlemi, disk hızına ve ağ bant genişliğine bağlı olarak 45 dakika ile 3 saat arasında sürebilir. Bu nedenle her çeyrekte gerçek bir restore testi yapılmasını standart prosedür olarak uyguluyoruz.
Doğru Araç Seçimi: Veeam ve Depolama Katmanı
Native SQL Server yedekleme betikleri küçük ortamlarda işe yarasa da, çok sunuculu ve VM tabanlı kurumsal altyapılarda merkezi yönetim gerekir. Veeam iş ortağımız olarak, Veeam Backup & Replication üzerinden SQL Server için application-aware image-level backup ile transaction log truncation'ı otomatikleştiriyoruz. Bu yaklaşım, VM seviyesinde günlük image backup alırken, veritabanı tutarlılığını (transactional consistency) da garanti eder. Ayrıca Veeam'in 3-2-1 kuralına uygun repository yapılandırması sayesinde yedekler hem yerel storage'da hem de bulutta veya offsite lokasyonda tutulur.
Depolama katmanında Lenovo ve HP iş ortaklıklarımız üzerinden, yedek verilerin tutulduğu storage'ların IOPS ve kapasite planlamasını da yapıyoruz. Örneğin günlük 50 GB değişim oranı olan bir SQL Server için 30 günlük retention politikasıyla en az 1.5-2 TB ek storage alanı ayrılmasını öneriyoruz; bu hesaplama yapılmadığında disk dolması nedeniyle yedeklemenin sessizce durduğu vakalarla sık karşılaşıyoruz.
AFN'nin İzleme Katmanı: ShamashAI
Yedekleme stratejisinin en zayıf halkası genellikle izlemedir. Yedek alınıyor gibi görünse de, gerçekte başarısız olan job'lar günlerce fark edilmeyebilir. AFN Teknoloji olarak geliştirdiğimiz ShamashAI platformu, SQL Server yedekleme job'larını, transaction log büyümesini ve backup dosyalarının bütünlüğünü sürekli izler; bir yedekleme başarısız olduğunda veya log dosyası anormal büyüdüğünde anlık uyarı üretir. Müşterilerimizin çoğu bize ilk geldiğinde "yedeklerimiz var ama son kez ne zaman test edildiğini bilmiyoruz" diyerek başvurur; ShamashAI ile bu görünürlük eksikliğini ortadan kaldırıyoruz.
Ayrıca fidye yazılımı saldırılarında SQL Server yedeklerinin de şifrelenmesi riskine karşı, immutable (değiştirilemez) repository yapılandırmasını Veeam üzerinden kurarak yedeklerin en az 7-14 gün süreyle silinemez/değiştirilemez halde tutulmasını sağlıyoruz. Bu, saldırı anında geri dönüş noktasının korunmasını garanti eden kritik bir katmandır.
Sonuç ve Öneri
SQL Server yedekleme stratejisi tek seferlik bir kurulum değil, sürekli test edilmesi ve izlenmesi gereken canlı bir süreçtir. Recovery model ayarları, backup türlerinin doğru kombinasyonu, storage kapasite planlaması ve restore testleri bir arada düşünülmediğinde, "yedeğimiz var" cümlesi yanıltıcı bir güvenlik hissi yaratır. Gerçek soru, o yedekten ne kadar hızlı ve ne kadar eksiksiz dönebildiğinizdir.
Şirketinizin SQL Server yedekleme stratejisinin gerçekten iş sürekliliği hedeflerinizi karşılayıp karşılamadığını bilmiyorsanız, AFN Teknoloji'nin ücretsiz AFN RiskScan siber risk taramasından yararlanabilirsiniz. Bu tarama ile yedekleme yapılandırmanızdaki boşlukları, recovery model hatalarını ve depolama risklerini somut bir raporla görebilirsiniz. Detaylı bilgi ve ücretsiz tarama talebi için https://afnteknoloji.com/iletisim adresinden bizimle iletişime geçebilirsiniz.