İnkremantal (incremental) mi Full backup mı? Ne zaman hangisi?

Günlük operasyonlarda en kritik sorulardan biri şudur: Sunucuda ya da uygulamada bir sorun çıktığında veriyi ne kadar hızlı ve ne kadar eksiksiz geri getirebilirim? Backup (yedekleme) yaklaşımının seçimi, hem güvenliği hem maliyeti hem de geri dönüş süresini (RTO) doğrudan etkiler. Bu rehberde inkremantal (incremental) ve full backup (tam yedek) stratejilerini ayıran noktaları; hangi durumda hangisinin “net” tercih olduğunu örneklerle anlatıyoruz. Hedef; okuduktan sonra “bizim senaryomuzda hangisi daha mantıklı?” kararını hızla verebilmeniz.

Backup türleri: Mantık farkı neden önemli?

Full backup, belirlenen zamanda tüm seçili verileri eksiksiz yedekler. İnkremantal backup ise son yedeklemeden bu yana değişen blokları ya da dosyaları temel alır.

Bu fark şu üç metrikle birlikte düşünülür: - RPO (Recovery Point Objective): Arıza anına göre kaç dakikaya/sloğa kadar veri kaybı kabul edilebilir? - RTO (Recovery Time Objective): Sistemi kaç sürede geri ayağa kaldırmak gerekir? - Yedekleme penceresi (backup window): Gün içinde yedekleme için ayrılabilen zaman aralığı.

İnkremantal yaklaşım genelde depolama maliyetini ve yedekleme süresini düşürür; çünkü her seferinde her şeyi kopyalamaz. Ancak geri dönüşte “zincir” mantığı oluşur: Son halinize ulaşmak için birden fazla inkremantal seti bir araya getirmeniz gerekebilir. Full backup, geri yükleme adımını sadeleştirir; ancak her seferinde daha fazla veri üretir.

Full backup ne zaman daha “net” avantaj sağlar?

Full backup şu koşullarda daha net bir tercihtir: - Hızlı geri dönüş ihtiyacı vardır: RTO kısa hedeflenir. - Yedek doğrulama/geri yükleme sürecinin mümkün olduğunca az adımda tamamlanması gerekir. - Değişim oranı görece düşüktür (ör. haftalık döngüde nadiren güncellenen içerik, arşiv sistemleri). - İnkremantal zincirlerin büyümesi risklidir (uzun süre boyunca sık inkremantal alıp sonra arşiv kayması/bozulması yaşamak gibi).

İnkremantal backup ne zaman daha “net” avantaj sağlar?

İnkremantal şu koşullarda belirgin şekilde öne çıkar: - Veri değişim oranı yüksektir: Dosyalar/sistem blokları gün içinde sık güncellenir. - Depolama ve ağ maliyeti sınırlıdır: Her seferinde full atmak bütçeyi zorlar. - Kayıp toleransı görece yüksektir ama toplam risk yönetilebilir: RPO hedefi inkremantal frekansla tutturulur. - Geri yükleme sürecini pratikte yönetebilecek disiplin vardır: düzenli restore testi (geri yükleme testi) yapılır.

Karar matrisi: RPO/RTO’ya göre seçim

Aşağıdaki tablo “hangi yedek yaklaşımı daha çok iş görür?” sorusunu netleştirmek için pratik bir başlangıç çerçevesi sunar.

Not: Burada “en iyi” tek bir doğru değildir. NetKıyas bakışıyla, seçim; hedeflediğiniz RPO/RTO ile yedekleme penceresi ve doğrulama kapasitenizi birlikte kapsamalı.

Uygulamada en sık görülen yanlışlar

İnkremantal vs full tartışmasının pratikte kırıldığı nokta çoğu zaman teknik detaydan ziyade süreç disiplinidir.

1) İnkremantal zincirini test etmemek

Sadece “yedek alındı” loguna bakmak, geri yükleme kabiliyetini garanti etmez. Özellikle inkremantal zincirlerde tek bir set bozulursa “son hal” üretilemeyebilir. - Çözüm: Ayda en az 1 kez restore (geri yükleme) testi yapın. - Test çıktısı: Uygulama ayağa kalkıyor mu, veriler tutarlı mı?

2) Gereğinden uzun yedekleme aralığı

Örneğin günlük inkremantal alıp “1 saat kayıp kabul edilebilir” diyorsanız, hedefle uyumsuzluk yaşanır. Böyle durumlarda RPO fiilen tutmaz. - Çözüm: RPO hedefinizi belirleyin; inkremantal sıklığını ona göre ayarlayın.

3) Full backup’ın her şeyi çözmesini beklemek

Full backup, geri yükleme kolaylığı sağlar; fakat her gün full almak depolama maliyetini hızlı artırır. Üstelik yedekleme penceresi uzarsa üretim tarafında performans etkisi doğabilir. - Çözüm: “Full ne sıklıkta?” sorusunu veri değişim oranı ve yedekleme penceresiyle birlikte yanıtlayın.

Net karar planı: 5 adımda seçim

Aşağıdaki adımlar, inkremantal ve full backup arasında net bir seçim yapmak için hızlı bir yol haritası sunar.

1) RPO/RTO hedefini yazın (sayıyla)

• RPO: "Kurtarma anında en fazla X dakika veri kaybı kabul ediyorum"
• RTO: "Sistemi en geç Y saat içinde ayağa kaldırmalıyım"

2) Değişim oranını ölçün

Uygulama ve veritabanı tarafında günlük değişim oranı pratikte şunu belirler: - Değişim azsa full backup daha ekonomik olabilir. - Değişim çoksa inkremantal maliyet/performans avantajı sağlar.

3) Yedekleme penceresini gerçekçi hesaplayın

Örnek: Saat 02:00-04:00 arası yedek için boşsa, full backup’ın tamamlanması mutlaka bu aralığa sığmalı.

4) Saklama (retention) kuralını belirleyin

Saklama, maliyeti belirleyen ikinci büyük faktördür. Örneğin: - 7 günlük inkremantal + 4 haftalık periyodik full - 30 günlük saklama + haftalık full taban

5) Restore testini planlayın

İnkremantal stratejilerde restore testi kritik önemdedir. - En az 1 “son hal” testi - En az 1 “belirli tarih geri dönüş” testi

Pratik örnekler: Hangi sıklık daha mantıklı?

Aşağıdaki örnekler, sayısal hedefler üzerinden “ne zaman full, ne zaman inkremantal?” sorusunu somutlaştırır.

Örnek A: E-ticaret sitesi (DB yoğun, değişim yüksek)

• Tahmin: Sipariş ve stok güncellemeleri sık
• RPO hedefi: 15 dakika
• RTO hedefi: 2 saat

Öneri yaklaşım: - Full backup: haftada 1 (ör. Pazar gecesi) - İnkremantal backup: her 15 dakikada bir ya da en az 30 dakikada bir (DB tarafında log/işlem bazlı strateji de kullanılabilir) - Doğrulama: haftada 1 restore testi (en azından DB konsistensi)

Neden? - 15 dakikalık RPO için inkremantal frekans gerekir. - Full taban haftalık olduğu için zincir uzunluğu yönetilebilir.

Örnek B: Blog/katalog (içerik değişimi daha düşük)

• RPO hedefi: 1 gün
• RTO hedefi: 1 gün

Öneri yaklaşım: - Full backup: her gece veya haftalık (değişim hızına göre) - İnkremantal: opsiyonel; günlük değişim çok düşükse maliyeti artırmadan sadece kritik dizinler için

Neden? - RPO “gün” seviyesindeyse inkremantal frekansı zorunlu değildir. - Full strateji geri yüklemeyi basitleştirir.

Örnek C: Yeni kurulan proje (test/dev ortamı)

• RPO hedefi: saatler
• RTO hedefi: aynı gün

Öneri yaklaşım: - Full backup: haftada 1 veya iki haftada 1 - İnkremantal: günlük (ya da sadece konfigürasyon dosyaları için)

Neden? - Restore zamanı “üretim kadar kritik” değildir. - Maliyet kontrolü ön plandadır.

Performans ve maliyet: Yedekleme ağı ve depolama gerçeği

İnkremantal daha az veri ürettiği için genellikle: - daha kısa backup süresi - daha düşük ağ trafiği - daha düşük bulut depolama maliyeti sağlar.

Full backup ise: - daha çok veri üretir - depolama maliyetini yükseltir - geri yüklemede daha az adım avantajı sağlar

Burada net eşik şudur: Depolama birimi ve aktarım hızı (özellikle yedekler dış depolamaya gidiyorsa) “full’ı her zaman” maliyetli yapar.

Yedekleme mimarisi: Nerede saklamak belirleyicidir

NetKıyas’ta birçok kullanıcı “yedek var mı?” sorusuna odaklanır; doğru soru “yedek nerede ve erişim nasıl?” olmalı.

Önerilen mimari: - Üretim sunucusu üzerinde anlık yedek üretimi - Ardından yedeklerin dış depolama (off-site) alanına aktarımı - Dış kopya için farklı arıza senaryolarını düşünme (aynı veri merkezinde yaşanacak kesinti gibi)

Bu yaklaşım, sunucunun kendisi arızalansa bile geri dönüş şansını korur.

Doğrulama ve geri yükleme: Kararın tamamlayıcısı

İnkremantal ve full arasındaki farkın pratik karşılığı “geri yükleyince gerçekten çalışıyor mu?” sorusudur.

Restore testinde kontrol listesi

• Uygulama ayağa kalkıyor mu?
• Veritabanı (DB) tutarlı mı?
• Dosya izinleri ve bağlantı (konfigürasyon) doğru mu?
• Beklenen tarihteki veriyi görme mümkün mü?

Basit kural

• Full backup: Restore süreci genelde daha hızlı ve daha az bağımlılık içerir.
• İnkremantal backup: Restore, zincirin doğru ve eksiksiz olduğuna bağlıdır; bu yüzden test sıklığı artmalıdır.

Sonuç: Net aksiyon önerisi

İnkremantal vs full backup tartışmasında tek bir “herkese uyan” cevap yoktur; ancak doğru kurguda karar netleşir: RPO hedefiniz dakika/15 dakika seviyesindeyse inkremantal frekansı zorunludur, RTO kısa ise düzenli full taban (zincir yönetimi için) gereklidir. En sağlıklı başlangıç planı genellikle “periyodik full + sık inkremantal”dır; ardından en kritik adım olarak ayda en az 1 restore testiyle yaklaşımınızı doğrulayın. Hedeflerinizi (RPO/RTO), değişim oranınızı ve yedek penceresi gerçekliğinizi yazın; bu üç veriyle seçim yaptığınız anda yedek stratejisi “tartışma” olmaktan çıkıp uygulanabilir bir plan haline gelir.