Bulut yedekleme fiyatları: maliyet nasıl hesaplanır?

Kısaca

Bulut yedekleme fiyatları yalnız saklanan veri miktarına bakılarak karşılaştırılmamalıdır. Gerçek maliyeti kaynak veri hacmi, günlük değişim oranı, saklama süresi, ikinci kopya, değişmez saklama, geri yükleme trafiği ve yönetilen operasyon kapsamı birlikte belirler. Dynamis Teknoloji, Raff platformunu sıfırdan geliştiren ekip olarak yedekleme maliyetini depolama birim fiyatından değil, geri döndürülebilir bir sistemin toplam sahiplik maliyetinden hesaplar.

Bulut yedekleme maliyeti yedi ana değişkenden oluşur

Bulut yedekleme maliyeti çoğu şirkette yedi ana değişkenin birleşimidir: korunan veri, saklanan veri, saklama süresi, kopya sayısı, geri yükleme yolu, veri transferi ve operasyon hizmeti.

Bu ayrımı yapmak önemlidir çünkü iki teklif aynı “1 TB yedekleme” ifadesini kullanırken farklı şeyleri fiyatlandırabilir.

Örneğin bir sağlayıcı yalnız depolanan veriyi ücretlendirebilir. Başka bir sağlayıcı depolamaya ek olarak korunan sunucu, yönetim, veri transferi veya geri yükleme işlemleri için ayrı kalemler kullanabilir.

Azure Backup fiyatlandırması korunan örnek ile yedekleme depolamasını ayrı bileşenler olarak ele alır. Google Cloud Backup and DR ise depolama, yönetim, bölgeler arası veri transferi ve bazı upload/download kalemlerini ayrı faturalandırma bileşenleri olarak tanımlar.

Bu nedenle teklif karşılaştırırken tek bir “GB başına fiyat” yeterli değildir.

Kaynak veri ile faturalanan yedek veri aynı olmayabilir

Kaynak veri boyutu, yedekleme kapasitesinin başlangıç noktasıdır; toplam saklanan veri değildir.

Bir sunucuda 1 TB veri bulunması, her zaman 1 TB yedekleme alanı kullanılacağı anlamına gelmez.

Toplam tüketimi şu unsurlar değiştirir:

• Full ve incremental yedekleme modeli
• Günlük veri değişim oranı
• Saklama süresi
• Sürüm sayısı
• Compression
• Deduplication
• Silinen dosyaların retention süresi

Basitleştirilmiş bir örnek düşünün.

1 TB kaynak verinin her gün yaklaşık %5'i değişiyor ve günlük recovery point'ler 30 gün tutuluyorsa, yalnız kaynak veri boyutuna bakarak maliyet hesabı yapmak yanıltıcı olur. Değişen verinin ne kadarının ayrı saklandığı, sıkıştırma ve deduplication davranışı gerçek kapasiteyi belirler.

Bu nedenle teklif isterken yalnız “kaç TB veriniz var?” sorusuna değil, “günlük değişim oranınız nedir?” sorusuna da cevap vermelisiniz.

Saklama süresi maliyeti doğrudan etkiler

Daha uzun saklama süresi genellikle daha fazla recovery point ve daha fazla depolama tüketimi anlamına gelir.

Ancak 30 gün retention ile 365 gün retention arasındaki maliyet farkı her sistemde aynı değildir.

Farkı belirleyen unsurlar:

• Günlük değişim oranı
• Haftalık veya aylık full yedek
• Incremental zincir
• Archive tier kullanımı
• Compression ve deduplication
• Eski sürümlerin ne zaman silindiği

Uzun dönem saklama gerekiyorsa bütün recovery point'leri aynı storage sınıfında tutmak zorunda değilsiniz.

Sık kullanılan son 30 günlük veriyi hızlı erişilen katmanda, daha eski aylık veya yıllık kopyaları daha düşük maliyetli arşiv katmanında tutmak bazı platformlarda mümkün olabilir.

Ancak arşiv katmanının geri yükleme süresi ve retrieval maliyeti ayrıca kontrol edilmelidir.

Kopya sayısı toplam maliyeti değiştirir

Tek bir yedek kopyası en düşük depolama maliyetini sağlayabilir, ancak tek failure domain bırakabilir.

3-2-1 yedekleme kuralı farklı failure domain'lerde birden fazla kopya tutmayı öneren temel yaklaşımı açıklar.

İkinci kopya şu şekilde tutulabilir:

• Farklı storage hesabında
• Farklı region'da
• Farklı cloud sağlayıcısında
• Şirket içi ortamda
• Offline veya değişmez depolamada

İkinci kopya depolama ve veri transferi maliyetini artırabilir.

Bunun karşılığında aynı credential, region veya provider arızasının bütün yedekleri etkileme riskini azaltabilirsiniz.

Maliyet hesabında “kaç kopya tutuyoruz?” sorusu bu nedenle zorunludur.

Değişmez yedekleme ek maliyet yaratabilir

Değişmez veya silinmeye karşı korunan yedekleme, ransomware ve yetkili kullanıcı hatalarına karşı ek kontrol sağlar.

Bu koruma sağlayıcıya göre:

• Object Lock
• immutable vault
• WORM policy
• retention lock

gibi yöntemlerle uygulanabilir.

Değişmezlik özelliğinin kendisi her platformda ayrı ücretli olmayabilir. Ancak silinemeyen verinin retention süresi boyunca tutulması depolama tüketimini artırabilir.

Örneğin yanlış oluşturulan büyük bir yedek kopyası 30 gün boyunca silinemiyorsa, o kapasite retention sona erene kadar maliyette kalabilir.

Bu nedenle immutable backup kararında yalnız özellik fiyatına değil, silme esnekliğine ve minimum retention davranışına da bakın.

Geri yükleme maliyeti teklifin parçası olmalıdır

Yedeklemenin değeri veri geri getirilebildiğinde ortaya çıkar.

Bu nedenle aylık maliyet hesabına en az bir gerçekçi geri yükleme senaryosu ekleyin.

Kontrol edilmesi gereken kalemler:

• Retrieval ücreti
• Veri okuma işlemleri
• API işlem ücretleri
• Network egress
• Geçici restore storage
• Yeni VM veya disk maliyeti
• Operasyon zamanı

Sağlayıcılar arasında bu model değişir.

Azure Backup bazı yedekleme türlerinde restore ve restore ile ilişkili outbound bandwidth için ücret almadığını belirtirken, farklı Azure hizmetlerinde restore başına GB ücretleri bulunabilir. Google Cloud Backup and DR fiyatlandırmasında ise kaynak türü ve mimariye göre depolama, yönetim ve veri transferi ayrı bileşenler olarak yer alır.

Bu yüzden “restore ücretsiz mi?” sorusunun cevabını ürün ve workload bazında doğrulayın.

RPO maliyeti etkiler

Daha düşük RPO, daha sık recovery point veya replikasyon gerektirebilir.

RPO, kabul edilebilir veri kaybı penceresidir.

Örneğin:

• 24 saat RPO
• 4 saat RPO
• 15 dakika RPO

aynı altyapı ihtiyacını oluşturmaz.

Daha sık yedekleme:

• daha fazla işlem
• daha yüksek veri değişim yakalama
• daha fazla metadata
• daha fazla transfer

gerektirebilir.

Ancak her workload için 15 dakika RPO gerekli değildir.

Muhasebe dosyaları, kritik üretim veritabanı ve arşiv dosyaları aynı RPO ile korunmamalıdır.

RPO'yu düşürmeden önce veri kaybının iş etkisini hesaplayın.

RTO maliyeti altyapı modelini değiştirir

Daha düşük RTO yalnız yedekleme sıklığıyla çözülmez.

RTO, sistemin kabul edilebilir geri dönüş süresidir.

Sekiz saat içinde geri dönmesi yeterli bir sistem ile 15 dakikada çalışması gereken sistem farklı kurtarma mimarisi gerektirir.

Düşük RTO için şu kaynaklar gerekebilir:

• Warm standby
• Hazır compute kapasitesi
• Daha hızlı storage
• Otomatik provisioning
• Replikasyon
• Önceden hazırlanmış network ve DNS

Bu nedenle “yedekleme fiyatı” ile “felaket kurtarma maliyeti” aynı şey değildir.

Disaster Recovery nedir? rehberi RPO, RTO ve recovery strategy ilişkisini ayrı olarak ele alır.

Geri dönüş testi operasyon maliyetine dahildir

Test edilmemiş yedekleme daha ucuz görünebilir, ancak kurtarma kabiliyeti kanıtlanmış değildir.

Geri dönüş testi şu işleri içerir:

• Recovery point seçimi
• Restore işlemi
• Yeni ortam hazırlığı
• Uygulama doğrulaması
• Veri bütünlüğü kontrolü
• RPO/RTO ölçümü
• Test ortamının temizlenmesi
• Bulguların kapatılması

Bu işler insan zamanı ve geçici altyapı tüketebilir.

Yedek geri yükleme testi aylık test modelini ve gerçek geri dönüş ölçümünü ayrıca açıklar.

Bir teklif “backup managed” diyorsa restore testinin kapsama dahil olup olmadığını mutlaka sorun.

Yönetilen hizmet ile yalnız depolama aynı fiyat değildir

Yedekleme yazılımı veya storage satın almak ile yedekleme operasyonunu yönetilen hizmet olarak almak farklı kapsamdır.

Yalnız altyapı modelinde siz şu işleri yönetirsiniz:

• Policy oluşturma
• Job takibi
• Başarısız yedekleme müdahalesi
• Retention
• Restore
• Test
• Kapasite takibi
• Raporlama

Yönetilen hizmette bu sorumlulukların bir bölümü hizmet sağlayıcıya devredilebilir.

Bu nedenle daha yüksek aylık maliyet her zaman daha pahalı storage anlamına gelmez. Fark operasyon kapsamından kaynaklanabilir.

Dynamis'in kurumsal altyapı hizmeti kapsamında yedekleme, monitoring ve geri dönüş sorumluluğu altyapının geri kalanıyla birlikte değerlendirilebilir.

Karar çerçevesi

Bulut yedekleme teklifini aşağıdaki durumlara göre karşılaştırın.

Bu tablo bir fiyat listesi değildir. Aynı veri hacmi farklı iş hedeflerinde farklı maliyet yaratabilir.

Teklif karşılaştırma tablosu oluşturun

Farklı sağlayıcıları aynı kapsamla karşılaştırmadan karar vermeyin.

Teklif tablonuzda şu alanlar bulunmalıdır:

Bu tablo “GB fiyatı” karşılaştırmasını toplam sahiplik maliyeti karşılaştırmasına dönüştürür.

Dynamis'te maliyet hesabını geri dönüş hedefinden başlatıyoruz

Dynamis, Raff platformunu sıfırdan geliştiren ekip olarak yedekleme tasarımında ilk soruyu “kaç TB depolayacağız?” şeklinde sormaz.

Önce şu dört bilgi netleştirilir:

1. Hangi veri kritik?
2. Kabul edilebilir veri kaybı nedir?
3. Sistem ne kadar sürede geri dönmeli?
4. Hangi failure domain'lerden korunmak gerekiyor?

Bu kararlar verildikten sonra:

• saklama süresi
• kopya sayısı
• storage katmanı
• değişmezlik
• test sıklığı

belirlenir.

Bu sıra gereksiz retention veya gereğinden pahalı recovery altyapısı kurma riskini azaltır.

Aylık maliyeti hesaplamak için basit model

İlk bütçe hesabını şu çerçeveyle kurabilirsiniz:

Toplam aylık maliyet = depolama + koruma/yönetim + veri transferi + geri yükleme/test + operasyon

Her kalemi ayrı hesaplayın.

Depolama

Tahmini saklanan GB × storage birim maliyeti.

Koruma veya yönetim

Sağlayıcının protected instance, workload veya yönetim lisansı varsa ekleyin.

Veri transferi

Cross-region veya cross-cloud kopya trafiğini ekleyin.

Geri yükleme ve test

Planlanan restore testleri için gerekli geçici compute, disk ve işlem maliyetini ekleyin.

Operasyon

İç ekip zamanı veya yönetilen hizmet bedelini ekleyin.

Bu hesap sağlayıcı fiyatlarını değiştirmez, fakat aynı kapsamı karşılaştırmanızı sağlar.

Sık yapılan hatalar

Yalnız GB fiyatına bakmak: Kopya, retention, restore ve operasyon maliyetini aynı tabloya ekleyin.

Kaynak veri boyutunu saklanan veri sanmak: Günlük değişim oranını ve retention politikasını ölçün.

Restore maliyetini hesaba katmamak: Gerçek bir geri dönüş senaryosunun maliyetini teklif aşamasında sorun.

RPO ve RTO'yu gereksiz düşük belirlemek: İş etkisini ölçmeden pahalı recovery mimarisi kurmayın.

Yedek var diye testi atlamak: En azından kritik workload'larda düzenli geri dönüş testi planlayın.

Sırada ne var

• 3-2-1 yedekleme kuralı: kopya ve failure domain yapısını planlayın.
• Yedek geri yükleme testi: yedeğin gerçekten geri döndüğünü ölçün.
• Disaster Recovery nedir?: RPO, RTO ve kurtarma stratejisini belirleyin.
• Kurumsal altyapı hizmeti: yedekleme ve geri dönüş operasyonunuzun kapsamını değerlendirin.

Kaynaklar

• Azure Backup fiyatlandırması
• Google Cloud Backup and DR fiyatlandırması