S3 vs R2 vs B2: Cloud Yedekleme Servislerini Net Karşılaştırma

Cloud yedekleme seçimi; yedekleme (backup) maliyeti, geri dönüş süresi (RTO) ve geri alma kolaylığı (restore) gibi kritik etkiler yaratır. Aynı veri miktarında bile S3, R2 ve B2 arasında maliyet ve iş akışı farkları belirginleşir. Bu rehberde, objenize veri depolama, yaşam döngüsü politikaları ve uygulama entegrasyonu perspektifinden üç servisi net kıyaslayacaksınız.

1) Üç servis neyi hedefliyor? (S3, R2, B2)

Aynı adı taşıyan “object storage” sınıfında olsalar da hedef kitleleri farklıdır.

Amazon S3 (Simple Storage Service)

• AWS ekosistemiyle en güçlü entegrasyon (IAM, CloudWatch, Lambda, Glacier/Deep Archive)
• Geniş bölgesel altyapı ve çok katmanlı depolama seçenekleri
• Standart S3 maliyeti çoğu senaryoda “baz fiyat” gibi görünse de uzun vadeli depolamada sınıf içi geçiş maliyetleri (storage class) devreye girer

Cloudflare R2

• “S3 uyumlu” API: Aynı mantıkta çalıştırılabilen uygulamalar için geçişi hızlandırır
• Cloudflare ağı üzerinden veri erişimini optimize eden yaklaşım
• Bulut çıkışı (egress) modelinde farklılıklar görülebilir; maliyet hesabında çıkış oranı belirleyicidir

Backblaze B2

• Backblaze ekosistemi (özellikle B2 Cloud Storage + Bunker/diğer ürünler) içinde yedekleme odaklı paketleme
• Objektif fiyat/performans iddiası: düşük birim depolama maliyeti sık görülür
• Uygulama tarafında yine S3 uyumluluğu avantaj sağlar

Not: Bu yazı “hangisi en ucuz” sorusuna tek satır cevap vermek yerine; hangi parametreyle maliyetin değiştiğini netleştirerek seçim yaptırır.

2) Maliyet karşılaştırması nasıl yapılmalı?

Yedeklemede maliyeti belirleyen kalemler genelde 4 başlıkta toplanır: 1) Depolama (GB-ay) 2) Veri çıkışı (egress) 3) API istekleri (PUT/LIST/GET) 4) Yaşam döngüsü (lifecycle) ile sınıf geçişleri ya da arşiv katmanı maliyetleri

Aşağıdaki tablo, aynı veri senaryosunda üç servisi karşılaştırmak için hangi kalemleri ayırt etmeniz gerektiğini özetler. Fiyatlar sağlayıcıya göre güncellendiği için bu tabloda “kesin TL” vermek yerine karar mantığını net kuruyoruz.

Net hesap için pratik formül

Bir “kapsamlı” kıyas yerine, şu formülü her servise uygulayın: - Aylık maliyet = Depolama + (Aylık egress GB × egress birim fiyat) + (Aylık istek sayısı × istek birim fiyat) + (lifecycle/restore maliyeti varsa ekle)

Bu sayıları nereden alacaksınız? - Uygulamanız zaten “backup push” yapıyorsa mevcut loglarınızdan günlük PUT/GET sayısını çıkarabilirsiniz. - Restore senaryosunda (ör. ayda 1 defa 200 GB geri alma) egress/restore maliyetini özellikle tartın.

3) Erişim ve restore hızı: RTO’yu nasıl etkilersiniz?

Yedekleme servisinin “hızı” ikiye ayrılır: - Objekt depoya yazma/okuma hızı (upload/download throughput) - Uygulamanın geri alma akışı (restore pipeline)

S3 / R2 / B2’de ortak risk: küçük dosyalar

• Binlerce küçük objeyi (ör. 1-5 MB) sık sık yüklerseniz LIST/GET/PUT istek sayısı artar.
• Bu durumda “tek seferde çok büyük dosya” yaklaşımı genellikle daha maliyet ve hız açısından avantajlı olur.

Net öneri: yedek paketleme (pack) stratejisi

Aşağıdaki yaklaşım restore süresini de öngörülebilir kılar: - Veriyi arşivleyin (örn: tar/zstd veya uygulama içi paketleme) - Sonra paketleri objeniz olarak yükleyin - “Her dosya” yerine “her snapshot” mantığıyla objeleri üretin

Örnek karar: - WordPress gibi binlerce dosyalı sistemlerde: dosyaları tek bir arşiv halinde (bölümleme ile) saklamak, küçük dosya istek maliyetini azaltabilir. - Veritabanlarında: dump + sıkıştırma + versiyonlama ile snapshot üretin.

4) Yaşam döngüsü (lifecycle) ve versiyonlama: maliyeti belirleyen kısım

Yedekleme sadece saklamak değildir. Üç kritik soruya net cevap gerekir: 1) Kaç gün “hot” (standart) saklayacağım? 2) Ne zaman daha düşük maliyetli katmana geçeceğim? 3) Kaç nokta-in-time (point-in-time) tutacağım?

S3 tarafı: storage class geçişleri

S3’de yaşam döngüsü kuralı kurarken storage class geçişlerini net tanımlayın: - 0-30 gün: Standart - 31-90 gün: Daha düşük maliyetli sınıf - 90+ gün: Arşiv katmanı (gerektiğinde restore süresi artabilir)

R2 tarafı: arşiv mimarisini planlayın

R2’de yaşam döngüsü ve sınıf modeli, S3 kadar katmanlı kullanılmayabilir. Bu yüzden: - Hangi veriyi “her gün erişeceksiniz”, hangisini “ayda bir restore edeceksiniz” netleştirin - Uygulama restore gereksinimlerine göre mimari seçin

B2 tarafı: yedekleme odaklı saklama modeli

B2’de genelde yedekleme kullanımına uygun bir maliyet profili yakalanır. Yine de şu noktayı kesinleştirin: - Snapshot sayısı (ör. günlük 1, haftalık 1, aylık 1) - Snapshot başına ortalama veri boyutu - Restore sırasında kaç snapshot geri alacağınız

5) Entegrasyon (uyumluluk) ve güvenlik: işin “kolay restore” boyutu

Yedekleme servisinin “S3 uyumluluğu” pratikte şunları etkiler: - Mevcut araçların (backup istemcileri, open-source backup yazılımları) geçiş süresi - Kimlik ve erişim (IAM/anahtar yönetimi) - Ağ erişimi politikaları

S3 uyumluluğu ne zaman karar belirler?

• Mevcut sisteminiz zaten S3 API’si kullanıyorsa geçiş daha az riskli olur.
• Uygulamanız “S3 imzaları / endpoint / region” gibi detaylara bağımlıysa küçük farklılıklar çıkabilir.

Kimlik yönetimi: servis anahtarları ve yetki sınırı

Net kural: - Yedekleme için kullanılan erişim anahtarı sadece gerekli bucket/prefix’lere yetkili olmalı. - Üretim sisteminiz ile yedek erişim anahtarını aynı yetkide birleştirmeyin.

6) Net seçim rehberi: hangi servis hangi senaryoda doğru?

Aşağıdaki listeler “en iyi” değil “en uygun” seçim mantığıdır.

Amazon S3 seçin, eğer

• AWS üzerinde çalışan altyapınız varsa (EC2/EKS/Lambda) entegrasyon sizin için maliyet ve operasyon avantajı yaratıyorsa
• Uzun vadeli arşiv senaryolarında restore süresi artışını göze alabiliyorsanız
• Çok gelişmiş izleme/otomasyon (CloudWatch vb.) ile yedek akışını uçtan uca yönetmek istiyorsanız

Cloudflare R2 seçin, eğer

• S3 uyumlu API ile mevcut araçları hızlı taşımak istiyorsanız
• Cloudflare ekosistemiyle veri erişimini optimize etmeyi hedefliyorsanız
• Erişim deseniniz “internet üzerinden indirme/servis” tarafında yoğun ve maliyet hesabında çıkış kalemi kritik ise

Backblaze B2 seçin, eğer

• Yedekleme maliyetini GB-ay bazında agresif optimize etmek istiyorsanız
• Yedek odaklı pratik süreçler ve basit kullanım hedefliyorsanız
• Küçük/orta veri setlerinde snapshot stratejisi kurup maliyeti istek desenine rağmen kontrol etmek istiyorsanız

7) Tek bir doğru karar için kontrol listesi (kısa, uygulanabilir)

Aşağıdaki maddeleri yanıtlayın; cevaplar genellikle tek serviste netleşir.

• Aylık depolama (GB-ay): 1 TB mı, 10 TB mı, 100 TB mı?
• Aylık egress: Restore için ayda kaç GB indirilecek? Yedekleri kullanıcı/sistem mi indiriyor?
• Dosya yapısı: Tek büyük arşiv mi, binlerce küçük dosya mı?
• Snapshot sıklığı: Günlük/haftalık/aylık kaç point-in-time tutuyorsunuz?
• Restore RTO hedefi: 1 saat mi, 6 saat mi, 24 saat mi?
• Operasyon ekibi: IAM politikalarını ve anahtar rotasyonunu kim yönetecek?
• Mevcut araç bağımlılığı: S3 uyumlu mu, yoksa platformdan bağımsız mı?

Sonuç: Küçük bir pilot ile “gerçek maliyet” çıkarın

Tek bir servis seçmeden önce 2-4 haftalık pilot yapın: Aynı yedek akışını üç servise de gönderin ve depolama + istek + egress kalemlerini gerçek loglarınızdan toplayın. Bu yaklaşım, fiyat tablolarına bakarak yapılan hatalı karşılaştırmayı engeller. Pilot sonunda RTO hedefinizi de test edin; restore süresi yetmiyorsa “ucuz ama geç geri alma” maliyetini hesaba katmış olursunuz.

NetKıyas’ta aradığınız şey “etiket” değil; sizden istenen çıktıyı (yedek güvenliği + geri alma hızı + maliyet öngörülebilirliği) sağlayan mimari. Bu yazıdaki kontrol listesiyle pilot çıktılarınızı kıyaslayın ve seçiminizi veriyle sabitleyin.