S3, R2 ve B2: Bulut Yedekleme Servisleri Net Karşılaştırma

Bulut yedekleme; arıza, silme (accidental deletion) ve fidye yazılımı senaryolarında kurtarma sürenizi (RTO) doğrudan etkiler. Ancak depolama alanını “ucuz” diye seçmek tek başına doğru değildir; egress (çıkış trafiği), erişim modeli (API/uyum), şifreleme ve saklama (retention) prensipleri toplam maliyeti belirler. Bu rehberde Amazon S3, Cloudflare R2 ve Backblaze B2’yi; maliyet kalemleri, mimari uygunluk, performans pratikleri ve güvenlik kontrol listesi üzerinden net karşılaştıracaksınız.

1) Servisleri aynı zeminde karşılaştırma: Yedekleme için kritik parametreler

Bulut depolama servisleri arasında karar verirken tek bir fiyat satırı yetmez. Yedekleme için en belirleyici başlıkları önce netleştirin:

Hangi iş yükü?

Sıcak yedek (sık okuma / sık geri dönüş): Log arşivi, sık restore edilen veri.
Soğuk yedek (seyrek okuma / uzun saklama): Görsel arşivi, uzun dönem arşiv, dokümantasyon.
Yedekleme sıklığı: Günlük, haftalık, aylık.
Restore ihtiyacı: Tam geri yükleme mi, dosya bazlı restore mı?

Maliyet hangi kalemlerden oluşur?

Depolama (GB-ay)
Yedekleme sırasında yazma (upload) maliyeti her zaman görünmez; asıl fark çoğu zaman egress tarafında çıkar.
Geri indirme (download) = egress
Veri aktarımı + istek maliyetleri (API request): özellikle küçük dosyalarda artar.
Ek özellikler: sürümleme (versioning), yaşam döngüsü kuralı (lifecycle), saklama politikaları.

Mimari fark: S3 uyumluluğu

Amazon S3: “S3 standardı”nın referansı.
Cloudflare R2: “S3 API uyumlu” yaklaşımıyla pratikte aynı araçlarla kullanılır.
Backblaze B2: S3 uyumlu araçlarla çalışır; pratikte benzer ekosistem sağlar.

Bu farklar, aynı yedekleme aracını (ör. rclone, SDK’lar, arşivleme script’leri) farklı servislerde kullanabilmenizi etkiler.

2) Maliyet karşılaştırması: En çok para nerede yanar?

Bulut yedeklemede “ucuz depolama” tuzağı çok yaygındır. Toplam maliyeti belirleyen ana kırılım egress ve restore desenidir.

Aşağıdaki tablo “ortalama bir yaklaşım” sunar; net fiyatlar bölgeye/ek özelliklere göre değişir. Yine de karar mantığı aynıdır.

| Kriter | Amazon S3 | Cloudflare R2 | Backblaze B2 | |---|---|---| | Depolama birimi | Çok seçenekli sınıflar (standart, IA vb.) | Basit depolama yaklaşımı | Genelde net ve tutarlı fiyatlama | | Egress (çıkış) | Sıkça toplam maliyetin ana kalemi | Çoğu senaryoda maliyeti aşağı çekebilir | Uygun egress konfigürasyonları ile öne çıkar | | İstek (request) etkisi | Küçük dosyalarda hissedilir | S3 uyumuna bağlı pratik avantaj | Küçük dosyalarda request optimizasyonu gerekir | | Yedekleme restore deseni | Restore sık ise maliyet daha çok yükselir | CDN/edge yaklaşımı dolaylı etki edebilir | Restore sıklığına göre bütçe planlanır | | Saklama/versiyon | Versioning ve lifecycle güçlü | Benzer konseptleri destekleyen yapı | Versiyon/saklama planlaması yapılır |

Net maliyet hesap planı (3 adım)

Aylık veri artışı: Günlük 50 GB artış → ayda ~1500 GB.
Saklama süresi: 90 gün → ortalama depolama yaklaşık 45 gün veri seti kadar olur (yenileme modeline göre).
Restore/egress tahmini: Aylık restore 1 TB ise, toplam maliyetin büyük kısmı egress tarafında toplanır.

Önemli: Eğer restore neredeyse hiç yapılmayacaksa, toplam maliyette depolama öne çıkar. Restore beklentiniz varsa egress/indirmenin maliyet etkisi mutlaka hesaba katılmalıdır.

3) Performans ve pratik kullanım: API hızı tek başına yetmez

Yedekleme performansını “dosyayı yükledim mi” üzerinden ölçmek yanıltıcıdır. Şu sorular daha nettir: - Aynı dosya boyutlarında upload süreleri nasıl? - İstek sayısı (küçük parçalarda çok request) performansı etkiliyor mu? - Şifreleme/compress adımı toplam süreyi artırıyor mu? - Restore sırasında paralel indirme (parallel download) ne kadar işe yarıyor?

Hangi durumda hangi servis daha iyi görünür?

Amazon S3: Çok sayıda ekosistem aracı ve servis entegrasyonu ile kurumsal senaryolarda daha “standart” ilerler. Çok büyük ölçekli veri akışlarında da tercih edilir.
Cloudflare R2: Özellikle Cloudflare ekosistemiyle çalışanlar için operasyonel yükü azaltabilir. Egress maliyeti ve edge yaklaşımı bazı mimarilerde bütçeyi avantajlı yapar.
Backblaze B2: Bütçe odaklı yedekleme stratejilerinde güçlü bir alternatif olarak öne çıkar; fakat restore planı ve paralel indirme stratejisiyle performans optimizasyonu yapmak gerekir.

Upload/restore için net test yöntemi

Karar vermeden önce 2-3 saatlik bir ölçüm yapın: - Aynı sunucudan üç servis için de aynı dosya setini yükleyin (ör. 100 GB: 70% büyük dosya + 30% küçük dosya). - rclone ile paralellik ayarını sabitleyin. - Sonuçları not edin: - Ortalama upload süresi - Paralel indirmede restore süresi - Hata/limit (rate limit) davranışı - Toplam request sayısı ve hatalar

Bu ölçüm, teorik fiyatların ötesine geçer.

4) Güvenlik ve uygunluk: “Şifreleme var” yetmez, kontrol şart

Yedekleme servisi seçerken teknik doğrulama yapın. Aşağıdaki kontrol listesi uygulanabilir ve denetlenebilir olmalıdır.

Kimlik ve erişim (IAM) kontrolü

Servise erişim için minimum yetki (least privilege) kullanın.
Uygulama anahtarları için sadece gerekli bucket/prefix erişimi verin.
Anahtarları uygulama içine gömmeyin; ortam değişkeni (environment variable) veya secret yönetimi kullanın.

Şifreleme katmanları

Transit şifreleme: HTTPS/TLS zorunlu.
At-rest şifreleme: Servis tarafı şifreleme (server-side encryption) aktif olmalı.
Ek gereklilik varsa client-side encryption (CSE) uygulayın.

Saklama politikası: Sildiğinizde geri dönebilir misiniz?

“Silme” veya “ransomware” senaryosunda kritik sorular: - Versioning açık mı? - Silme/üzerine yazma sonrası geri dönme süresi var mı? - Lifecycle ile “çok erken silme” riski var mı?

Yedek doğrulama (integrity) şart

Her yedekleme stratejisinde “yükledim” demek yetmez. - Dosya düzeyinde checksum (ör. SHA-256) üretecek bir doğrulama adımı ekleyin. - Restore sonrası doğrulama yapın: checksum eşleşiyor mu? - Büyük dosyalarda parçalı upload/restore için bütünlük kontrolünü planlayın.

5) Hangi servis sizin senaryonuza daha net uyar? (karar matrisi)

Aşağıdaki liste “genel öneri” değildir; doğrudan yedekleme kararınız için eşik sağlar.

Senaryo A: Günlük yedek + düşük restore oranı

Öncelik: depolama + egress maliyeti düşük kalsın.
Net seçim eğilimi:
Backblaze B2 veya Cloudflare R2 maliyet odaklı projelerde daha mantıklı görünür.
Amazon S3 kurumsal entegrasyon avantajı nedeniyle seçilebilir.

Senaryo B: Sık restore (test ortamları, çekirdek veri geri dönüşü)

Öncelik: restore sırasında egress ve indirme süresi bütçenizi aşmasın.
Net seçim eğilimi:
Amazon S3 ekosistem ve olgunluk nedeniyle tercih edilse de egress maliyeti mutlaka simüle edilmelidir.
Cloudflare R2 restore maliyetini düşürme potansiyeli olan mimarilerde güçlü adaydır.

Senaryo C: Aynı yedekleme aracıyla hızlı geçiş/taşınabilirlik

Öncelik: S3 uyumluluğu ve mevcut script/SDK uyumu.
Net seçim eğilimi:
R2 ve B2, S3 uyumlu yaklaşım sayesinde geçişi kolaylaştırır.
Mevcut altyapınız S3 ekosistemine kilitli ise S3 doğrudan devam olur.

Senaryo D: Uzun süreli arşiv + versiyonlama kritik

Öncelik: versiyon/saklama politikalarının net uygulanması.
Net seçim eğilimi:
Hepsinde versiyonlama yaklaşımı planlanabilir; kararınız “lifecycle kuralı + maliyet simülasyonu” ile netleşir.

6) Uygulama mimarisi: “Doğru yedekleme” için servis kadar süreç de belirleyici

Servis seçtikten sonra yedekleme sürecini standardize edin. Aşağıdaki yapı çoğu senaryoda somut sonuç verir.

Net önerilen yedekleme akışı

Uygulama verisini arşivle: tar/zip veya dosya bazlı yaklaşım.
Şifrele: mümkünse client-side (şifre anahtarını kontrol edin).
Parçala (chunk): özellikle çok sayıda küçük dosya varsa request sayısını kontrol etmek için strateji uygulayın.
Yükle (upload) ve ardından checksum doğrula.
Restore testini ayda 1 kez yapın.

Paralellik ve request optimizasyonu

Çok küçük dosya yükliyorsanız request sayısı artar; bu hem performansı hem maliyeti etkiler.
Büyük dosyalarda paralel upload daha anlamlıdır.
rclone gibi araçlarda paralellik ayarını deneme ile belirleyin.

Basit test senaryosu (örnek)

30 GB veri seti oluşturun:
20 GB tekil büyük dosya
10 GB küçük dosya (ör. 10-50 MB)
Her servise aynı anda yükleyin.
Upload sonrası 1 dosyayı restore edin ve checksum doğrulayın.

Bu test, “hangisi daha hızlı?” sorusunu veriyle cevaplar.

Sonuç: Net karar için fiyat + egress + restore testi şart

S3, R2 ve B2 arasında seçim yaparken tek belirleyici fiyat etiketi değildir. Toplam maliyeti egress (geri indirme) ve request yoğunluğu belirler; güvenliği ise versiyonlama, şifreleme ve bütünlük doğrulama adımları belirler. Bugün en doğru aksiyon: 2-3 saatlik aynı veri setiyle upload/restore testini yapın, ardından aylık restore beklentinizi de ekleyerek egress odaklı bir maliyet simülasyonu çıkarın. Bu iki çıktıyla servis seçiminiz netleşir ve sürpriz maliyetlerin önüne geçersiniz.