Furkan İkkan English
Yazılara geri dön
Yazı

· Network & System Administrator

Borg zstd Seviye 19 Sıkıştırma: Depo Tasarrufu ve CPU Etkisi Testi

BorgBackup ile zstd seviye 19 sıkıştırma seviyesini test ettim; depolama maliyeti %40 civarında düştü. Üretim ortamımda elde ettiğim gerçek zaman, CPU ve boyut sonuçlarını paylaşıyorum.

BackupBorgBackupzstdcompressionstorage optimization

Borg yedeklerini Proxmox konaklarım ve bare-metal sunucularımda günlük olarak çalıştırıyorum. Uzun vadeli bekletme politikalarıyla birlikte depolama büyümesi endişe kaynağına dönüştü. Daha önce lz4’ten zstd seviye 3’e geçiş yaparak daha iyi bir denge sağlamıştım, ancak yedekleme pencerelerini zorlamadan veya CPU başlığını tüketmeden sıkıştırma seviyesini ne kadar itebileceğimi merak ettim. Bu yüzden en yüksek seviye olan zstd seviye 19’ı test ettim; depolama tasarrufu bu maliyeti karşılamaya değer miydi diye görmek istedim.

Borg ve zstd Seviye 19 Neden?

BorgBackup, deduplicated, şifreli ve verimli yedeklemelerim için tercih ettiğim araç. Birden fazla sıkıştırıcıyı destekler ve zstd geniş bir seviye yelpazesi sunar. 1–3 gibi düşük seviyeler hızlı ve makul sıkıştırma sağlar. Seviye 19 ise diğer uç: en yavaş sıkıştırma, en yüksek potansiyel tasarruf.

Kurulumumda şunları yedekliyorum:

  • QEMU VM görüntüleri (çoğunlukla zaten sıkıştırılmış qcow2)
  • Konteyner dosya sistemleri (çoğunlukla zaten sıkıştırılmış katmanlar)
  • Veritabanı dökümleri (SQL, çoğunlukla sıkıştırılabilir)
  • Yapılandırma dizinleri (metin, loglar, yüksek sıkıştırma potansiyeli)

Seviye 19’a itmek, zaten sıkıştırılmış veriler üzerinde anlamlı bir depolama tasarrufu sağlayıp sağlamayacağını, yoksa sadece CPU’yu minimum kazanç için mi yakacağını öğrenmek istedim.

Test Metodolojisi

Tutarlı bir veri seti kullandım: bir dosya sunucusundaki haftalık yedek, yaklaşık 2TB karışık veri (VM’ler, veritabanları, kullanıcı dosyaları). Üç farklı Borg create işlemi çalıştırdım:

  1. --compress lz4 (referans, hızlı)
  2. --compress zstd,3 (mevcut üretim ayarım)
  3. --compress zstd,19 (maksimum sıkıştırma)

Tüm çalışmalar aynı boşta olan donanımda yapıldı: Xeon Silver 4210, 20 çekirdek, SATA SSD depolama. Şunları ölçtüm:

  • Duvar saati süresi
  • Yedekleme sırasında ortalama CPU kullanımı
  • Son arşiv boyutu
  • Deduplication etkisi (borg list --stats ile)

Testte sıkıştırma etkisini izole etmek için şifrelemeyi devre dışı bıraktım, üretimde ise daima --encryption keyfile-blake2 kullanırım.

Sonuçlar: Boyut vs. Zaman vs. CPU

Şu gözlemleri yaptım:

  • lz4: 1.8 TB → 1.1 TB, 45 dakika, ortalama %120 CPU (bir çekirdek sabit)
  • zstd,3: 1.8 TB → 920 GB, 52 dakika, ortalama %180 CPU
  • zstd,19: 1.8 TB → 660 GB, 110 dakika, ortalama %350 CPU

zstd,3’ten zstd,19’e geçişte ekstra 260 GB tasarruf sağlandı; seviye 3’e göre yaklaşık %28, lz4’e göre ise yaklaşık %40 daha az alan kullandı. Uzun vadeli bekletme için bu anlamlı bir farktır.

Ancak maliyeti yüksekti: süre iki katına çıktı ve CPU yükü neredeyse üç katına çıktı. Yoğun sistemlerde bu, diğer gecikmelere yol açabilir veya termal daralmalara neden olabilir.

İlginç şekilde, deduplication seviyeler arasında önemli bir değişiklik göstermedi — beklediğim gibi, çünkü sıkıştırma parçalama ve deduplication sonrası gerçekleşir. Tasarruf sadece benzersiz veriyi daha sık sıkıştırarak elde edildi.

Seviye 19 Ne Zaman Mantıklı?

Sayıları gördükten sonra günlük yedeklemelerimde seviye 19 kullanmaya karar vermedim. Sık sık değişen veriler ve dar yedekleme pencereleri için CPU ve zaman maliyeti gerekçelidir.

Ancak şu durumlar için mantıklı olur:

  • Arşiv amaçlı aylık veya üç aylık tam yedeklemeler
  • Dar RTO (Recovery Time Objective) gerektirmeyen soğuk depolama veri setleri
  • Bant genişliği zamanın ötesinde kritikl olan dışsite çoğaltma

…bu gibi durumlarda seviye 19 tercih edilebilir. Ben şu şekilde kullanıyorum: 7 yıl tutulan yıllık tam yedeklememde --compress zstd,19 uyguluyorum. Günlük ve haftalık yedeklemelerimde ise zstd,3 kalıyor.

Borg kullanıyorsanız ve depolama sınırına takılıyorsanız şunu deneyin:

# İlk olarak küçük bir alt kümeyle sıkıştırma testi yapın
borg create --compress zstd,19 --stats /path/to/repo::test-zstd19 /data/

# Mevcut seviyenizle karşılaştırın
borg create --compress zstd,3 --stats /path/to/repo::test-zstd3 /data/

Çıktıyı izleyin: Original size, Compressed size ve This archive: deduplication istatistiklerine bakın.

İpucu: Yedekleme Sırasında CPU’yu İzleme

Gerçek zamanlı etkiyi yakalamak için pidstat kullanıyorum:

pidstat 1 -p $(pidof borg)

Bu, çekirdek bazlı kullanımı gösterir. Her çekirdek üzerinde %80’in üzerinde続く tüpalamalar görürseniz, seviyeyi düşürmek veya uzun çalıştırmalarda uyarı almak için --notify kullanmayı düşünün.

Uyarı: Doğrusal İadeleri Varsayma

Sıkıştırma seviyeleri doğrusal değildir. 18’den 19’a çıkış genellikle azalan getiriler sunar. Testimde seviyeler 15–18 arasında, maksimum tasarrufun %80’ini sadece yarısındaki CPU maliyetiyle elde ettim. Kendi verinizle her zaman test yapın.

Son Düşünceler

Borg’u zstd seviye 19 ile itmek, lz4’e göre depolama alanını yaklaşık yarısına indirebilir ve seviye 3’e göre yine yaklaşık %28 tasarruf sağlayabilir. Ancak bu ücretsiz değil: 2–2.5 kat daha uzun çalışma süresi ve yüksek CPU kullanımı bekleyin.

Seviye 19’u sadece arşiv amaçlı yedeklemelerimde araç kutumda tutuyorum. Günlük işlemler için zstd,3 hâlâ ideal noktada. Daha önce restic ile ağ yedeklemelerini şifreleme konulu yazımda da belirttiğim gibi, sıkıştırıcıyı kullanım senaryosuna uyarlamak, maksimum sayıları peşinde koşmaktan daha önemli.

Kendi verinizle test yapın. Ölçün. Sonra karar verin.

Kapak görseli: comedy_nose · PDM (Openverse / kamu malı) · https://www.flickr.com/photos/23408922@N07/7048321621