S3, R2, B2 Cloud Yedekleme Karşılaştırması (Net Rehber)

Bulut yedekleme seçimi, sadece depolama fiyatına bakılarak yapılmaz. Yedek dosyalarını ne kadar sık okuduğunuz, geri dönüşte (restore) ne kadar geciktiği ve veri çıkış (egress) maliyetleri toplam maliyeti belirler. Bu rehberde Amazon S3, Cloudflare R2 ve Backblaze B2 servislerini; yedekleme senaryoları, performans/erişim modeli ve kurumsal güvenlik gereksinimleri açısından net şekilde karşılaştırırsınız. Hedef; “hangi servis hangi kullanımda daha doğru?” sorusuna doğrudan cevap bulmanız.

Karşılaştırma çerçevesi: Yedeklemede maliyeti neler belirler?

Bulut yedeklemede toplam maliyet, çoğu kullanıcıda “storage (depolama)” kalemine sıkışır. Oysa gerçek farkı şu kalemler yaratır:

Yazma (upload) sıklığı ve toplam veri hacmi: Aylık kaç GB yedek alıyorsunuz?
Okuma (restore) sıklığı: Normalde restore nadirdir; ama geri dönüş testleri için yılda en az birkaç kez veri okunur.
Egress (veri çıkışı) maliyeti: Veriyi buluttan sunucunuza geri indirirken veya CDN üzerinden dışarı taşırken maliyet çıkar.
İsteğe bağlı erişim hızı ve gecikme: Parça parça restore (ör. sadece belirli klasör/objeleri almak) zamanı etkiler.
Silinmeye dayanıklılık ve kilitleme: Ransomware senaryosunda yedeklerin değiştirilmeden kalması kritik olur.

Bu nedenle karşılaştırmada yalnızca GB fiyatı değil; “ne zaman ve nasıl erişeceksiniz?” sorusunu baz alacağız.

S3, R2 ve B2: Temel servis modeli farkları

Aşağıdaki tablo, yedekleme planı yaparken doğrudan işinize yarayacak teknik farkları özetler.

Kriter	Amazon S3	Cloudflare R2	Backblaze B2
Erişim uyumluluğu	S3 API (genelde sorunsuz entegrasyon)	S3 API uyumlu (araç/SDK uyumlu)	S3-compatible yaklaşımı (çoğu araç çalışır)
Veri çıkışı (egress)	Bölgeye/dağıtıma göre ücretlenir	Cloudflare ekosistemi içinde konum avantajları; egress yapısı farklıdır	Egress ücretleri tipik olarak bant genişliği üzerinden hesaplanır
Entegrasyon kolaylığı	AWS ekosistemi güçlü	Cloudflare ekosistemi + hızlı edge mantığı	Backblaze tarafında basit kullanım ve maliyet verimliliği
Yedek güvenliği (immutability)	Object Lock ile kilitleme (immutable) seçenekleri	R2 tarafında ransomware/immutability yaklaşımı Cloudflare kontrolleriyle birlikte değerlendirilir	B2’de “immutability/lock” benzeri özellikler plan ve mimariye göre ele alınır
İdeal kullanım	Kurumsal ekosistem + karmaşık senaryolar	Edge’e yakın erişim + maliyet/kullanım dengesi	Uygun maliyetli yedek depolama + pratik restore

Not: Mutlak fiyatlar zamanla değişir. Bu rehberde kritik olan “hangi maliyet davranışı sizi yakalar?”dır.

Hangi yedek tipi hangi modele daha yakın?

Soğuk arşiv (cold backup): Yılda birkaç kez restore edecekseniz depolama fiyatı ve veri çıkış senaryosu öne çıkar.
Güncel yedek (hot/near-hot backup): Daha sık restore veya parça parça geri dönüş yapıyorsanız okuma performansı ve erişim gecikmesi belirleyicidir.
Ransomware’a dayanıklı yedek: “Silinemez/ değiştirilemez” yaklaşımı (immutability) ve erişim kontrolü (least privilege) tasarımın merkezine alınmalıdır.

Senaryo bazlı net seçim: Hangisi ne zaman daha mantıklı?

Aşağıda üç tip gerçek senaryoyu ele alacağız. Her senaryoda “en doğru seçim genelde şudur” diyebilmek için belirleyici kriterleri somutlaştırıyoruz.

1) Tek uygulama + düzenli yedek: En düşük yönetim maliyeti

Bu senaryo: Tek bir uygulama sunucusu, günde 1 yedek veya saatlik diferansiyel yedek, yılda birkaç kez restore testi.

Tercih eğilimi: R2 veya B2
Neden:
Geri dönüş testi nadir olduğundan storage davranışı ve pratik maliyet dengesi öne çıkar.
S3 uyumluluğu sayesinde (SDK/araç) yönetim yükü düşer.

S3 burada otomatik olarak yanlış değildir; AWS ekosistemi zaten kullanılıyorsa (IAM, log, lifecycle yönetimi) S3 yine mantıklıdır. Ancak “yalnızca yedek” odaklı kullanıcıda R2/B2 daha hızlı değer üretir.

2) Çoklu hesap/çoklu lokasyon + kurumsal entegrasyon

Bu senaryo: Birden fazla VDS/VPS bölgesi, farklı ekiplerin yedeklediği bucket/namespace mantığı, merkezi izleme ve politika.

Tercih eğilimi: Amazon S3
Neden:
IAM, lifecycle, event entegrasyonları ve büyük ekosistem; karmaşık kontrol ihtiyacı olan yapılarda avantaj sağlar.
Restore akışları (ör. belirli klasör/objeleri seçerek alma) için otomasyon geliştirmek kolaylaşır.

R2 ve B2 de yapılır; ancak çok parçalı politika ve yönetim ekosistemi ihtiyacında S3’nin “standartlaşmış” yaklaşımı daha az sürpriz çıkarır.

3) Ransomware/insider riskine karşı kilitli yedek şart

Bu senaryo: Yedeklerin saldırı sırasında silinmesini veya üzerine yazılmasını engellemek istersiniz. En azından bazı sürümler immutable olmalıdır.

Tercih eğilimi: S3 (Object Lock) gibi net kilitleme/uygulama yaklaşımı güçlü olan tasarımlar
Neden:
Object Lock (immutable) benzeri özelliklerin mimariye net oturtulması kritik.
Saldırı senaryosunda “yedek erişim yetkisi” de en az ayrıcalık (least privilege) prensibine göre kurgulanmalıdır.

R2 ve B2 için de dayanıklılık mümkündür; ancak “hangi garanti hangi koşulda geçerli?” sorusunu dokümana dayanarak kontrol etmeniz gerekir. Bu nedenle ransomware odaklı karar, yalnızca GB maliyetiyle verilmemelidir.

Performans: Yedek yazma mı, restore mu daha önemli?

Bulut yedekleme testlerinde en sık yapılan hata: sadece upload hızını ölçmek. Oysa işletme açısından asıl stres restore anında yaşanır.

Ölçmeniz gereken 3 metrik

Upload throughput (MB/s): Yedeği buluta ne kadar hızlı gönderiyorsunuz?
Restore throughput (MB/s): Aynı dosyaları geri indirirken hız ne?
Objelerin parça parça erişim gecikmesi (latency): Büyük bir arşiv yerine klasör bazlı restore yapıyorsanız hissedilir.

Net test planı (kopyala-uygula)

1–5 GB’lık test verisi oluşturun (hem küçük hem orta boy dosyalar olsun).
3 tur yapın: - İlk tur: tam upload - İkinci tur: aynı veriyi tekrar upload (duplikasyon yaklaşımı varsa fark gözleyin) - Üçüncü tur: restore
Testi iki farklı ağ koşulunda yapın: - Ortalama saatlerde - Yoğun saatlerde
Sonuçları MB/s ve süre olarak kaydedin.

Bu verilerle “S3 daha hızlı” gibi yüzeysel iddiaları kendi ortamınızda doğrularsınız.

Maliyet hesabı: GB fiyatı yetmez, egress kuralını ekleyin

Toplam maliyeti kabaca hesaplamak için şu denklem iş görür:

Aylık depolama = (ortalama depolanan GB) × (storage birim fiyat)
Aylık yazma maliyeti = (upload GB) × (varsa işlem/istek maliyeti)
Aylık egress maliyeti = (restore veya dışarı çıkış GB) × (egress birim fiyat)
İstek (request) maliyeti: Özellikle küçük dosyalarla çalışıyorsanız request sayısı artar.

Küçük dosya çokluğu maliyeti nasıl etkiler?

Yedekleri “tek büyük tar.gz” yerine çok küçük dosyalara bölerseniz request sayısı artar. Bu durum servislerin request/istek tarifesine göre maliyet dağılımını değiştirebilir. Bu yüzden, uygulama yedeğinde: - mümkünse “diferansiyel” ve “paketleme” stratejisi uygulayın, - restore ihtiyacına göre makul dosya boyutu hedefleyin (ör. 100 MB–1 GB bandı pratikte işe yarar).

Yedek güvenliği: Anahtarlar, erişim politikası ve kilitleme

Bulut yedeklemede güvenlik üç başlıkta toplanır:

1) Erişim anahtarları (credentials)

Yedekleme aracı için ayrı bir kullanıcı/rol oluşturun.
Yalnızca gerekli izinleri verin: örneğin “yaz” + “listele” sınırları.
Restore için ayrı yetki kullanın; tek anahtar hem yedekleyip hem silebilmeli olmamalıdır.

2) Yedeklerin silinmeye karşı durumu

Object Lock/immutability benzeri özellikleri kullanacaksanız, bu özelliği etkinleştirme mantığı (hangi sürüm, hangi retention süresi) net olmalıdır.
“Admin hesabı her şeyi silebilir” tasarımı varsa, ransomware senaryosunda hedefe dönüşür. Bu yüzden politika tasarımını gözden geçirin.

3) Şifreleme

Uygulama tarafı şifreleme (client-side) + bulut tarafında saklama şifreleme kombinasyonu en sağlam yaklaşımdır.
Anahtar yönetimi (KMS) kullanan yapılar için anahtar rotasyonu ve erişim akışı önemlidir.

NetKıyas’taki seçim mantığı: Hangi sorularla karar verilir?

Kararı kolaylaştırmak için aşağıdaki kontrol listesini kullanın. Her maddeye net cevap verdiğinizde S3/R2/B2 arasında fark kendiliğinden görünür.

Yedeklediğiniz veri türü nedir? (DB dump, dosya yedek, imaj, log arşivi)
Ortalama aylık kaç GB ekliyorsunuz?
Ortalama aylık kaç GB restore için indirilir? (test restore dahil)
Yedekler küçük dosyalar mı, büyük paketler mi?
Ransomware’a karşı immutable gereksiniminiz var mı? Varsa süre hedefiniz nedir?
Mevcut altyapınız AWS mi, Cloudflare ekosistemi mi yoğun?
Otomasyon tarafında S3 API uyumu sizde ne kadar kritik?

Sonuç: Hangi servise yöneleceksiniz?

Eğer tek bir sunucudan düzenli yedek alıp restore’i nadiren yapıyorsanız ve maliyet/işlem dengesi arıyorsanız R2 veya B2 daha pratik bir başlangıç sağlar. Çoklu lokasyon, karmaşık erişim politikaları ve kurumsal otomasyon ihtiyacı öne çıkıyorsa Amazon S3 daha düşük sürprizle çalışır. Ransomware dayanıklılığı ve kilitleme (immutability) tasarımınız merkezdeyse, kararınızı doğrudan “immutable garanti ve ayar mantığı” üzerinden netleştirerek verin.

Aksiyona dönüştürmek için: Kendi veri profilinizle (küçük+orta dosya karışımı) 1–5 GB’lık bir test planı çalıştırın; upload/restore sürelerini ve tahmini egress miktarını netleştirdikten sonra servis seçimini sonlandırın.