S3, R2, B2 Cloud Yedekleme Karşılaştırması (2026 Rehberi)

Cloud yedekleme seçimi; maliyet, performans (geri dönüş hızı) ve veri güvenliği üçgeninde somut farklar yaratır. Bu yazıda S3 (Amazon S3), R2 (Cloudflare R2) ve B2 (Backblaze B2) servislerini; fiyat bileşenleri, depolama/okuma-yazma mantığı, sürümleme ve silme koruması, şifreleme yaklaşımı ve pratik mimariyle karşılaştırıyorum. Okuduktan sonra hangi senaryoda hangisinin daha doğru olduğunu net şekilde eşleştireceksiniz.

Hız ve maliyet: Yedeklemede asıl ölçüm “geri dönüş”tür

Yedekleme sadece yükleme (upload) değil, gerektiğinde veriyi hızlı toparlama (restore) sürecidir. Bu nedenle seçim yaparken şu 3 metriği birlikte düşünmek gerekir:

1) Depolama maliyeti: GB-ay başına ücret (bellek değil, dosya depolama). 2) Veri transferi / istek maliyeti: Yedekleri yazarken (put), geri getirirken (get) ve listeleme yaparken (list) ücret doğar. 3) Restorasyon süresi: Aynı dosyayı tekrar indirmek için gereken süre; çoğunlukla internet bandı ve sağlayıcının veri yolu (route) ile ilişkilidir.

Aşağıdaki karşılaştırma, sadece “GB ucuz” bakışının neden yetmediğini; erişim deseniniz (çok okur musunuz, ara sıra mı, hiç mi) belirleyici olduğunu anlatır.

S3, R2, B2: Temel farklar (yedekleme odaklı)

Üç servis de “objekt depolama (object storage)” mantığında çalışır. Yedekleriniz dosya olarak bucket içinde saklanır; veri parçalara ayrılabilir, sürümleme (versioning) kullanılabilir. Ancak operasyonel farklılıklar var.

S3 (Amazon S3) ne sağlar?

• Geniş entegrasyon ekosistemi (AWS IAM, lifecycle policy, çok sayıda üçüncü parti araç).
• Sürümleme, lifecycle, silme koruması gibi yedekleme gereksinimlerine uygun özellik seti.
• Erişim kontrolü ve loglama seçenekleri geniştir.
• Genelde en yüksek “ekosistem ve seçenek” yoğunluğunu sunar; ama istek/transfer kalemleri maliyeti hızla etkileyebilir.

R2 (Cloudflare R2) neyi farklı kılar?

• Cloudflare’in ağ altyapısı ve erişim kolaylığıyla “genelde geri dönüşte daha hızlı hissettirme” hedefi taşır.
• Cloudflare tarafında bant genişliği ve istek modelleri bazı senaryolarda daha öngörülebilir maliyet çıkarır.
• Özellikle Cloudflare ekosistemiyle çalışan uygulamalarda pratiklik sağlar.

B2 (Backblaze B2) nerede öne çıkar?

• Backblaze ekosistemiyle uyumlu yedekleme çözümleri ve maliyet odaklı yaklaşım.
• Birçok kullanıcı için “maliyet/performans dengesi” hedefinde net bir alternatif.
• Sürümleme ve yaşam döngüsü yönetimi mantığı; doğru ayarlandığında yedek güvenliği için kullanılabilir.

Not: Fiyatlar kampanya ve tarihsel değişkenlik gösterebildiği için burada “kalem mantığını” anlatıyorum. NetKıyas gibi karşılaştırma platformlarında güncelim fiyat tablolarını kontrol ederek kendi kullanım değerlerinizi girmeniz gerekir.

Maliyet hesabı: Aynı 1 TB yedek için neden üç farklı sonuç çıkar?

Yedekleme maliyeti şu bileşenlerin toplamıdır: - Storage (depolama): TB/GB depoladığınız süre. - Requests (istek): Dosya yükleme (PUT), listeleme (LIST), indirme (GET), silme (DELETE). - Egress / veri transferi: Veriyi dışarı indirirken ücret doğabilir.

Aşağıdaki tablo, “yedekleme için maliyeti hangi tarafta büyüteceğinizi” özetler. (Rakam değil, etki yönü.)

Küçük dosya problemi: “GB ucuz ama istek pahalı”

Örneğin yedeklerinizi dosya başına yüzlerce parça halinde tutuyorsanız (log parçaları, temp dosyaları, kısa aralıklı segmentler), toplam request sayısı hızla büyür. Üç servis de request bazlı çalıştığından “GB ucuz” hesabı yanıltır.

Net maliyet için basit model

Kendi verinizle net tahmin yapmak için şu yaklaşımı kullanın: - Haftalık yedeklenen veri miktarı: W GB/hafta - Geri dönmeniz gereken yedek süresi: R gün - Dosya segmentleri: ortalama dosya sayısı (veya ortalama parçalama büyüklüğü)

Bu yaklaşımın pratik formu: - Ortalama depolanan miktar ≈ (W × R / 7) - Toplam istek ≈ (yedekleme başına put sayısı × yedekleme sayısı) + (restore senaryosu)

NetKıyas üzerinde karşılaştırma yaparken “storage + requests + egress” kalemlerini aynı satır mantığıyla karşılaştırın; sadece storage fiyatına bakmayın.

Güvenlik ve geri dönüş güvenliği: Sürümleme, yaşam döngüsü, silme koruması

Yedek servisinin görevi sadece veri tutmak değil; yanlışlıkla silme (accidental delete), fidye yazılımı etkisi ve hatalı overwrite durumlarında kurtarmaktır.

Sürümleme (Versioning) ve silme koruması

• Versioning açık olmalı: Aynı anahtar (object key) tekrar yazıldığında eski sürümler korunur.
• Silme koruması: “Silindi” görünen bir nesnenin kurtarılabilir olması, incident sonrası süreyi ciddi kısaltır.
• LifeCycle policy: Eski sürümleri daha ucuz sınıfa taşıma veya belirli süre sonra otomatik arşivleme.

Şifreleme (Encryption) ve anahtar yönetimi

• Nesne şifrelemesi (genellikle sunucu tarafında) standarttır.
• Daha ileri kontrol isteyenler için müşteri tarafı şifreleme veya anahtar yönetimi (KMS benzeri yaklaşımlar) tercih edilebilir.

Aşağıdaki kontrol listesi, “yedek servisinin güvenlik tarafında doğru ayarı yaptım mı?” sorusunu yanıtlar: - [ ] Sürümleme açık - [ ] Yanlış silmeye karşı restore yolu test edilmiş - [ ] Lifecycle policy ile gereksiz uzun süre tutma önlenmiş - [ ] Şifreleme açık, anahtar yönetimi ihtiyacınıza uygun - [ ] Erişim anahtarları (API keys) en az yetki (least privilege) ilkesinde

Performans: Aynı dosyayı geri indirirken neden fark görürsünüz?

Objekt depolamada “yükleme hızı” kadar “yeniden indirme hızı” önemlidir. Türkiye’den kullanımda gecikme (latency) ve sağlayıcının erişim rotası rol oynar.

Restore testi önerisi (net ve ölçülebilir)

Bir karar vermeden önce şu testi yapın: 1) 5–20 GB arası gerçek yedek segmentinden bir paket hazırlayın. 2) Servise yükleyin. 3) Aynı gün ve günün farklı saatlerinde indirme (download) süresini ölçün. 4) Aynı test paketiyle en az 2 farklı sağlayıcı arasında karşılaştırma yapın.

Bu test, sadece teoriyi değil; sizin gerçek restore deseninizi yansıtır.

CDN ile akıl karıştırmayın

Bazen CDN kullanınca “hız” artar gibi görünür. Yedekte esas olan: restore akışının “yedek çözümünüzde gerçekten nereden geldiği”. Restore işlemi, doğrudan object storage endpoint’inden mi gidiyor yoksa CDN üzerinden mi akıyor? Bu netleştirilmeden performans karşılaştırması yanıltıcı olur.

Hangi servis hangi senaryoda daha mantıklı? (Net eşleştirme)

Aşağıdaki seçim rehberi, “yedekleme deseni”ne göre yapılmıştır.

1) Kurumsal ekosistem ve karmaşık politika isteyenler

Tercih eğilimi: S3 - IAM, entegrasyon ve policy çeşitliliği yüksek. - Lifecycle ve erişim loglama ihtiyacı gelişmiş olduğunda S3 pratik olur.

2) Cloudflare kullanan altyapılarda basit ve performans hissi odaklı yaklaşım

Tercih eğilimi: R2 - Cloudflare ile çalışan sistemlerde operasyonel kolaylık. - Özellikle uygulama katmanı restore/erişim kalıbı sık kullanılıyorsa R2 avantaj sağlayabilir.

3) Maliyet odaklı ve yedek depolamayı “basit” tutmak isteyenler

Tercih eğilimi: B2 - Depolama ve istek kalemlerinin yönetimi; yedek bütçesi planlayanlar için net hedef olur.

Kritik nokta: “Tek bir servis” değil, çoğu sağlam kurgu iki katmanlı düşünür. Birincil servis (primary) + ikincil servis (secondary) veya aynı serviste farklı bölge/hesap stratejisi.

En iyi pratik mimari: Tek bucket yerine katmanlı yedek planı

Cloud yedekleme servislerinde en sık yapılan hata, yalnızca “veriyi saklamak”. Oysa gerçek gereksinim üç adım:

1) Yedek üretimi: Uygulama/VM/veri tutarlı (consistent) şekilde alınmalı. 2) Depoya yazma: Nesneler parçalara ayrılıyorsa boyut ve segmentleme planı yapılmalı. 3) Restore testi: Ayda en az bir kez seçili dosyalarla geri dönüş doğrulanmalı.

Dosya segmentleme (segment size) için net hedef

• Çok küçük parçalar request’i şişirir.
• Çok büyük parçalar ise restore sırasında tek paket problem yaratır.
• Pratikte orta boy segmentler (ör. 1–50 GB bant aralığı) birçok senaryoda daha dengeli olur.

Sık yapılan 7 hata ve net çözüm

1) Sadece depolama ücretine bakmak → Requests + egress kalemlerini aynı tabloda karşılaştırın. 2) Versioning kapalı bırakmak → Yanlış silme ve overwrite riskinde restore imkanı azalır. 3) Restore testini ertelemek → “Kayıp anında” test yoktur; önceden ölçün. 4) Küçük dosya yığınları oluşturmak → Segmentlemeyi optimize edin, gereksiz dosyaları filtreleyin. 5) Erişim anahtarlarını geniş yetkide tutmak → Least privilege uygulayın; ayrı roller kullanın. 6) Lifecycle policy’yi düşünmeden açmak → Gereksiz veri kaybına yol açabilir; önce plan, sonra uygulama. 7) Tek servis bağımlılığı → En az iki aşamalı plan kurun (primary + secondary).

NetKıyas’ta karar verirken nasıl ilerleyin? (Aksiyon planı)

09.11.2026 itibarıyla en doğru seçim, “hangi servis daha ucuz?” sorusundan önce şu 4 soruyu netleştirmenizle başlar:

1) Yedekleriniz kaç GB ve ayda kaç kez yazılıyor? 2) Restore ihtiyacı ne sıklıkta ve ne büyüklükte? 3) Dosyalar küçük mü büyük mü? (request sayısını belirler) 4) Versioning ve silme koruması sizin için zorunlu mu?

Bu bilgileri çıkarın; ardından NetKıyas’ta S3, R2, B2 odaklı karşılaştırmayı storage + request + transfer mantığıyla yapın. Son adım olarak, seçtiğiniz 1–2 servis için aynı gün içinde küçük bir restore testi gerçekleştirin.

Sonuç: Bulut yedekleme servisinde doğru tercih, sadece fiyat etiketinden çıkmaz; geri dönüş (restore) hızı, request kaynaklı maliyet, sürümleme/silme koruması ve gerçek restore denemesi ile netleşir. Önce ölçülebilir kullanım deseninizi belirleyin, sonra S3/R2/B2’den “en az sürpriz çıkaracak” olanı seçip düzenli restore testiyle doğrulayın.