SQL Server Yedekleme Neden Kritik?
Kurumsal müşterilerimizle yaptığımız saha çalışmalarında gördüğümüz tekrarlayan bir tablo var: şirketin ERP, muhasebe veya CRM sistemi SQL Server üzerinde çalışıyor, günlük işlemlerin yüzde 80'i bu veritabanından geçiyor ama yedekleme planı 5-6 yıl önce bir ajans tarafından kurulmuş, o günden sonra kimse dokunmamış. Veritabanı büyüdükçe disk alanı doluyor, yedekleme işi hiç kimseye ait olmadığı için başarısız oluyor ve kimse fark etmiyor.
SQL Server'da veri kaybı sadece disk arızasından kaynaklanmaz. Fidye yazılımı saldırısı, yanlışlıkla silinen tablo, hatalı bir DELETE komutu, güncelleme sırasında yaşanan kesinti — bunların hepsi gerçek senaryolardır. 2023-2024 arasında müdahale ettiğimiz olayların yaklaşık üçte birinde sorun donanımdan değil, insan hatası veya siber saldırıdan kaynaklandı. Bu noktada tek soru şu: elinizdeki yedekten ne kadar hızlı ve ne kadar güvenilir şekilde dönebiliyorsunuz?
Yedekleme Türleri ve Doğru Strateji Seçimi
SQL Server'ın sunduğu üç temel yedekleme türünü doğru kombinasyonla kullanmak, yedekleme stratejisinin omurgasıdır. Full Backup, veritabanının tamamının anlık görüntüsünü alır; genellikle büyük veritabanlarında haftalık, orta ölçekli sistemlerde günlük planlanır. Differential Backup, son full backup'tan sonra değişen verileri yedekler ve full backup'a göre çok daha hızlı tamamlanır — 200 GB'lık bir veritabanında full backup 40 dakika sürerken differential backup genellikle 5-8 dakikada biter. Transaction Log Backup ise en kritik katmandır; genellikle 15 dakikada bir alınır ve veri kaybını saniyeler seviyesine indirir.
Simple Recovery Model kullanan birçok firma transaction log backup'ı hiç çalıştırmıyor çünkü recovery model ayarı yanlış seçilmiş. Bu durumda log dosyası kontrolsüz büyüyor ve disk doluyor; aynı zamanda "point-in-time recovery" yani belirli bir saate geri dönme imkanı tamamen kaybediliyor. AFN Teknoloji olarak sahaya çıktığımız projelerin yaklaşık yarısında ilk müdahalemiz recovery model'i Full'e çevirmek ve log backup zincirini kurmak oluyor.
Yedekleme sıklığı tek başına yeterli değil; sıkıştırma oranı da maliyeti doğrudan etkiliyor. SQL Server'ın native backup compression özelliği devreye alındığında, ortalama bir OLTP veritabanında yedek dosya boyutu yüzde 50-70 küçülüyor. Bu, hem depolama maliyetini düşürüyor hem de yedekleme süresini kısaltıyor; disk I/O baskısı altında çalışan canlı sistemlerde bu fark kritik önem taşıyor.
RPO/RTO Hesaplaması ve Gerçek Müşteri Senaryoları
Yedekleme stratejisi kurarken sorulması gereken iki temel soru RPO (Recovery Point Objective — ne kadar veri kaybını kabul edebilirsiniz) ve RTO (Recovery Time Objective — sistemi ne kadar sürede geri ayağa kaldırmanız gerekiyor) sorularıdır. Üretim hattı yöneten bir sanayi müşterimizde RTO hedefi 2 saatti; sadece günlük full backup ile bu hedefe ulaşmak mümkün değildi çünkü 1,2 TB'lık veritabanının restore işlemi tek başına 3 saat sürüyordu. Differential backup katmanını ekleyip restore sırasını optimize ederek bu süreyi 55 dakikaya çektik.
Bir diğer örnek, e-ticaret sektöründeki bir müşterimizdeydi: RPO hedefi 5 dakikaydı çünkü her dakika kaybedilen sipariş verisi doğrudan gelir kaybına dönüşüyordu. 15 dakikalık log backup aralığını 5 dakikaya indirip, Always On Availability Groups ile ikinci bir replika sunucu kurarak hem RPO hedefini karşıladık hem de okuma yükünü ikinci node'a dağıttık. Bu kurulum sayesinde ana sunucuda yaşanan bir donanım arızasında otomatik failover süresi 30 saniyenin altına indi.
Veeam Entegrasyonu ile VM Seviyesinde Koruma
AFN Teknoloji olarak yedekleme stratejisini sadece SQL Server native backup komutlarıyla sınırlı tutmuyoruz. Veeam iş ortaklığımız sayesinde VM seviyesinde application-aware yedekleme kurarak hem sanal makinenin tam görüntüsünü hem de SQL Server içindeki veritabanı tutarlılığını (VSS entegrasyonu ile) tek bir yedekleme işleminde güvence altına alıyoruz. Bu yaklaşım, sadece dosya seviyesinde yedek alıp veritabanı tutarlılığını riske atan klasik yöntemlere göre çok daha güvenilir bir kurtarma noktası sunuyor.
Veeam'in SureBackup özelliğiyle her gece alınan yedeklerin otomatik olarak izole bir ortamda ayağa kalkıp kalkmadığını test ediyoruz. Bu, "yedek alındı ama restore edilemedi" riskini ortadan kaldıran en kritik adımdır; çünkü deneyimlerimize göre test edilmeyen yedeklerin yüzde 10-15'i kritik anda açılmıyor. Ayrıca 3-2-1 yedekleme kuralını (3 kopya, 2 farklı ortam, 1 off-site) Veeam ile bulut depolama entegrasyonu üzerinden uyguluyor, siber saldırı senaryolarına karşı immutable (değiştirilemez) yedek kopyaları oluşturuyoruz.
AFN Teknoloji Olarak Sunduğumuz SQL Server Yedekleme Hizmeti
AFN Teknoloji olarak 2008'den bu yana İstanbul merkezli faaliyet gösteren ekibimiz, SQL Server altyapısı olan kurumsal müşterilere uçtan uca yedekleme danışmanlığı veriyor: mevcut yedekleme zincirinin sağlık analizi, recovery model optimizasyonu, backup job'larının SQL Server Agent veya Veeam üzerinden yeniden kurulması ve restore test otomasyonunun devreye alınması. Microsoft iş ortaklığımız sayesinde lisans danışmanlığından SQL Server sürüm uyumluluğuna kadar teknik detayları da aynı ekip içinde yönetiyoruz.
Müşterilerimiz bize genellikle üç tipik sorunla geliyor: yedekleme işi sessizce günlerdir başarısız oluyor ve kimse fark etmemiş, disk alanı doluyor çünkü log backup hiç çalışmamış ya da bir önceki IT firması yedekleme planını kurmuş ama hiçbir zaman test etmemiş. Her üç senaryoda da ShamashAI izleme platformumuzu devreye alarak backup job durumunu, disk kapasitesini ve log dosyası büyümesini gerçek zamanlı olarak takip ediyor, eşik değer aşıldığında ilgili ekibe otomatik bildirim gönderiyoruz. Bu sayede "yedek sorunu" artık haftalar sonra fark edilen bir kriz değil, anlık olarak çözülen bir uyarı haline geliyor.
Yedekleme stratejinizin gerçekte ne kadar güvenli olduğunu merak ediyorsanız varsayımlarla hareket etmeyin. AFN Teknoloji olarak sunduğumuz ücretsiz AFN RiskScan taramasıyla SQL Server ortamınızdaki yedekleme açıklarını, recovery model hatalarını ve test edilmemiş restore noktalarını somut bir raporla ortaya koyuyoruz. Taramayı planlamak ve mevcut yedekleme sağlığınızı öğrenmek için https://afnteknoloji.com/iletisim adresinden bizimle iletişime geçebilirsiniz.