İnkremental mi Full Backup mı? Ne Zaman Hangisi Seçilir?

Güncelleme, hatalı bir yapılandırma, disk bozulması ya da saldırı sonrası hızlı toparlanma, yedek stratejisinin nasıl kurulduğuna bağlıdır. Full backup ve inkremental backup iki temel yaklaşım; aralarındaki fark sadece “dosya miktarı” değildir. Bu yazıda iki yöntemin mantığını, geri yükleme (restore) sürelerini, saklama maliyetini ve hangi durumlarda hangisinin daha net bir seçim olduğunu somut senaryolarla anlatıyorum.

İnkremental vs Full backup: Temel farkları netleştirelim

Full backup (tam yedek) ne demek?

Full backup, seçilen veri kümesinin (ör. /var/www, veritabanı klasörleri, VM diskleri) o anki durumunu eksiksiz kopyalar. - Avantaj: Geri yükleme genellikle en hızlıdır. - Dezavantaj: Her çalışmada veri miktarı büyür; hem depolama hem de ağ aktarımı artar.

İnkremental backup (artımlı yedek) ne demek?

İnkremental backup, yalnızca “son yedekten bu yana değişen” verileri kopyalar. - Avantaj: Yedekleme süresi ve bant kullanımı çoğu senaryoda daha düşüktür. - Dezavantaj: Geri yükleme için birden fazla yedek setinin sırayla uygulanması gerekir (restore zinciri).

“İnkremental her zaman daha iyi” mi?

Hayır. İnkremental yöntem, değişim hızı düşük ve restore adımı iyi yönetilen sistemlerde çok verimli olur. Ancak yüksek değişim, sık restore ihtiyacı veya “yedek zinciri bozulursa ne olacak?” sorusu önem kazanır. Bu noktada strateji, yalnızca yedek boyutuna değil, geri yükleme hedefi (RTO) ve kayıp toleransı (RPO) mantığına göre kurulmalıdır.

Performans ve maliyet karşılaştırması: gerçek etkiler

Aşağıdaki tablo, tipik bir web/uygulama senaryosunda (dosya + veritabanı) iki yöntemin genel etkisini özetler. Kesin sayılar ortamdan ortama değişse de, karar mantığını netleştirir.

Bu tablo “tek başına karar” için değil, hangi tarafın hangi maliyeti doğurduğunu görmeniz için tasarlandı.

Ağ kullanımı ve saat seçimi

• Full backup, özellikle büyük disklerde aynı saat bandında ağ tavanına takılabilir.
• İnkremental, bant tüketimini düşürür ama restore için ihtiyaç duyulan yedek sayısını artırır.

Bu nedenle doğru zamanlama (ör. full’ı düşük trafik saatinde, inkrementali gün içine yaymak) pratikte fark yaratır.

Hangi senaryoda full backup daha net seçenek olur?

Full backup, “restore kritik” veya “yedek zinciri riskini azaltmak” isteyen ekipler için daha anlaşılır bir başlangıçtır.

1) Aylık/haftalık test restore ihtiyacı yüksekse

Yedek işe yarıyor mu sorusunun cevabı, planlı geri yükleme testleriyle doğrulanır. Test restore sıklığı yüksekse, full backup geri yüklemeyi sadeleştirir. - Öneri: Haftada bir veya ayda bir full backup + periyodik restore testi.

2) Büyük bir sistem değişikliği yapılıyorsa

Örnekler: - Büyük sürüm güncellemesi (ör. WordPress çekirdeği, uygulama major sürümü) - Disk/VM taşıma - Büyük ölçekli yapılandırma değişikliği (routing, reverse proxy, veritabanı ayarları)

Bu değişiklikten önce full backup almak, “iş bozuldu mu?” durumunda geri dönüşü hızlandırır. - Öneri: Değişiklik penceresinden hemen önce full backup, ardından inkremental ile devam.

3) Restore süresi hedefi çok sıkıysa (RTO kısa)

İnkremental zincir, adım sayısını artırdığı için RTO hedefi kısa olan sistemlerde risk büyüyebilir. - Öneri: Kritik servislerde full (ör. haftalık) + günlük inkremental gibi hibrit yaklaşım.

4) Yedekleme arızası olasılığı yüksekse veya denetim azsa

İnkremental stratejide her halka önemlidir. “Bir gün atlandı mı, hangi dosya seti eksik mi?” gibi durumların fark edilmemesi restore sırasında sürpriz çıkarabilir. - Öneri: Kontrol (log takibi, bütünlük doğrulama) zayıfsa, full sıklığını artırın.

Hangi senaryoda inkremental backup daha net seçim olur?

İnkremental yaklaşım, değişimin yönetilebilir olduğu ve yedek zincirinin sağlıklı işlendiği ortamlarda net avantaj sağlar.

1) Gün içinde yüksek güncellenen veri yoksa

Örneğin: - Web uygulaması statik sayfalar ağırlıklıysa - Veritabanı yazımı sınırlıysa - Log rotasyonu düzenliyse

Bu durumda inkremental yedek çok daha küçük olur. - Öneri: Günlük inkremental + belirli aralıklarla full.

2) Bant genişliği ve depolama bütçesi sınırlıysa

Full backup sık yapıldığında depolama maliyeti hızlı büyür. İnkremental, bu büyümeyi kontrol altına alır. - Öneri: İnkrementali sık, full’ı seyrek yaparak denge kurun.

3) Restore zinciri yönetilebiliyorsa

İyi bir stratejinin ana şartı, restore adımlarının dokümante edilmesi ve test edilmesidir. - Öneri: - Her inkremental setin hangi “base” full setine dayandığının kayıt altına alınması - Yedek bütünlüğünün doğrulanması (checksum/validasyon gibi mekanizmalar) - En azından ayda bir restore simülasyonu

4) Otomasyon ve izleme olgunluğu yüksekse

Otomasyon (backup job schedule), alarm (başarısız job bildirimi), log doğrulama gibi süreçler oturmuşsa inkremental yaklaşım sorunsuz akar. - Öneri: Başarısız inkremental yakalandığında, zinciri kırmadan stratejiyi güncelleyin.

En pratik karar yöntemi: RTO/RPO ve veri tipine göre seç

Aşağıdaki liste, karar verirken “tek bir cümleyle” hangi yönteme ağırlık vermeniz gerektiğini gösterir.

RTO (geri yükleme süresi hedefi) kısa ise

• Ağırlığı full tarafa verin.
• Hibrit plan: “Her hafta full + her gün inkremental” gibi.

RPO (kayıp toleransı) sıkı ise

• Yedek sıklığını artırın.
• Sıklık artırımı inkremental ile daha sürdürülebilir olur; fakat restore testleriyle zincirin sağlam olduğundan emin olun.

Veri tipi ağırlıklı olarak hangisi?

• Dosya sistemi (web içerikleri, statik dosyalar): Değişim azsa inkremental verimli.
• Veritabanı (MySQL/MariaDB, PostgreSQL): Transaction yoğunluğu yüksekse inkremental hızlı büyüyebilir; uygulama tutarlılığı için quiesce/consistency mekanizmalarını hesaba katın.

Hibrit yaklaşım: çoğu ekip için en net “orta yol”

Sahada en az sürpriz çıkaran model genellikle hibrittir: belirli aralıklarla full alırken aralarda inkremental ile veri güncellersiniz. Böylece hem depolama kontrolü sağlanır hem de restore zinciri aşırı uzamaz.

Örnek hibrit planlar (net takvim mantığı)

1) Küçük-orta ölçek web sitesi (gün içinde düşük değişim)

• Pazartesi: Full backup
• Diğer günler: İnkremental backup
• Her ay: restore testi (en az bir kez)

2) Gün içinde sık güncellenen uygulama

• Haftada 2 gün: Full backup (ör. Çarşamba + Cumartesi)
• Geri kalan: günlük inkremental
• Kritik güncellemeden önce: ekstra full

3) Kritik servis (RTO çok kısa)

• Haftalık full
• Günlük inkremental
• Aynı gün içinde restore hedefi varsa: inkrementali daha sık (saatlik) ama zinciri büyütmeden dengeleyin.

Restore testini “seçenek” değil “zorunluluk” yapın

Yedek almanın tek başına anlamı yoktur; restore edebilmeyi doğrulayan testler stratejinin kalitesini ölçer. - Test sırasında hedef: “doğru sürüm”, “tutarlılık”, “süre” (RTO) üçlüsünü kontrol etmek.

Net kontrol listesi: Hangi yöntemi seçerseniz seçin yapılacaklar

1) Yedeklerin bütünlüğünü doğrulayın

• Yedek job başarıyla bitiyor görünse bile içerik bozulmuş olabilir.
• Otomatik doğrulama ve kontrol raporlarını inceleyin.

2) Yedekleri farklı lokasyonda tutun

Sunucu diskinde kalan yedek, aynı hataya maruz kalır. Uzak lokasyon veya ayrı storage hedefi kullanın.

3) Restore prosedürünü yazılı hale getirin

Kim yapacak, hangi sırayla hangi set uygulanacak? Bu bilgi dokümante değilse inkremental zincirde kriz çıkar.

4) Şifreleme (encryption) ve erişim kontrolü

Yedek dosyaları saklanırken şifrelenmeli (yedek (backup) encryption). Anahtar yönetimi ayrı bir konu olsa da erişim yetkileri net olmalıdır.

5) Uyarıları (alert) etkin kullanın

Başarısız backup job’ları sessiz kalırsa inkremental zincir bozulur. Sisteminizin “yedek başarısızsa bildirim” mekanizması olmalı.

Sonuç: Kararı tek cümleye indirgemek

İnkremental backup, bant ve depolama maliyetini düşük tutup gün içi kaybı azaltmak için güçlüdür; ancak restore sırasında zincir karmaşıklığı ve halka riski doğurur. Full backup ise geri dönüşü sadeleştirir, test restore ve büyük değişiklik öncesi güven verir. En net yol çoğu senaryoda hibrit stratejidir: belirli aralıklarla full + aralarda inkremental yapın, sonra mutlaka planlı restore testiyle hedeflerinizi (RTO/RPO) doğrulayın.

Aksiyon önerisi: Mevcut yedek planınızı gözden geçirin; son 30 günde restore testi yaptınız mı? Yapmadıysanız bir hafta içinde haftalık full + günlük inkremental hibrit plan kurun ve ilk restore testini bu takvime ekleyin.