Arşiv Boyutunu Önceden Tahmin Etme

yazar

Bir arşiv oluşturmadan önce ne kadar yer kaplayacağını bilmek, özellikle disk alanının kısıtlı olduğu production ortamlarında hayat kurtarır. Kaç kere oldu ki büyük bir tar.gz oluşturdunuz, işlem yarıda kaldı, disk doldu ve sistemi mahvettiniz? Ya da bulut depolamaya göndermeden önce boyutu tahmin etmek istediniz ama elimde ne var diye düşündünüz? Bu yazıda arşiv boyutunu önceden tahmin etmenin pratik yollarını, araçlarını ve gerçek dünya senaryolarını ele alacağız.

Neden Boyut Tahmini Önemli?

Sysadmin işinin büyük bir kısmı “bir şey olmadan önce o şeyi öngörmek”ten ibarettir. Arşiv boyutu tahmini de tam olarak bu kategoriye girer. Şöyle düşünün: 200 GB’lık bir log dizinini sıkıştırıyorsunuz ve hedef diskinizde 80 GB boş alan var. İşlem saatler sürer, disk dolar, sistem panikler. Bu senaryoyu yaşamamak için birkaç dakika harcayıp boyutu önceden tahmin etmek son derece mantıklıdır.

Boyut tahmini şu durumlarda kritik önem taşır:

  • Yedekleme scriptleri yazarken: Hedef dizinin yeterli alana sahip olup olmadığını kontrol etmek
  • Bulut transferleri öncesinde: S3, Azure Blob veya GCS’e göndermeden önce maliyet tahmini
  • Tape arşivleme sistemlerinde: Teyp kapasitesini aşmamak için
  • CI/CD pipeline’larında: Artifact boyutlarını kontrol altında tutmak
  • Müşteri raporları için: “Bu yedek yaklaşık şu kadar yer kaplar” demek profesyonelce görünür

du Komutu ile Ham Boyutu Anlama

Her şeyden önce, sıkıştırmadan önceki ham veri boyutunu anlamak gerekir. Bunun için du (disk usage) komutu temel silahımızdır.

# Bir dizinin toplam boyutunu human-readable formatta göster
du -sh /var/log/nginx/

# Çıktı:
# 4.2G    /var/log/nginx/
# Sadece belirli dosya türlerini hesapla
du -sh /var/www/html/*.log

# Alt dizinleri de göster, maksimum derinlik belirle
du -h --max-depth=2 /var/www/

# Sonuçları boyuta göre sırala
du -h /var/log/* | sort -rh | head -20

-s: Sadece toplamı gösterir, alt dizinleri ayrı ayrı listelemez -h: Human-readable format (K, M, G cinsinden) –max-depth=N: N seviye derinliğe kadar göster -c: Genel toplam satırı ekle

Bu ham boyut, sıkıştırma sonrası ne olacağını doğrudan söylemez ama başlangıç noktası olarak çok değerlidir.

Sıkıştırma Oranlarını Anlamak

Farklı dosya türleri farklı oranlarda sıkışır. Bu temel bilgiyi aklınızda tutarsanız tahminleriniz çok daha isabetli olur.

Yüksek sıkıştırma oranı (60-80% küçülme): Log dosyaları, CSV, XML, JSON, kaynak kod dosyaları Orta sıkıştırma oranı (30-50% küçülme): Word belgeleri, Excel dosyaları, veritabanı dump’ları Düşük sıkıştırma oranı (0-15% küçülme): JPEG, PNG, MP4, MP3, ZIP içindeki ZIP

Örneğin bir nginx log dosyası genellikle %70-80 oranında sıkışırken, zaten sıkıştırılmış bir video dosyasını tekrar gzip’le sıkıştırmak neredeyse hiçbir kazanç sağlamaz.

gzip ile Tahmini Boyut Hesaplama

gzip’in güzel bir özelliği var: --list parametresi mevcut gzip dosyalarının sıkıştırma oranını gösterir. Ama biz daha önce tahmin yapmak istiyoruz.

# Küçük bir örnek alıp sıkıştırma oranını test et
# Önce örnek dosyayı oluştur
head -c 10M /var/log/nginx/access.log > /tmp/sample.log

# Sıkıştır ve boyutu karşılaştır
gzip -9 /tmp/sample.log
ls -lh /tmp/sample.log.gz

# Orijinal boyutu öğren (gzip --list ile)
gzip --list /tmp/sample.log.gz

Bu yaklaşımın mantığı şu: Büyük bir dosyanın küçük bir örneğini alıp sıkıştırıyorsunuz. Eğer 10 MB’lık örnek 2 MB’a indi ise sıkıştırma oranınız %80’dir. Bunu tüm dosya boyutuna uygulayarak tahmin yapabilirsiniz.

Pratik Örnek: Log Rotasyonu Öncesi Tahmin

#!/bin/bash
# log_size_estimator.sh
# Log dizininin sıkıştırma sonrası boyutunu tahmin eder

LOG_DIR="/var/log/nginx"
SAMPLE_SIZE="50M"
SAMPLE_FILE="/tmp/log_sample_$$"
COMPRESSED_SAMPLE="/tmp/log_sample_$$.gz"

echo "=== Log Arşiv Boyutu Tahmincisi ==="
echo ""

# Ham boyutu al
RAW_SIZE=$(du -sb "$LOG_DIR" | cut -f1)
RAW_SIZE_HUMAN=$(du -sh "$LOG_DIR" | cut -f1)
echo "Ham boyut: $RAW_SIZE_HUMAN"

# Örnek al ve sıkıştır
echo "Örnek alınıyor ($SAMPLE_SIZE)..."
find "$LOG_DIR" -type f -name "*.log" -exec cat {} ; 2>/dev/null | 
    head -c "$SAMPLE_SIZE" > "$SAMPLE_FILE"

SAMPLE_RAW=$(stat -c%s "$SAMPLE_FILE")
gzip -9 -c "$SAMPLE_FILE" > "$COMPRESSED_SAMPLE"
SAMPLE_COMPRESSED=$(stat -c%s "$COMPRESSED_SAMPLE")

# Sıkıştırma oranını hesapla
RATIO=$(echo "scale=4; $SAMPLE_COMPRESSED / $SAMPLE_RAW" | bc)
ESTIMATED=$(echo "scale=0; $RAW_SIZE * $RATIO" | bc)
ESTIMATED_MB=$(echo "scale=2; $ESTIMATED / 1048576" | bc)

echo "Tahmini arşiv boyutu: ${ESTIMATED_MB} MB"
echo "Sıkıştırma oranı: $(echo "scale=1; (1 - $RATIO) * 100" | bc)%"

# Temizlik
rm -f "$SAMPLE_FILE" "$COMPRESSED_SAMPLE"

tar ile Gerçek Dünya Senaryoları

tar komutunun kendi başına boyut tahmin özelliği yoktur ama birkaç farklı yöntemle bu işi halledebiliriz.

Yöntem 1: –totals Parametresi

# tar ile arşiv oluştururken toplam boyutu göster
tar --totals -czf /dev/null /var/www/html/ 2>&1 | grep "Total bytes"

# Ya da daha temiz bir çıktı için
tar -czf - /var/www/html/ 2>/dev/null | wc -c

Buradaki numara şu: Arşivi /dev/null‘a ya da stdout’a yönlendirip wc -c ile byte sayısını alıyoruz. Gerçek arşiv oluşturulmuyor, sadece veri işleniyor. Bu yöntem yavaş olabilir ama en isabetli sonucu verir.

Yöntem 2: Hızlı Kaba Tahmin

# Ham boyutu al
RAW=$(du -sb /var/www/html/ | cut -f1)

# Dosya türlerine göre tahmin et
# Web dosyaları için genellikle %40-60 sıkıştırma varsayımı
ESTIMATED=$(echo "$RAW * 0.4" | bc)
echo "Tahmini boyut: $(echo "scale=2; $ESTIMATED / 1073741824" | bc) GB"

Yöntem 3: pigz ile Paralel Test

Büyük sistemlerde pigz (parallel gzip) kullanıyorsanız, küçük bir test yapabilirsiniz:

# pigz ile sıkıştırma oranını test et
tar -cf - /path/to/directory/ 2>/dev/null | 
    pigz -9 | 
    pv -pterab > /dev/null

pv aracı (pipe viewer) gerçek zamanlı transfer hızı ve geçen veri miktarını gösterir. Eğer pv kurulu değilse apt install pv veya yum install pv ile kurabilirsiniz.

zip Boyut Tahmini

zip formatı, özellikle Windows ortamlarıyla paylaşım söz konusu olduğunda popülerdir. zip’in güzel bir özelliği var: -sf parametresiyle içeriği listeler.

# Zip oluşturmadan içeriği simüle et ve boyutu göster
zip -r -sf archive_name /path/to/directory/ 2>/dev/null | tail -1

# Daha detaylı tahmin için küçük bir örnek
zip -r /tmp/test_archive.zip /path/to/small/sample/
unzip -l /tmp/test_archive.zip | tail -1
#!/bin/bash
# zip_estimator.sh
# Klasör yapısındaki dosya türlerine göre zip boyutunu tahmin eder

TARGET_DIR="$1"

if [ -z "$TARGET_DIR" ]; then
    echo "Kullanim: $0 <dizin>"
    exit 1
fi

echo "Analiz ediliyor: $TARGET_DIR"
echo ""

# Dosya türü dağılımını göster
echo "=== Dosya Türü Dağılımı ==="
find "$TARGET_DIR" -type f | 
    sed 's/.*.//' | 
    sort | uniq -c | sort -rn | head -10

echo ""
echo "=== Toplam Boyut ==="
du -sh "$TARGET_DIR"

echo ""
echo "Not: Log/text dosyaları icin %60-80, resim/video icin %0-5 kazanim beklenir."

7zip ile Gelişmiş Tahmin

7zip en yüksek sıkıştırma oranlarından birini sunar ve test modu sayesinde tahmin için de kullanılabilir.

# 7zip ile arşiv oluşturmadan sıkıştırma testi
7z t /path/to/existing/archive.7z

# Sıkıştırma simülasyonu (benchmark)
7z b -mm=lzma2 -mmt=4

# Belirli bir dizini arşivlemeden boyut tahmini
# Önce küçük bir örnek arşivle
7z a -t7z -mx=9 /tmp/test_sample.7z /path/to/sample/
7z l /tmp/test_sample.7z

7zip özellikle database dump’ları ve kaynak kod arşivleri için inanılmaz sıkıştırma oranları sunar. MySQL dump’ı %85-90 oranında küçülebilir.

Otomatik Boyut Kontrolü ile Yedekleme Scripti

Gerçek dünyada en çok kullanacağınız senaryo şu: Yedekleme başlamadan önce hedef dizinde yeterli alan var mı kontrol et, yoksa uyar.

#!/bin/bash
# smart_backup.sh
# Boyut tahmini yapan akıllı yedekleme scripti

SOURCE_DIR="/var/www/html"
BACKUP_DIR="/backup"
BACKUP_FILE="$BACKUP_DIR/www_backup_$(date +%Y%m%d_%H%M%S).tar.gz"
MIN_FREE_SPACE_GB=5

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1"
}

# Ham boyutu hesapla
RAW_BYTES=$(du -sb "$SOURCE_DIR" | cut -f1)
RAW_GB=$(echo "scale=2; $RAW_BYTES / 1073741824" | bc)

log "Kaynak dizin boyutu: ${RAW_GB} GB"

# Sıkıştırma tahmini (web dosyaları icin %50 varsayimi)
ESTIMATED_BYTES=$(echo "scale=0; $RAW_BYTES * 0.50" | bc | cut -d. -f1)
ESTIMATED_GB=$(echo "scale=2; $ESTIMATED_BYTES / 1073741824" | bc)

log "Tahmini arşiv boyutu: ~${ESTIMATED_GB} GB"

# Hedef diskte boş alan kontrolü
FREE_BYTES=$(df -B1 "$BACKUP_DIR" | tail -1 | awk '{print $4}')
FREE_GB=$(echo "scale=2; $FREE_BYTES / 1073741824" | bc)

log "Hedef dizinde boş alan: ${FREE_GB} GB"

# Yeterli alan var mı?
REQUIRED_BYTES=$(echo "$ESTIMATED_BYTES + (1073741824 * $MIN_FREE_SPACE_GB)" | bc)

if [ "$FREE_BYTES" -lt "$REQUIRED_BYTES" ]; then
    log "HATA: Yetersiz disk alani!"
    log "Gerekli: ~${ESTIMATED_GB} GB + ${MIN_FREE_SPACE_GB} GB tampon"
    log "Mevcut: ${FREE_GB} GB"
    exit 1
fi

log "Disk alani yeterli, yedekleme basliyor..."
tar -czf "$BACKUP_FILE" "$SOURCE_DIR"

ACTUAL_SIZE=$(du -sh "$BACKUP_FILE" | cut -f1)
log "Yedekleme tamamlandi: $BACKUP_FILE ($ACTUAL_SIZE)"

Bu script production ortamında cron job olarak çalıştırılabilir. Disk dolu hatası almadan önce uyarı verir ve işlemi durdurur.

rsync ile Kuru Çalıştırma (Dry Run)

rsync’in --dry-run modu, transfer yapılacak veriyi önceden görmek için mükemmeldir. Bu özellikle uzak sunucuya aktarım öncesinde çok işe yarar.

# rsync ile transfer öncesi boyut tahmini
rsync -avzn --stats /source/directory/ user@remote:/destination/ 2>&1 | 
    grep -E "Total file size|Total transferred"

# Sadece istatistikleri göster
rsync --dry-run --stats -az /var/log/ /backup/logs/ 2>&1 | tail -20

-n veya –dry-run: Gerçekte hiçbir şey aktarmaz, sadece simüle eder –stats: Transfer istatistiklerini gösterir -az: Arşiv modu ve sıkıştırma (network üzerinden)

Tahmin vs Gerçek: Farkı Minimize Etme

Tahminlerinizin gerçeğe ne kadar yakın olduğunu test etmek isteyebilirsiniz. Bunun için küçük ama temsili bir örnek almak kritiktir.

# Gerçekçi örnek alma stratejisi
# Dizinin farklı alt klasörlerinden örnek topla

#!/bin/bash
SAMPLE_DIR="/tmp/estimation_sample_$$"
mkdir -p "$SAMPLE_DIR"

# Her alt dizinden birkaç dosya al
find /var/www/html -type f | shuf | head -100 | 
    while read file; do
        cp "$file" "$SAMPLE_DIR/" 2>/dev/null
    done

# Örneği sıkıştır
SAMPLE_RAW=$(du -sb "$SAMPLE_DIR" | cut -f1)
tar -czf "/tmp/sample_archive_$$.tar.gz" "$SAMPLE_DIR" 2>/dev/null
SAMPLE_COMPRESSED=$(stat -c%s "/tmp/sample_archive_$$.tar.gz")

# Oran hesapla
echo "Örnek ham: $(echo "scale=2; $SAMPLE_RAW/1024" | bc) KB"
echo "Örnek sıkıştırılmış: $(echo "scale=2; $SAMPLE_COMPRESSED/1024" | bc) KB"
echo "Sıkıştırma oranı: $(echo "scale=1; (1 - $SAMPLE_COMPRESSED/$SAMPLE_RAW) * 100" | bc)%"

# Temizlik
rm -rf "$SAMPLE_DIR" "/tmp/sample_archive_$$.tar.gz"

Gerçek Dünya Senaryosu: MySQL Yedekleri için Boyut Tahmini

Veritabanı yedeklemelerinde boyut tahmini özellikle önemlidir. MySQL dump boyutunu tahmin etmenin pratik yolu:

# MySQL veritabanı boyutunu sorgula
mysql -u root -p -e "
SELECT 
    table_schema AS 'Database',
    ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS 'Size (MB)'
FROM information_schema.tables 
GROUP BY table_schema
ORDER BY SUM(data_length + index_length) DESC;" 2>/dev/null

# Dump alıp sıkıştırma oranını test et (sadece birkaç tablo ile)
mysqldump -u root -p --single-transaction mydb customers orders | 
    gzip -9 | wc -c

Genel kural olarak MySQL dump’ları gzip ile %70-85 arası sıkışır. Yani 10 GB’lık bir veritabanından 1.5-3 GB’lık bir dump çıkması normaldir.

Monitoring ve Alerting Entegrasyonu

Bu tahmin mantığını bir monitoring sistemiyle entegre edebilirsiniz. Prometheus veya Zabbix kullanan ortamlar için:

#!/bin/bash
# backup_precheck.sh
# Nagios/Icinga uyumlu çıktı üretir

SOURCE="/var/www"
BACKUP_MOUNT="/backup"
WARNING_THRESHOLD=80   # Disk doluluk yüzdesi
CRITICAL_THRESHOLD=90

RAW_BYTES=$(du -sb "$SOURCE" 2>/dev/null | cut -f1)
ESTIMATED=$(echo "$RAW_BYTES * 0.5" | bc | cut -d. -f1)

FREE=$(df -B1 "$BACKUP_MOUNT" | tail -1 | awk '{print $4}')
TOTAL=$(df -B1 "$BACKUP_MOUNT" | tail -1 | awk '{print $2}')
USED_AFTER=$(echo "$TOTAL - $FREE + $ESTIMATED" | bc)
USAGE_PERCENT=$(echo "scale=0; $USED_AFTER * 100 / $TOTAL" | bc)

if [ "$USAGE_PERCENT" -ge "$CRITICAL_THRESHOLD" ]; then
    echo "CRITICAL: Yedek sonrasi disk dolulugu %${USAGE_PERCENT} olacak"
    exit 2
elif [ "$USAGE_PERCENT" -ge "$WARNING_THRESHOLD" ]; then
    echo "WARNING: Yedek sonrasi disk dolulugu %${USAGE_PERCENT} olacak"
    exit 1
else
    echo "OK: Yedek sonrasi disk dolulugu %${USAGE_PERCENT} olacak"
    exit 0
fi

Pratik İpuçları ve Tuzaklar

Yıllar içinde öğrendiğim birkaç önemli nokta:

Hard link’lere dikkat: du bazen hard link’leri birden fazla sayar, bu da tahminizi şişirebilir. du --count-links ile kontrol edin.

Sparse file’lar: Sanallaştırma ortamlarında sparse dosyalar gerçek boyutlarından çok farklı görünebilir. du -sh ile ls -lh arasındaki fark büyükse sparse file var demektir.

Çok küçük dosya sorunu: Binlerce küçük dosya içeren dizinlerde (örneğin /var/spool/mail) tar’ın overhead’i önemli olabilir. Tahmine %5-10 buffer ekleyin.

Ağ bant genişliği tahmini: Sıkıştırılmış boyutu bilmek, transfer süresini de hesaplamanızı sağlar. 100 Mbps’lik bir link üzerinden 5 GB’lık arşiv transferi yaklaşık 7 dakika sürer.

Buffer ekleyin: Hiçbir tahmin mükemmel değildir. Tahmininize her zaman en az %15-20 buffer ekleyin.

İlk sıkıştırmayı kaydedin: Bir dizini ilk kez sıkıştırdığınızda elde ettiğiniz oranı not alın. Benzer içerik için gelecekteki tahminlerinizde bu veriyi kullanın.

Sonuç

Arşiv boyutunu önceden tahmin etmek, profesyonel sistem yönetiminin ayrılmaz bir parçasıdır. du ile ham boyutu anlamak, küçük örnekler üzerinde sıkıştırma testleri yapmak ve bu bilgiyi yedekleme scriptlerine entegre etmek sizi “disk doldu, yedek yarıda kaldı” krizlerinden kurtarır.

En sağlam yöntem genellikle hibrit bir yaklaşımdır: Dosya türü analizi yapın, küçük bir örnek üzerinde gerçek sıkıştırma oranını test edin ve bu oranı tüm dizine uygulayın. Buna makul bir buffer ekleyin ve hedef diskte yeterli alan olup olmadığını kontrol edin.

Scriptleri kendinize göre uyarlayın, cron job’larınıza ekleyin ve sonuçları bir yere kaydedin. Zamanla elinizde geçmiş veri birikir ve tahminleriniz giderek daha isabetli hale gelir. Bu da gecenin üçünde pager uyarısıyla uyanma ihtimalini dramatik biçimde azaltır, ki her sysadmin bunu ister.

Yorum yapın