Bulut Yedekleme Maliyet Optimizasyonu: Faturayı Düşüren 5 Yöntem

Bulut yedekleme maliyet optimizasyonu bence günlük kullandığım beş pratik tekniğe indirgeniyor: veri sıkıştırma, lifecycle politikaları, incremental-forever yedekleme, storage tiering ve retention budama. Ortamınızdaki üretim verisi gerçek anlamda büyümüyorsa ama aylık bulut yedekleme faturanız sürekli tırmanıyorsa, muhtemelen gereksiz veri blokları, eski retention penceresi veya aylar önce cold storage'a taşınması gereken hot-tier storage için para ödüyorsunuzdur. İşte bu faturaları nasıl kontrol altına aldığım.

Önce Ne Depolandığını Denetle, Sonra Değişiklik Yap

Kör körüne optimizasyona başlamam. İlk yaptığım şey yedekleme platformundan (Veeam, Restic, Borg, ne kullanıyorsam) bir storage envanteri çekmek ve neyin alan tükettiğine bakmak. Çoğu zaman suçlu aktif yedekler değildir. Orphaned restore point'ler, kaldırılmış host'lardan kalan eski VM yedekleri ya da birinin açıp unuttuğu test job'larıdır.

Restic repository'inde repo boyutunu ve snapshot sayısını görmek için çalıştırdığım hızlı bir kontrol:

restic stats --mode raw-size
restic snapshots | wc -l

Snapshot sayısı yüzlerse ve haftalık olarak artıyorsa, retention politikanız ya fazla cömert ya da uygulanmıyor. 30 gün gerektiren bir sistem için 18 aylık günlük yedek tutan repository'ler gördüm. Bu tamamen israf.

Kaynakta Sıkıştırma ve Deduplication'ı Etkinleştir

Bu en az eforla en yüksek etkiyi veren değişiklik. Modern yedekleme araçlarının çoğu built-in sıkıştırma ve deduplication destekler ama her zaman varsayılan olarak etkin değildir.

Dosya tabanlı yedekler için BorgBackup kullanıyorum çünkü deduplication'ı chunk tabanlı ve benzer veri setlerinde gerçekten etkili:

borg create --compression=zstd,11 \
  user@backupserver:/repo::myserver-{now:%Y-%m-%d} \
  /path/to/data

zstd,11 sıkıştırma seviyesi log ve database dump gibi text ağırlıklı workload'larda bana yaklaşık %40-60 oranında küçülme sağlıyor. VM image gibi binary ağırlıklı verilerde kazanç daha küçük ama yine de anlamlı.

Veeam ortamlarında "Storage optimization" ayarının doğru yapıldığından ve repository üzerinde deduplication'ın etkin olduğundan emin oluyorum. Kritik nokta: sıkıştırmayı veri kaynaktan çıkmadan önce uygulayın. Bulut storage'a yüklemeden sonra sıkıştırmak, bant genişliği için zaten para ödediğiniz anlamına gelir.

Eski Yedekleri Cold Storage'a Taşımak İçin Lifecycle Politikaları Kullan

En büyük gereksiz harcamayı burada görüyorum. Yedekler tüm retention penceresi boyunca hot SSD sınıfı bulut storage'da (AWS S3 Standard, Azure Hot Blob) kalıyor. Ama restore olasılığı ilk haftadan sonra keskin şekilde düşer. 2. gün mevcutken kimse 45. günün yedekğini restore etmez.

Yedekleri storage tier'ları arasında otomatik taşımak için lifecycle rule'ları yapılandırıyorum:

0-7. Gün: Hot tier (hızlı restore erişimi)
7-30. Gün: Warm tier (seyrek erişim)
30. Gün ve sonrası: Cold/archive tier (en ucuz storage)

AWS S3'de bu şöyle görünüyor:

{
  "Rules": [{
    "ID": "BackupTiering",
    "Status": "Enabled",
    "Transitions": [
      {"Days": 7, "StorageClass": "STANDARD_IA"},
      {"Days": 30, "StorageClass": "GLACIER"}
    ]
  }]
}

Incremental-Forever Yedekleme Modellerine Geç

Her hafta full yedek almak storage israf eden eski bir alışkanlık. Yedekleme aracınız incremental-forever destekliyorsa — yani bir başlangıç full yedekten sonra sadece incremental'lar — etkinleştirin.

Veeam'de bu, reverse incremental veya forward incremental with synthetic fulls ile varsayılan. Ben forward incremental with periodic synthetic fulls tercih ediyorum çünkü storage verimliliği ile restore hızını dengeliyor.

Restic'te incremental otomatik. Araç sadece değişen blokları depolar, bu yüzden 500GB'lık bir veri setinin günlük yedekleri her çalıştırmada sadece birkaç yüz MB ekleyebilir:

restic backup /data --tag daily

Kaçınılması gereken tuzak: yedekleme aracınız yedekler arasında gerçek block-level deduplication yapmıyorsa, gereksiz veri depolarsınız. Her yedekleme çalıştırmasında gerçek repository büyümesini kontrol edin. Çoğunlukla idle bir sunucunun günlük yedeklemesi 50GB ekliyorsa, deduplication ayarlarında bir sorun vardır.

Retention'ı Agresif Şekilde Budayın ve Restore Testi Yapın

Retention set-and-forget bir ayar değil. Retention politikalarını çeyreklik olarak gözden geçiriyorum. İş gereksinimleri değişir, compliance penceresi kayar ve storage maliyetleri gelişir. 18 ay önce mantıklı olan bir politika bugün para yakıyor olabilir.

Compliance dışı workload'lar için benim standart retention baseline'ım:

Günlük: 14 gün
Haftalık: 4 hafta
Aylık: 3 ay
Yıllık: Yılda 1 (gerekirse)

Restic'te pruning'i scheduled job ile otomatikleştiriyorum:

restic forget --keep-daily 14 --keep-weekly 4 \
  --keep-monthly 3 --keep-yearly 1 --prune

İpucu: pruning'den sonra repository bütünlüğünü doğrulamak için her zaman restic check çalıştırın. Bozuk bir repo tüm yedekleme stratejisini çökertir.

Daha önceki [3-2-1 yedekleme kuralı](https://furkanikkan.com/urun/3-2-1-yedekleme-kurali-sadece-yedek-almak-yetmez-49) yazımda da belirttiğim gibi, yedeklerin olması ancak onlardan gerçekten restore yapabiliyorsanız işe yarar. Süreçte restore yeteneğini bozuyorsanız maliyet optimizasyonunun bir anlamı yok. Retention veya storage tier'ları her değiştirdiğimde, yedeklemenin hala geçerli olduğunu doğrulamak için test restore çalıştırıyorum.

Storage Büyümesini Sürekli İzle

Optimizasyon tek seferlik bir proje değil. Storage tüketim trendlerinde alert'ler kuruyorum. Bir yedekleme repository'si üretim verisinde karşılık gelen bir artış olmadan aydan aya %15'ten fazla büyürse, hemen araştırıyorum.

Monitoring için repository boyutunu günlük olarak loglayan ve Grafana dashboard'uma besleyen basit bir script kullanıyorum. Ani spike'lar genellikle başarısız bir deduplication job'ını, birinin bana haber vermeden backup almaya başladığı yeni büyük bir veri setini veya çalışmayı bırakan bir retention politikasını gösterir.

Özü: bulut yedekleme maliyetleri, storage'ı sınırlı bir kaynak olarak ele alırsanız kontrol edilebilir. Yüklemeden önce sıkıştırın, agresif şekilde tier yapın, düzgün deduplicate edin ve ihtiyacınız olmayanları budayın. Aylık faturanız bir faturalandırma döngüsü içinde bu eforu yansıtacak.

Kapak görseli: Unknown · CC0 (Openverse / kamu malı) · https://svgsilh.com/3f51b5/image/303333.html