Arşivleme İşlemlerinde Bant Genişliğini Sınırlandırma: trickle ve rsync ile Kontrollü Yedekleme Transferi

Yazar:komut.io ekibi Arşiv ve Sıkıştırma Komutları
0 Yorum

Gece yarısı bir yedekleme scripti çalıştırıp sabah ofise geldiğinde network’ün felç olduğunu gördüysen, bu yazı tam sana göre. Yıllarca “zaten gece çalışıyor, kimse kullanmıyor” diye düşünüp hiç throttle uygulamadan yedekleme yapan biri olarak şunu söyleyebilirim: Bir gün mutlaka pişman olursun. Özellikle ortam büyüdükçe, yedekleme penceresi daralıp trafik artınca bu ihmal seni çok ciddi sorunlara sokabilir.

Bu yazıda trickle ve rsync‘in birlikte nasıl kullanılabileceğini, bant genişliği sınırlandırmanın neden sadece “iyi bir pratik” değil, kurumsal ortamlarda neredeyse zorunluluk olduğunu anlatacağım. Komutları ezberletmek yerine arkasındaki mantığı aktarmaya çalışacağım.

Neden Bant Genişliği Sınırlandırması Gerekli?

Şöyle bir senaryo düşün: 50 GB’lık bir dizini uzak bir sunucuya yedekliyorsun. Gigabit bir bağlantın var ve rsync tüm bant genişliğini kullanmaya başlıyor. Bu esnada:

  • Üretim ortamındaki uygulamalar yavaşlıyor
  • VoIP görüşmeleri kopuyor
  • Veritabanı replikasyonu gecikiyor
  • Monitoring sistemlerin alarm üretiyor

Gece 03:00’te başlayan bir yedekleme, düşündüğün kadar “sessiz” olmayabilir. Özellikle şu durumlarda dikkatli olmak gerekir:

  • Paylaşımlı WAN bağlantısı: Şubeler arası bağlantılarda yedekleme trafiği gerçek iş trafiğini eziyor.
  • Bulut ortamları: AWS, Azure gibi platformlarda egress maliyetleri var. Hız ne kadar yüksekse, burst maliyetin o kadar artıyor.
  • Hybrid backup senaryoları: Hem yerel hem uzak yedekleme aynı anda çalışıyorsa kaynak çakışması kaçınılmaz.
  • SLA’lı ortamlar: Yedekleme penceresini aşarsan bu doğrudan SLA ihlali sayılabiliyor.

trickle Nedir ve Nasıl Çalışır?

trickle, kullanıcı alanında (userspace) çalışan bir bant genişliği şekillendirme aracıdır. Kernel seviyesinde bir trafik şekillendirme yapmaz; bunun yerine uygulamaların send() ve recv() sistem çağrılarını yakalar, araya girerek akışı düzenler. Bu yaklaşımın hem avantajları hem dezavantajları var.

Avantajları:

  • Root yetkisi gerektirmez
  • tc/iptables gibi kernel araçlarına gerek yok
  • Herhangi bir uygulamanın önüne koyulabilir
  • Kurulumu son derece basit

Dezavantajları:

  • UDP tabanlı uygulamalarda çalışmaz (sadece TCP)
  • Statik kütüphane ile derlenmiş uygulamalarda etkisiz
  • Çok thread’li uygulamalarda tahmin edilemez davranışlar gösterebilir

Kurulum

Debian/Ubuntu sistemlerde:

sudo apt-get install trickle

RHEL/CentOS/Rocky Linux sistemlerde:

sudo yum install trickle
# veya daha yeni sistemlerde:
sudo dnf install trickle

Temel Kullanım

trickle’ın temel sözdizimi şu şekilde:

trickle -u [upload_kbps] -d [download_kbps] [komut]

Parametreler:

  • -u: Upload (gönderme) hız sınırı, KB/s cinsinden
  • -d: Download (indirme) hız sınırı, KB/s cinsinden
  • -s: Standalone mod, daemon olmadan çalışır
  • -t: Trickle’ın ne sıklıkla akışı kontrol edeceği (saniye, varsayılan 0.08)
  • -l: Gecikme uzunluğu (mikrosaniye)
  • -w: Window size (KB cinsinden)
  • -v: Verbose çıktı

Basit bir örnek: Bir dosyayı scp ile 500 KB/s hızıyla kopyalamak:

trickle -s -u 500 -d 1000 scp /backup/database_dump.sql.gz kullanici@uzak-sunucu:/yedekler/

Burada -s flag’ini özellikle belirtmek istiyorum. trickle normalde bir daemon üzerinden çalışmayı tercih eder. -s ile standalone modda çalıştırırsın ve daemon bağımlılığından kurtulursun. Script’lerde her zaman -s kullanmanı öneririm, aksi halde trickled daemon’ının çalışıp çalışmadığına bakman gerekir.

rsync ile Bant Genişliği Kontrolü

rsync, aslında kendi içinde bant genişliği sınırlandırma özelliğine sahip. --bwlimit parametresi bu işi yapar:

rsync --bwlimit=2048 -avz /kaynak/dizin/ kullanici@uzak-sunucu:/hedef/dizin/

Bu örnekte transfer hızı 2048 KB/s (yani yaklaşık 2 MB/s) ile sınırlandırılıyor.

Parametreler açısından biraz daha detaylı bakalım:

  • –bwlimit=KBPS: Transfer hızını KB/s cinsinden sınırlar. rsync 3.1.0 ve sonrasında K, M, G son ekleri de kullanılabilir.
  • -a: Archive modu, izinleri, zaman damgalarını ve sembolik linkleri korur
  • -v: Verbose
  • -z: Sıkıştırma, özellikle WAN bağlantılarında işe yarar
  • –progress: Transfer ilerlemesini gösterir
  • –stats: Tamamlandıktan sonra istatistik çıktısı verir
  • -e: Kullanılacak shell veya SSH parametrelerini belirtir

Daha kapsamlı bir rsync komutu:

rsync 
  --bwlimit=1500 
  -avz 
  --progress 
  --stats 
  --checksum 
  --exclude='*.tmp' 
  --exclude='*.log' 
  --log-file=/var/log/rsync_backup.log 
  /var/www/html/ 
  [email protected]:/backup/web/

--checksum parametresine dikkat et. Normalde rsync dosya boyutu ve zaman damgasını karşılaştırır. --checksum ile MD5 checksum kontrolü yaparsın. Daha güvenilir ama daha yavaş. Kritik veriler için tercih et.

trickle + rsync: En İyi Kombinasyon

rsync’in --bwlimit özelliği varken neden trickle kullanalım? Çünkü bazen rsync dışında başka araçlar da kullanıyorsun: scp, tar | ssh, sftp, curl gibi. trickle, bu araçların tamamı için tek bir çözüm sunar. Ayrıca bazı senaryolarda her ikisini birden kullanmak, daha tutarlı bir hız sınırı sağlar.

trickle -s -u 1000 -d 500 rsync 
  --bwlimit=1000 
  -avz 
  --progress 
  /data/kritik_veriler/ 
  kullanici@yedek-sunucu:/arsiv/

Bu kombinasyonda hem trickle hem rsync hız sınırı uygular. trickle sistem çağrısı seviyesinde, rsync ise uygulama seviyesinde sınırlandırma yapar. Pratikte bu bazen daha kararlı bir hız eğrisi oluşturur.

Gerçek Dünya Senaryoları

Senaryo 1: Mesai Saatlerinde Yedekleme

Yedekleme sadece gece çalışmıyor, özellikle büyük veri setlerinde. Gündüz saatlerinde de çalışması gerekebiliyor. Bu durumda agresif bir hız sınırı şart:

#!/bin/bash

# Mesai saatlerini kontrol et
saat=$(date +%H)

if [ "$saat" -ge 9 ] && [ "$saat" -lt 18 ]; then
    # Mesai saatlerinde düşük hız
    BWLIMIT=512
    TRICKLE_LIMIT=512
else
    # Gece saatlerinde yüksek hız
    BWLIMIT=4096
    TRICKLE_LIMIT=4096
fi

echo "$(date): Yedekleme başlıyor, hız sınırı: ${BWLIMIT} KB/s"

trickle -s -u "$TRICKLE_LIMIT" rsync 
    --bwlimit="$BWLIMIT" 
    -avz 
    --progress 
    --log-file=/var/log/yedekleme_$(date +%Y%m%d).log 
    /var/lib/mysql/backups/ 
    [email protected]:/mysql_backups/

echo "$(date): Yedekleme tamamlandı."

Senaryo 2: Çoklu Kaynak, Önceliklendirilmiş Transfer

Birden fazla dizini yedeklerken bazıları kritik, bazıları değil. Önceliğe göre farklı hız sınırları uygulayabilirsin:

#!/bin/bash

HEDEF="kullanici@yedek-sunucu:/backup"
LOG="/var/log/backup_$(date +%Y%m%d_%H%M%S).log"

echo "=== KRİTİK VERİLER ===" >> "$LOG"
# Kritik veriler: daha yüksek hız, daha yüksek öncelik
trickle -s -u 2048 rsync 
    --bwlimit=2048 
    -avz 
    --stats 
    --log-file="$LOG" 
    /var/lib/postgresql/ 
    "${HEDEF}/postgresql/"

echo "=== UYGULAMA DOSYALARI ===" >> "$LOG"
# Uygulama dosyaları: orta öncelik
trickle -s -u 1024 rsync 
    --bwlimit=1024 
    -avz 
    --stats 
    --log-file="$LOG" 
    /var/www/ 
    "${HEDEF}/www/"

echo "=== ARŞİV DOSYALARI ===" >> "$LOG"
# Arşiv dosyaları: düşük öncelik, yavaş transfer
trickle -s -u 256 rsync 
    --bwlimit=256 
    -avz 
    --stats 
    --log-file="$LOG" 
    /data/arsiv/ 
    "${HEDEF}/arsiv/"

Senaryo 3: SSH Tüneli Üzerinden Şifreli Transfer

Hassas veriler için SSH tüneli kullanıyorsan ve trickle’ı SSH’a uygulamak istiyorsan:

trickle -s -u 800 -d 200 
    rsync 
    --bwlimit=800 
    -avz 
    --progress 
    -e "ssh -i /home/backup/.ssh/id_rsa -o StrictHostKeyChecking=no -p 2222" 
    /etc/configs/ 
    [email protected]:/etc_backups/

ionice ile Disk I/O Optimizasyonu

Bant genişliğini sınırlandırırken disk I/O’yu da düşünmek gerekiyor. ionice ile rsync’in disk önceliğini düşürebilirsin. Bu özellikle yoğun I/O ortamlarında kritik:

ionice -c 3 trickle -s -u 1024 rsync 
    --bwlimit=1024 
    -avz 
    --progress 
    /data/buyuk_dosyalar/ 
    kullanici@hedef:/backup/

ionice -c 3 ile “idle” sınıfına alırsın. Disk meşgulse rsync bekler, disk boşaldığında devreye girer. Üretim sistemleri için idealdir.

Üçlü optimizasyon için nice de ekleyebilirsin:

nice -n 19 ionice -c 3 trickle -s -u 512 rsync 
    --bwlimit=512 
    -avz 
    --compress-level=9 
    /var/log/uygulama/ 
    kullanici@log-sunucu:/arsiv/loglar/

Burada nice -n 19 ile CPU önceliğini de en düşüğe çekiyorsun.

screen veya tmux ile Uzun Süren Transferleri Yönetmek

Büyük yedeklemeler bazen saatler sürer. Terminal kapanırsa transfer de kesilir. Bu sorunu çözmek için:

# Yeni bir screen oturumu başlat
screen -S yedekleme

# İçinde komutu çalıştır
trickle -s -u 2048 rsync 
    --bwlimit=2048 
    -avz 
    --progress 
    --partial 
    --append-verify 
    /data/buyuk_arsiv/ 
    kullanici@yedek:/arsiv/

# Ctrl+A, D ile screen'i arka plana al
# Durumu kontrol etmek için:
# screen -r yedekleme

--partial ve --append-verify kombinasyonu, kesilen transferlerin kaldığı yerden devam etmesini sağlar. Yüzlerce GB’lık transferlerde bu iki parametre hayat kurtarır.

Aktif Transferi İzleme

Trickle ile sınırlandırdığın bir transferin gerçekten istediğin hızda çalışıp çalışmadığını nasıl doğrularsın?

# iftop ile anlık trafik izleme
sudo iftop -i eth0 -f "host yedek-sunucu"

# nethogs ile process bazlı izleme
sudo nethogs eth0

# ss ile bağlantı durumunu görme
ss -tnp | grep rsync

# Alternatif: pv ile boru hattı hızını izleme
tar czf - /data/buyuk_dizin/ | trickle -s -u 1024 pv | 
    ssh kullanici@uzak-sunucu "cat > /backup/arsiv.tar.gz"

pv (pipe viewer) gerçekten çok işlevli bir araç. Boru hattındaki veri akış hızını, toplam aktarılan veriyi ve tahmini süreyi anlık gösteriyor.

Cron ile Otomatik Zamanlamak

Tüm bu komutları cron ile otomatize etmek için basit bir yapı:

# crontab -e ile ekle

# Her gece 02:00'de yüksek hızlı yedekleme
0 2 * * * /opt/scripts/gece_yedekleme.sh >> /var/log/cron_backup.log 2>&1

# Her saat başı düşük hızlı incremental yedekleme
0 * * * * /opt/scripts/saatlik_incremental.sh >> /var/log/cron_incremental.log 2>&1

saatlik_incremental.sh içeriği:

#!/bin/bash
set -euo pipefail

KAYNAK="/var/www/uploads/"
HEDEF="kullanici@yedek-sunucu:/incremental/$(date +%Y/%m/%d)/"
LOG_DOSYA="/var/log/incremental_$(date +%Y%m%d_%H).log"

# Hedef dizini oluştur
ssh kullanici@yedek-sunucu "mkdir -p /incremental/$(date +%Y/%m/%d)" 2>/dev/null || true

# Sadece son 1 saatte değişen dosyaları yedekle
find "$KAYNAK" -newer /tmp/son_yedek_zamani -type f > /tmp/degisen_dosyalar.txt

if [ -s /tmp/degisen_dosyalar.txt ]; then
    echo "$(date): $(wc -l < /tmp/degisen_dosyalar.txt) dosya değişmiş, transfer başlıyor." >> "$LOG_DOSYA"

    trickle -s -u 256 rsync 
        --bwlimit=256 
        -avz 
        --files-from=/tmp/degisen_dosyalar.txt 
        / 
        "$HEDEF" >> "$LOG_DOSYA" 2>&1

    touch /tmp/son_yedek_zamani
    echo "$(date): Transfer tamamlandı." >> "$LOG_DOSYA"
else
    echo "$(date): Değişen dosya yok, atlanıyor." >> "$LOG_DOSYA"
fi

Yaygın Hatalar ve Çözümleri

Pratikte karşılaşılan sorunlara bakalım:

trickle etkisiz gibi görünüyor: rsync SSH üzerinden çalışırken trickle’ın scp yerine rsync daemon’ını veya SSH’ı yakaladığından emin ol. Eğer rsync --daemon modunda çalışıyorsa trickle işe yaramaz; o zaman rsync’in kendi --bwlimit parametresini kullan.

Hız belirtilenden çok daha düşük: trickle’ın -t parametresi (kontrol aralığı) çok küçükse throttling aşırı agresif olabilir. Varsayılan 0.08 saniye genellikle iyidir ama ağ gecikmesi yüksekse -t 0.5 gibi bir değer dene.

rsync bağlantı kesiliyor: WAN üzerinde uzun süren transferlerde SSH timeout sorunu yaşanabilir. SSH config’e veya -e parametresine şunları ekle:

rsync -avz 
    --bwlimit=512 
    -e "ssh -o ServerAliveInterval=60 -o ServerAliveCountMax=3" 
    /kaynak/ kullanici@uzak:/hedef/

Checksum hatası: --append-verify kullanıyorsan ve transfer kesilip devam ediyorsa bazen dosya bütünlüğü sorunları çıkabilir. Bu durumda --checksum ile tam doğrulama yap.

Sonuç

Bant genişliği kontrolsüz yedekleme, özellikle paylaşımlı altyapılarda ciddi operasyonel sorunlara yol açıyor. Hem trickle hem de rsync’in --bwlimit parametresi bu sorunu çözmek için güçlü ve esnek araçlar sunuyor.

Pratik tavsiye: trickle’ı sadece rsync için değil, scp, sftp, curl gibi diğer araçlar için de alışkanlık haline getir. ionice ve nice ile kombinlemek ise üretim sunucularında neredeyse standart olmalı. Transfer hızlarını gerçek ortam koşullarında test et, iftop veya nethogs ile doğrula ve cron script’lerine mesai saati kontrolü ekle.

En önemlisi, yedekleme sadece “çalışıyor mu” sorusunun ötesinde düşünülmeli. “Hangi maliyetle çalışıyor?” sorusu da en az ilki kadar kritik. Kontrollü transfer, hem ağını hem de iş süreçlerini korumanın en akıllıca yolu.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir