Borg zstd Seviye 19 Sıkıştırma ile Yedekleme Depolama Maliyetlerini %40 Azaltın

Yıllardır Proxmox ana bilgisayarları ve bare-metal posta sunucularında BorgBackup çalıştırıyorum. Son zamanlarda, bekletme politikaları artıkça depolama maliyetleri yavaş yavaş artmaya başladı. Depolama tasarrufu sağlamak ve yedekleme pencerelerini dar tutmak için sıkıştırma seviyelerine baktım. zstd’i seviye 1’den 22’ye kadar test ettikten sonra, gece yedeklemelerim için seviye 19’u seçtim. Bu, zstd,6’ye göre disk kullanımında yaklaşık %40 azalma sağladı ve sadece %15–20 daha fazla CPU zamanı ekledi. SSD katmanları veya dış mekan nesne depolama için ödeme yapıyorsanız, bu dengede kazanç sağlanıyor.

zstd Seviyesi 19 Borg İçin Mantıklı Neden

Borg’un --compression zstd,9 önerisi, hızlı ve sağlam sıkıştırma sağladığı için varsayılan öneridir. Ancak yedek işlerimi profilediğimde, sıkıştırma aşamasında CPU'nun boşta kalmasını gördüm. Bu, yedek penceresini aşmadan sıkıştırma oranını artırabileceğimiz anlamına geliyordu. Örnek 200GB veri seti (VM diskleri, PostgreSQL yedekleri ve dosya paylaşımları karışımı) üzerinde zstd seviyeleri 10 ile 22 arasında karşılaştırma yaptım. Seviye 19, ideal noktayı buldu: sıkıştırma oranı ~2.8x (zstd,6) yerine ~4.6x çıktı ve geri yükleme hızı seviye 6 ile %10 içinde kaldı, çünkü zstd çıkarma hızı seviyeye neredeyse bağımsızdır.

Yeni depolar için kullandığım tam init komutu şu şekildedir:

borg init --encryption=repokey --compression zstd,19 /mnt/backup/borg-repo

Mevcut depolar için sıkıştırma geri dönük olarak değiştirilemez, ancak yeni segmentler yapılandırma dosyasında belirtilen seviyeyi kullanır. Bunu borg config /mnt/backup/borg-repo compression komutunu birkaç çalıştırma sonrası kontrol ederek doğruladım.

Yedekleme Komutunu Ayarlama

Gece yedekleme komut dosyam, uzun süreli işler için cron yerine daha güvenilir olan systemd zamanlayıcı üzerinden çalışır. Temel kısımlar şöyle görünüyor:

borg create \
    --verbose \
    --filter AME \
    --list \
    --stats \
    --show-rc \
    --compression zstd,19 \
    --exclude-caches \
    --exclude '*/__pycache__/*' \
    --exclude '*.iso' \
    {hostname}-{now:%Y-%m-%d_%H:%M} ::\
    /etc\
    /var/lib/mysql\
    /srv/www

--stats bayrağı, her çalıştırmada sıkıştırma oranını verir. Bu sayıları journal'a kaydediyorum ve zaman içinde oranı grafikliyorum. Seviye 19'e geçtikten sonra, aynı 30 günlük bekletme süresi için ortalama depolama kullanımı 1.2TB'den 720GB'ye düştü. Bu, %40'luk bir azalttır—Hetzner sunucumuza ait depolama katmanını bir seviye düşürmek için yeterli.

Doğrulanan Geri Yükleme Süreci

Alan tasarrufu, geri yüklemeye güvenilemiyorsa hiçbir şey ifade etmez. Aylık olarak, üretim ana bilgisayarıyla aynı CPU/RAM'ye sahip ayrı bir Proxmox VM kullanarak geri yüklemeleri test ediyorum. Süreç basittir:

1. Arşivleri listele: borg list /mnt/backup/borg-repo
2. Rastgele son bir arşivi /tmp/test-restore klasörüne çıkar:

borg extract /mnt/backup/borg-repo::{hostname}-2024-05-15_02:30 \
    /etc/nginx /var/lib/mysql

1. Canlı veri (loglar ve geçici dosyalar hariç) ile diff -r kullanarak dosya sayılarını ve boyutlarını karşılaştır.
2. Veritabanları için, dümü geri yükler ve bütünlüğü kontrol etmek için mysqlcheck çalıştırırım.

Bu süreci, diff özetini bana e-posta ile gönderen bir systemd hizmeti olarak betikledim. Başarılı olursa, yedek o ay için yeşil olarak işaretlenir. Daha önceki ZFS gönder/al gönderimimde de belirttiğim gibi, doğrulama opsiyonel değildir—yedekleriniz gerçekten çalışıyor mu diye öğrenmenin tek yolu budur.

Dikkat Edilmesi Gerekenler ve Uyarılar

Daha fazlasının daha iyi olduğunu düşündüğünüz için seviye 22’ye atlamayın. 19’un üzerindeki oran kazançları düzleşirken CPU süresi kesin şekilde artıyor. Benim Xeon E3-1230 v6 işlemcimde, seviye 22, seviye 19’a kıyasla sadece %5 ek tasarruf için neredeyse iki kat daha uzun sürdü. Ayrıca, düşük güçlü ARM cihazlarında (örneğin, yedekleme düğümü olarak kullanılan Raspberry Pi 4) zstd seviyelerini 20’nin üzerinde kullanmaktan kaçının—sıkıştırma aşaması bottleneck haline gelebilir ve dışarıya yedeklemeyi geciktirebilir.

İpucu: Sıkıştırma aşaması sırasında pidstat -p $(pgrep borg) 1 komutuyla yedekleme işinizin CPU kullanımını izleyin. Sürekli olarak %50’in altında CPU kullanıyorsanız, seviyeyi güvenli bir şekilde artırabileceğiniz anlamına gelir.

Daha Düşük Seviyelerle Kalmak Ne Zaman Uygun?

Yedekleme penceresi zaten dar ve sıkıştırma sırasında CPU maksimum seviyedeyse, zstd,6 veya zstd,9 seviyelerinde kalın. Depolama tasarrufu, yedeklemeler çakışmaya başladığında veya kaçmaya başladığında önemsiz olur. Bu durumlar için, --chunker-params ayarını ayarlamak veya gereksiz verileri atlamak için --exclude kullanarak deduplication ayarlarını ilk önce incelemenizi öneririm—bu genellikle sıkıştırmanın son gotunu çıkarmaya çalışmaktan daha iyi sonuç verir.

Sunucularımın çoğu—özellikle gece boş döngülerine sahip olanlar için—zstd,19 artık varsayılan seçenek. Bu, bir kez ayarlayıp unutulan bir değişikliktir ve her ay geri dönüş sağlar.

Kapak görseli: Lenharth Systems · CC0 (Openverse / kamu malı) · https://stocksnap.io/photo/computer-hard-2J3PLNMO9M