Büyük Dosya Transferini Hızlandırma: rsync Ayarları

Büyük dosyaları ağ üzerinden taşımak, özellikle terabayt seviyesine ulaştığında gerçek bir sabır testine dönüşebilir. Varsayılan rsync ayarlarıyla 500 GB’lık bir veritabanı yedeği almaya çalıştığınızda, aktarımın sabaha kadar sürdüğünü görürsünüz. Oysa birkaç parametre değişikliğiyle aynı işlemi çok daha kısa sürede tamamlamak mümkün. Bu yazıda, rsync’i gerçekten hızlı çalıştıran ayarları, neden işe yaradıklarını ve hangi senaryoda hangisini kullanmanız gerektiğini ele alacağız.

rsync’in Temel Performans Sorunları

Önce sorunun kaynağını anlamak gerekiyor. rsync varsayılan olarak güvenli çalışmak üzere tasarlanmış, hız ikinci planda tutulmuş. Bunun yanı sıra birkaç temel darboğaz var:

• Checksum hesaplama maliyeti: Her dosya için MD5/SHA hesabı CPU’yu meşgul eder
• SSH şifreleme yükü: Büyük transferlerde şifreleme algoritması fark yaratır
• Tek bağlantı limiti: Varsayılan olarak tek bir TCP akışı kullanılır
• Delta algoritması: Küçük değişiklikler için çok verimli ama büyük yeni dosyalarda overhead yaratır
• Metadata kontrolleri: Her dosyanın izinleri, zaman damgaları, sahiplik bilgisi ayrı ayrı kontrol edilir

Bunları nasıl ele geçireceğimizi tek tek göreceğiz.

SSH Şifreleme Algoritmasını Optimize Etmek

rsync büyük çoğunlukla SSH tüneli üzerinden çalışır. Varsayılan olarak OpenSSH, chacha20-poly1305 veya aes128-gcm gibi algoritmalar kullanır. Bunlar güvenli ama her bayt için CPU harcıyorlar. İç ağda (LAN) ya da güvendiğiniz bir VPN tüneli içindeyseniz daha hafif algoritmalar kullanabilirsiniz.

# AES-128-CTR ile transfer - donanım AES desteği olan sistemlerde çok hızlı
rsync -avz -e "ssh -c aes128-ctr" /data/yedek/ kullanici@hedef:/backup/

# Birden fazla algoritma öncelik sırasıyla
rsync -avz -e "ssh -c [email protected],aes128-ctr,aes256-ctr" 
  /data/buyuk_dosyalar/ kullanici@hedef:/depo/

# Şifrelemeyi tamamen kapatmak (sadece yerel ağda, güvenilir ortamda!)
rsync -avz -e "ssh -c none" /veri/ [email protected]:/yedek/

Hangi algoritmaların desteklendiğini görmek için:

ssh -Q cipher

Modern sunucularda AES-NI donanım desteği neredeyse standart. [email protected] çoğu zaman en iyi dengeyi sağlıyor. Bunu /proc/cpuinfo üzerinden kontrol edebilirsiniz:

grep -o 'aes' /proc/cpuinfo | head -1 && echo "AES-NI destekleniyor" || echo "AES-NI yok"

Sıkıştırma Ayarları: Ne Zaman Yarar, Ne Zaman Zarar Verir

-z parametresi sıkıştırmayı etkinleştirir. Ama burada önemli bir nokta var: Zaten sıkıştırılmış dosyaları (.gz, .zip, .jpg, .mp4, .sql.gz) tekrar sıkıştırmaya çalışmak sadece CPU yakar, boyutu azaltmaz.

# Metin tabanlı dosyalar için sıkıştırma mantıklı
rsync -avz --compress-level=1 /var/log/ kullanici@hedef:/log_arsiv/

# Zaten sıkıştırılmış dosyaları sıkıştırma (rsync 3.1+)
rsync -av --skip-compress=gz/zip/jpg/mp4/mkv/iso 
  /data/medya/ kullanici@hedef:/depo/

# Hız odaklı, düşük sıkıştırma
rsync -av --compress-level=1 -e "ssh -c aes128-ctr" 
  /veri/loglar/ kullanici@log-sunucu:/arsiv/

–compress-level=1: En düşük sıkıştırma, en yüksek hız. Ağ bant genişliğiniz 1 Gbps’yi geçiyorsa sıkıştırma genellikle dezavantaj haline gelir çünkü CPU sıkıştırmayla boğuşurken ağ boşta bekler.

–skip-compress: Belirttiğiniz uzantıları sıkıştırmadan geçirir. Karma içerikli dizinlerde çok işe yarar.

Checksum Stratejisi: Hız ile Güvenilirlik Dengesi

rsync varsayılan olarak dosya boyutu ve değiştirilme zamanını karşılaştırır. --checksum parametresi ise her dosyanın içeriğini hash’leyerek karşılaştırır. Bu güvenilir ama yavaş.

# Sadece boyut ve zaman karşılaştırması (varsayılan, en hızlı)
rsync -av /kaynak/ hedef/

# Tam checksum karşılaştırması (güvenilir ama yavaş)
rsync -avc /kaynak/ hedef/

# Boyut değişmişse kopyala, değişmemişse atla (orta yol)
rsync -av --size-only /data/ kullanici@hedef:/yedek/

# Checksum yerine sadece boyut + zaman, delta aktarımı kapat
rsync -av --whole-file /data/buyuk_dosya.img kullanici@hedef:/yedek/

–whole-file özellikle dikkat çekici. rsync normalde değişen blokları tespit edip sadece onları gönderir (delta transfer). Ama bu hesaplama kendi başına bir maliyet. Eğer dosyaların büyük çoğunluğu tamamen yeni veya tamamen değişmişse --whole-file bazen daha hızlı çalışır. Gigabit veya daha hızlı ağlarda bu parametre çoğu zaman delta algoritmasını geçer.

Paralel Transfer ile Hızı Katlamak

rsync tek başına paralel transfer yapmaz, ama bunu araçlarla aşabiliriz. En pratik yöntemler şunlar:

# GNU parallel ile birden fazla dizini eş zamanlı aktar
find /data -maxdepth 1 -mindepth 1 -type d | 
  parallel -j 4 rsync -av {} kullanici@hedef:/yedek/

# xargs ile paralel çalıştırma
ls /data/ | xargs -P 4 -I{} rsync -av /data/{} kullanici@hedef:/yedek/{}/

# Belirli dosya uzantılarını paralel gönder
find /veri -name "*.tar" | 
  parallel --progress -j 3 
  rsync -av --bwlimit=50000 {} kullanici@hedef:/arsiv/

Paralel transfer yaparken dikkat edilmesi gereken nokta: kaç paralel iş açacağınız. Kural olarak, ağ bant genişliğini hedef disk I/O’sunu bunaltmadan dolduracak kadar paralel iş mantıklı. Genellikle 3-6 arası iş iyi sonuç verir.

Bant Genişliği Kontrolü ve Önceliklendirme

Gündüz saatlerinde diğer servisleri boğmadan yedek almak istiyorsanız --bwlimit parametresi hayat kurtarır:

# Bant genişliğini KB/s cinsinden sınırla (100 MB/s = 102400 KB/s)
rsync -av --bwlimit=51200 /data/ kullanici@hedef:/yedek/

# Gece yarısı tam hızda, gündüz sınırlı çalışan script
#!/bin/bash
SAAT=$(date +%H)
if [ "$SAAT" -ge 22 ] || [ "$SAAT" -lt 06 ]; then
  LIMIT=""
else
  LIMIT="--bwlimit=20480"
fi

rsync -av $LIMIT 
  --log-file=/var/log/rsync_yedek.log 
  /production/data/ yedek-sunucu:/backup/production/

# nice ve ionice ile sistem önceliğini düşür
nice -n 19 ionice -c 3 rsync -av 
  /data/arsiv/ kullanici@hedef:/arsiv/

ionice -c 3 idle I/O önceliği anlamına gelir. Sistem boştayken I/O yapar, başka bir süreç disk kullanmak istediğinde geri çekilir.

SSH Bağlantı Optimizasyonu

SSH’ın kendi yapılandırması da önemli rol oynar. ~/.ssh/config dosyasına şunları eklemek uzun süreli transferlerde fark yaratır:

# ~/.ssh/config
Host yedek-sunucu
    HostName 192.168.1.100
    User yedekci
    Compression no
    ServerAliveInterval 60
    ServerAliveCountMax 10
    ControlMaster auto
    ControlPath ~/.ssh/cm-%r@%h:%p
    ControlPersist 10m
    IPQoS throughput

ControlMaster ve ControlPersist ayarları, birden fazla rsync çağrısı olduğunda SSH el sıkışmasını tekrar tekrar yapmaktan kaçınır. Özellikle küçük-orta boyutlu çok sayıda dosyayı aktarırken bu ciddi hız kazancı sağlar.

IPQoS throughput: SSH’a yüksek bant genişliği gerektiren bir aktarım yaptığını söyler ve TCP bağlantı parametrelerini buna göre ayarlar.

TCP Tampon Boyutlarını Ayarlamak

Ağ üzerinden büyük dosya transferlerinde TCP tampon boyutları kritik önem taşır. Özellikle yüksek gecikmeli (WAN) bağlantılarda varsayılan değerler yetersiz kalır.

# Geçici olarak ayarla
sysctl -w net.core.rmem_max=134217728
sysctl -w net.core.wmem_max=134217728
sysctl -w net.ipv4.tcp_rmem="4096 87380 134217728"
sysctl -w net.ipv4.tcp_wmem="4096 65536 134217728"

# Kalıcı ayar için /etc/sysctl.conf veya /etc/sysctl.d/99-network-tuning.conf
cat >> /etc/sysctl.d/99-rsync-tuning.conf << 'EOF'
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728
net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fq
EOF

sysctl -p /etc/sysctl.d/99-rsync-tuning.conf

BBR (Bottleneck Bandwidth and RTT): Google’ın geliştirdiği TCP tıkışma kontrol algoritması. Özellikle WAN transferlerinde geleneksel CUBIC algoritmasına kıyasla çok daha iyi performans gösterir. Linux 4.9+ çekirdeklerinde mevcut.

Gerçek Dünya Senaryosu 1: 2 TB Veritabanı Yedeği

Şirketin üretim PostgreSQL sunucusundan gece yarısı yedek almak istiyorsunuz. Hedef sunucu aynı veri merkezinde, 10 Gbps bağlantı var.

#!/bin/bash
# /opt/scripts/pg_rsync_yedek.sh

KAYNAK="/var/lib/postgresql/data/"
HEDEF="yedek-sunucu:/backup/postgresql/"
LOG="/var/log/pg_yedek_$(date +%Y%m%d).log"
TARIH=$(date +%Y-%m-%d)

echo "[$TARIH] Yedek başlıyor..." | tee -a $LOG

rsync -av 
  --whole-file 
  --no-compress 
  -e "ssh -c [email protected] -o Compression=no" 
  --checksum-choice=none 
  --inplace 
  --no-whole-file=false 
  --stats 
  --log-file=$LOG 
  --exclude='pg_wal/0*' 
  --exclude='postmaster.pid' 
  $KAYNAK $HEDEF

DURUM=$?
if [ $DURUM -eq 0 ]; then
  echo "[$TARIH] Yedek başarıyla tamamlandı" | tee -a $LOG
else
  echo "[$TARIH] HATA: Yedek başarısız, çıkış kodu: $DURUM" | tee -a $LOG
  # Alarm gönder
  mail -s "PostgreSQL Yedek Hatası" [email protected] < $LOG
fi

Bu senaryoda --whole-file ve --no-compress kombinasyonu, 10 Gbps LAN’da delta algoritması ve sıkıştırmanın CPU yükünü ortadan kaldırır. --inplace ise hedefte geçici dosya oluşturmak yerine doğrudan hedef dosyayı günceller, disk I/O’sunu yarı yarıya düşürür.

Gerçek Dünya Senaryosu 2: Uzak Ofisten WAN Üzerinden Yedek

500 Mbps WAN bağlantısı üzerinden uzak ofisin dosya sunucusunu merkeze yedekliyorsunuz. Gecikme 20-30ms.

#!/bin/bash
# WAN optimizasyonlu rsync

rsync -avz 
  --compress-level=3 
  -e "ssh -c [email protected] 
      -o TCPKeepAlive=yes 
      -o ServerAliveInterval=30 
      -o ConnectTimeout=60" 
  --partial 
  --partial-dir=.rsync-partial 
  --timeout=300 
  --bwlimit=40960 
  --stats 
  --human-readable 
  kullanici@uzak-ofis:/dosyalar/ 
  /backup/uzak-ofis/

–partial ve –partial-dir: Yarıda kesilen transferleri kaldığı yerden devam ettirir. WAN bağlantısında kopukluk olursa baştan başlamak zorunda kalmazsınız. .rsync-partial dizini geçici blokları tutar.

–timeout=300: 300 saniye boyunca veri gelmezse bağlantıyı keser. Ölmüş bağlantıların zombi olarak kalmasını önler.

–itemize-changes ile Neyin Aktarıldığını Anlamak

Performans sorunlarını teşhis etmek için neyin aktarıldığını görmek önemlidir:

# Hangi dosyaların aktarıldığını ve neden aktarıldığını göster
rsync -av --itemize-changes --dry-run /kaynak/ /hedef/

# Sadece değişen dosyaları listele
rsync -a --itemize-changes /kaynak/ /hedef/ | grep -E '^[^.]'

# Çıktı formatı: >f+++++++++ yeni dosya, >f.st...... boyut ve zaman değişmiş
# f=dosya, d=dizin, L=sembolik link
# c=checksum, s=boyut, t=zaman, p=izin, o=sahip, g=grup

Bu çıktıyı analiz etmek, neden beklenenden fazla veri aktarıldığını anlamanızı sağlar.

–filter ile Gereksiz Dosyaları Elemek

Aktarım hızını artırmanın en etkili yollarından biri gereksiz dosyaları hiç göndermemektir:

# Geliştirme ortamı yedeği - node_modules ve geçici dosyaları atla
rsync -av 
  --filter='- node_modules/' 
  --filter='- .git/' 
  --filter='- *.pyc' 
  --filter='- __pycache__/' 
  --filter='- .cache/' 
  --filter='- tmp/' 
  /projeler/ kullanici@hedef:/yedek/projeler/

# Filtre dosyası kullanarak daha temiz yönetim
cat > /etc/rsync-filters/gelistirme.txt << 'EOF'
- node_modules/
- .git/
- *.pyc
- *.class
- *.log
- __pycache__/
- .env
- dist/
- build/
EOF

rsync -av --filter='merge /etc/rsync-filters/gelistirme.txt' 
  /projeler/ kullanici@hedef:/yedek/

–stats ile Performansı Ölçmek

Hangi ayarların işe yaradığını doğrulamak için sayılara bakın:

rsync -av --stats /buyuk_dizin/ kullanici@hedef:/yedek/ 2>&1 | tail -20

# Örnek çıktı analizi
# Number of files: 45,231 (reg: 44,890, dir: 341)
# Number of created files: 1,203
# Number of deleted files: 0
# Number of regular files transferred: 1,203
# Total file size: 2.14T bytes
# Total transferred file size: 45.23G bytes  <-- sadece değişenleri gönderdi
# Literal data: 45.23G bytes
# Matched data: 0 bytes
# File list size: 2.34M
# Total bytes sent: 45.34G
# Total bytes received: 892.45K
# sent 45.34G bytes  received 892.45K bytes  112.45M bytes/sec  <-- hız

Total transferred file size ile Total file size arasındaki fark, rsync’in ne kadar veri tasarrufu yaptığını gösterir. bytes/sec değerini farklı ayarlarla karşılaştırarak hangisinin daha iyi çalıştığını somut olarak ölçebilirsiniz.

Daemon Modu ile Yüksek Performanslı Aktarım

Güvenliğin daha az önemli olduğu iç ağ transferlerinde rsync daemon modu SSH yükünü tamamen ortadan kaldırır:

# Hedef sunucuda /etc/rsyncd.conf oluştur
cat > /etc/rsyncd.conf << 'EOF'
uid = rsync
gid = rsync
use chroot = yes
max connections = 10
syslog facility = local5
pid file = /var/run/rsyncd.pid
log file = /var/log/rsyncd.log

[yedek]
    path = /backup
    comment = Yedek Deposu
    read only = no
    list = no
    hosts allow = 192.168.1.0/24
    transfer logging = yes
EOF

# Daemon'ı başlat
systemctl start rsync
systemctl enable rsync

# Kaynak sunucudan daemon modunda bağlan (:: kullanımına dikkat)
rsync -av --no-compress 
  /data/ rsync://192.168.1.100/yedek/

# Daha da hızlı: rsync over netcat (çok güvenilir iç ağ için)
# Hedef: nc -l -p 1234 | rsync --daemon --config=/etc/rsyncd.conf
# Kaynak: rsync -av /data/ rsync://hedef::yedek/

Özet: Senaryoya Göre Ayar Rehberi

Hangi durumda ne kullanmalısınız:

• Yerel ağ, büyük dosyalar: --whole-file --no-compress -e "ssh -c [email protected]" kombinasyonu
• WAN, değişken içerik: -z --compress-level=3 --partial --partial-dir
• Karma içerik (resim + metin): --skip-compress=jpg/mp4/zip/gz --compress-level=1
• Çok sayıda küçük dosya: SSH ControlMaster + paralel transfer
• Üretim saatleri: --bwlimit + nice -n 19 ionice -c 3
• İç ağ, maksimum hız: rsync daemon modu + TCP tampon optimizasyonu

Sonuç

rsync’i hızlandırmak tek bir sihirli parametre meselesi değil. Ağınızın yapısını, dosyalarınızın türünü, aktarım zamanlamasını ve hedef sistemin kapasitesini göz önünde bulundurarak doğru kombinasyonu bulmak gerekiyor.

Başlangıç noktası olarak şunu öneriyorum: Önce --stats ile mevcut durumunuzu ölçün. Sonra LAN’daysa --whole-file ve şifreleme optimizasyonunu deneyin, WAN’daysa sıkıştırma ve --partial kombinasyonunu test edin. Her değişikliği tek tek yapın ve ölçün, böylece gerçekte neyin fark yarattığını anlarsınız.

Yedekleme sistemleri çoğu zaman “bir kere kur, unut” mantığıyla bırakılır. Oysa biraz zaman ayırıp rsync ayarlarını optimize etmek, yedekleme penceresini ciddi ölçüde daraltır ve üretim sistemlerine verilen yükü azaltır. Bu da sizi gece yarısı uyandıracak olayların sayısını düşürür ki bu tek başına yeterince iyi bir motivasyon.