Kurumsal sistemlerde SQL Server çoğu zaman ERP, muhasebe, e-ticaret, raporlama ve özel yazılım geliştirme projelerinin merkezinde yer alır. Bu nedenle veritabanı yedekleme stratejisi teknik bir bakım görevi olarak değil, iş sürekliliğinin temel parçası olarak ele alınmalıdır. Bir yedekleme planı yalnızca başarılı çalışan job kayıtlarından ibaretse eksiktir. Asıl soru, ihtiyaç anında hangi noktaya, ne kadar sürede ve hangi doğrulukla geri dönülebileceğidir.
RPO ve RTO olmadan strateji tamamlanmış sayılmaz
Yedekleme planına başlamadan önce iki kavram netleşmelidir: RPO ve RTO. RPO, kurumun ne kadar veri kaybını tolere edebileceğini ifade eder. RTO ise sistemin ne kadar sürede tekrar çalışır hale gelmesi gerektiğini gösterir. Örneğin satış ve ERP operasyonlarının yoğun olduğu bir işletmede gün sonunda alınan tek bir full backup yeterli olmayabilir. Gün içinde oluşan sipariş, fatura, stok hareketi ve üretim kayıtlarının kaybı kabul edilemiyorsa differential backup veya transaction log backup senaryoları devreye girmelidir.
Bu kararın yalnızca BT tarafından verilmesi doğru değildir. Finans, operasyon, satış, depo ve yönetim ekiplerinin beklentileri alınmalı; hangi sistemin ne kadar kritik olduğu belirlenmelidir. Bazı raporlama veritabanları için birkaç saatlik kayıp kabul edilebilirken, canlı ERP veritabanında birkaç dakikalık kayıp bile ciddi sonuç doğurabilir. Bu ayrım yapılmadığında tüm sistemlere aynı yedekleme kurgusu uygulanır ve kaynaklar ya gereksiz tüketilir ya da kritik sistemler yeterince korunmaz.
Full, differential ve log backup dengesi
SQL Server yedekleme stratejisinde full backup temel başlangıç noktasıdır. Ancak büyük veritabanlarında yalnızca full backup ile ilerlemek depolama, süre ve ağ trafiği açısından verimsiz olabilir. Differential backup, son full backup’tan sonra değişen verileri kapsadığı için daha hızlı bir ara katman sağlar. Full backup haftalık, differential backup günlük, transaction log backup ise iş ihtiyacına göre daha sık çalışacak şekilde planlanabilir. Bu yapı, veri kaybı toleransını azaltırken geri dönüş senaryosunu da daha kontrollü hale getirir.
Transaction log backup kullanılan yapılarda recovery model seçimi kritik hale gelir. Full recovery model ile noktasal geri dönüş mümkün olabilir, ancak log zincirinin bozulmaması gerekir. Log dosyalarının kontrolsüz büyümesi, yedeklerin farklı lokasyonlara taşınmaması veya job hatalarının izlenmemesi bu zinciri zayıflatır. SQL Server bakım planı veya özel job yapısı kullanılsa da her adımın izlenebilir, raporlanabilir ve uyarı üretebilir olması gerekir.
Planlama yapılırken veritabanı büyüklüğü, bakım penceresi, disk performansı ve ağ kapasitesi de hesaba katılmalıdır. Çok büyük bir ERP veritabanında mesai saatinde çalışan full backup performans sorununa yol açabilir. Benzer şekilde sık log backup almak iyi bir hedef olsa da, bu dosyaların saklanacağı alan ve geri dönüş sırasında izlenecek sıra önceden düşünülmelidir.
Geri dönüş testi planın en önemli parçasıdır
Pek çok kurum yedekleme job’larının başarılı çalıştığını görerek kendini güvende hisseder. Oysa dosya bozuk olabilir, yetki sorunu yaşanabilir, hedef sunucuda yeterli disk alanı bulunmayabilir veya geri dönüş adımları ekip içinde bilinmiyor olabilir. Bu nedenle düzenli restore testleri yapılmalıdır. Test ortamında belirli periyotlarla full, differential ve log backup zinciri geri yüklenmeli; uygulama bağlantısı, kullanıcı yetkileri ve veri tutarlılığı kontrol edilmelidir.
Geri dönüş testleri aynı zamanda dokümantasyonu güçlendirir. Kriz anında hangi dosyanın nereden alınacağı, hangi sırayla restore edileceği, hangi kullanıcıların bilgilendirileceği ve uygulama tarafında hangi kontrollerin yapılacağı önceden yazılı olmalıdır. Bu doküman yalnızca BT ekibinin bildiği teknik bir metin olarak kalmamalı; karar vericilerin anlayacağı RTO ve RPO hedefleriyle ilişkilendirilmelidir.
Depolama, güvenlik ve izleme birlikte düşünülmelidir
Yedeklerin aynı sunucuda tutulması tek başına yeterli değildir. Disk arızası, fidye yazılımı, kullanıcı hatası veya fiziksel hasar gibi riskler için farklı lokasyon ve saklama politikaları gerekir. QNAP NAS, harici depolama, bulut replikasyon veya offline kopya gibi seçenekler kurumun bütçesi ve risk profiline göre değerlendirilebilir. Yedek dosyalarının yetkisiz erişime kapalı olması, gerektiğinde şifrelenmesi ve silinmeye karşı korunması da güvenlik tarafının parçasıdır.
İzleme katmanında job sonucu, dosya boyutu, süre, log büyümesi ve son başarılı yedek zamanı takip edilmelidir. Grafana, Power BI veya basit bildirim mekanizmalarıyla SQL Server yedekleme süreçleri görünür hale getirilebilir. Yönetim raporlamasına uygun özet göstergeler de eklenirse, yedekleme yalnızca BT’nin arka planda yürüttüğü bir görev olmaktan çıkar ve kurumsal süreklilik yönetiminin ölçülebilir bir bileşeni haline gelir.
Sonuç olarak sağlıklı bir SQL Server yedekleme stratejisi; doğru teknik tipleri seçmek, iş hedefleriyle uyumlu RPO/RTO belirlemek, düzenli restore testi yapmak ve izleme mekanizması kurmakla mümkündür. Bu disiplin sağlandığında ERP danışmanlığı, özel yazılım geliştirme ve dijital dönüşüm projeleri daha sağlam bir veri güvenliği zemini üzerinde ilerler.