Rclone ile Bant Genişliği Kontrolü ve Zamanlama

Tarafındankomut
0 Comments

Yedekleme işlemleri güzel bir şeydir, ta ki gece yarısı production sunucunuzun ağını kilitleyen bir rclone transferi yüzünden müşterilerden şikayet almaya başlayana kadar. Bant genişliği kontrolü ve akıllı zamanlama, rclone kullanımının en kritik ama en az konuşulan konularından biri. Bu yazıda hem bant genişliğini nasıl sınırlayacağımızı hem de yedeklemeleri akıllıca nasıl zamanlayacağımızı ele alacağız.

Neden Bant Genişliği Kontrolü Önemli?

Diyelim ki 500 GB’lık bir veritabanı yedeğini Backblaze B2’ye veya bir uzak sunucuya gönderiyorsunuz. Rclone’u hiçbir kısıtlama olmadan çalıştırırsanız, mevcut tüm bant genişliğini yerle bir eder. Bunu production saatlerinde yaparsanız:

  • Web siteniz yavaşlar veya erişilemez hale gelir
  • Veritabanı bağlantıları zaman aşımına uğrar
  • Monitoring sistemleriniz alarm vermeye başlar
  • Telefon çalmaya başlar, ve bu genellikle iyi bir şey değildir

Rclone bu sorunu çözmek için oldukça kapsamlı araçlar sunuyor. Hem anlık sınırlamalar hem de zaman dilimine göre dinamik sınırlamalar yapabiliyorsunuz.

Temel Bant Genişliği Sınırlama

En basit yöntem --bwlimit parametresidir. Bu parametre ile transferi belirli bir hız ile sınırlayabilirsiniz.

# Yükleme hızını 10 MB/s ile sınırla
rclone copy /backup/db-dump.tar.gz remote:backups --bwlimit 10M

# Hem yükleme hem indirme hızını ayrı ayrı ayarla
# Format: yükleme:indirme
rclone copy /backup/ remote:backups --bwlimit 10M:5M

# Kilobit cinsinden de belirtebilirsiniz
rclone sync /var/www/ remote:web-backup --bwlimit 512k

Burada dikkat edilmesi gereken nokta: --bwlimit değeri byte değil bit cinsinden değil, byte cinsindendir. Yani 10M dediğinizde 10 MB/s demek. Bunu karıştırmak çok yaygın bir hata.

Zaman Dilimine Göre Dinamik Bant Genişliği

İşte rclone’un gerçekten parlayan özelliği burada. --bwlimit parametresine birden fazla zaman dilimi ve hız çifti verebilirsiniz. Böylece mesai saatlerinde düşük, gece yarısı yüksek bant genişliği kullanabilirsiniz.

# Mesai saatlerinde (09:00-18:00) 2M, gece yarısı sınırsız
rclone sync /backup/ remote:backups 
  --bwlimit "09:00,2M 18:00,off"

# Daha detaylı bir zamanlama
rclone sync /backup/ remote:backups 
  --bwlimit "08:00,1M 12:00,500k 13:00,1M 18:00,20M 23:00,off 06:00,5M"

Format şu şekilde çalışır: SS:DD,hız çiftleri boşlukla ayrılır. off kelimesi sınırsız anlamına gelir, 0 ise transferi tamamen durdurur.

Daha gerçekçi bir örnek verelim. Bir e-ticaret sitesi yönetiyorsunuz, yoğun saatler 10:00-22:00 arası:

rclone sync /var/backups/ecommerce/ r2:ecommerce-backup 
  --bwlimit "00:00,off 10:00,2M 22:00,off" 
  --transfers 4 
  --checkers 8 
  --log-file /var/log/rclone/ecommerce-backup.log 
  --log-level INFO

Bu komut gece 00:00’dan sabah 10:00’a kadar sınırsız, 10:00’dan 22:00’ya kadar 2 MB/s, 22:00’dan gece 00:00’a kadar tekrar sınırsız transfer yapacak.

Rclone Konfigürasyon Dosyasında Bant Genişliği Ayarları

Her seferinde komut satırında parametre yazmak yerine, rclone’un konfigürasyon dosyasına (~/.config/rclone/rclone.conf) bu ayarları ekleyebilirsiniz. Ancak --bwlimit doğrudan remote konfigürasyonuna girmiyor, bunun için farklı bir yaklaşım kullanmak gerekiyor.

En temiz çözüm bir wrapper script yazmak:

#!/bin/bash
# /usr/local/bin/rclone-backup.sh

# Değişkenler
BACKUP_SOURCE="/var/backups"
BACKUP_DEST="b2:my-company-backups"
LOG_DIR="/var/log/rclone"
DATE=$(date +%Y-%m-%d_%H-%M)
LOG_FILE="${LOG_DIR}/backup-${DATE}.log"

# Log dizini yoksa oluştur
mkdir -p "$LOG_DIR"

# Çalışma saatine göre bant genişliği belirle
HOUR=$(date +%H)
if [ "$HOUR" -ge 8 ] && [ "$HOUR" -lt 20 ]; then
    BWLIMIT="3M"
    echo "Mesai saati - Bant genişliği sınırı: 3 MB/s"
else
    BWLIMIT="off"
    echo "Mesai dışı - Bant genişliği sınırsız"
fi

# Yedekleme işlemi
rclone sync "$BACKUP_SOURCE" "$BACKUP_DEST" 
    --bwlimit "$BWLIMIT" 
    --transfers 4 
    --checkers 8 
    --retries 3 
    --retries-sleep 30s 
    --log-file "$LOG_FILE" 
    --log-level INFO 
    --stats 60s 
    --stats-log-level INFO

EXIT_CODE=$?

if [ $EXIT_CODE -eq 0 ]; then
    echo "Yedekleme başarıyla tamamlandı: $(date)"
else
    echo "HATA: Yedekleme başarısız! Çıkış kodu: $EXIT_CODE" >&2
    # Buraya alerting entegrasyonu ekleyebilirsiniz
fi

exit $EXIT_CODE

Cron ile Akıllı Zamanlama

Script hazır, şimdi bunu cron ile zamanlamalıyız. Burada önemli bir nokta: rclone transferleri uzun sürebilir, bu yüzden çakışan çalışmaları engellemek gerekir.

# /etc/cron.d/rclone-backup içeriği
# Her gün gece 02:00'da çalıştır
0 2 * * * root /usr/local/bin/rclone-backup.sh >> /var/log/rclone/cron.log 2>&1

# Veya crontab -e ile kullanıcı crontab'ına ekle
0 2 * * * /usr/local/bin/rclone-backup.sh

Ama ya script önceki günden hala çalışıyorsa? Bunu flock ile engelleyebilirsiniz:

# Aynı anda sadece bir instance çalışsın
0 2 * * * root flock -n /tmp/rclone-backup.lock /usr/local/bin/rclone-backup.sh

flock -n ile lock alınamazsa (yani başka bir instance çalışıyorsa) komut çalışmadan çıkar.

Systemd Timer ile Daha Gelişmiş Zamanlama

Cron iyidir ama systemd timer daha güçlü özelliklere sahip. Özellikle büyük kurumsal ortamlarda systemd kullanmanızı öneririm.

Önce service dosyasını oluşturun:

# /etc/systemd/system/rclone-backup.service
[Unit]
Description=Rclone Yedekleme Servisi
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
User=backup
Group=backup
ExecStart=/usr/local/bin/rclone-backup.sh
StandardOutput=journal
StandardError=journal
# Transfer 6 saati geçerse öldür
TimeoutStopSec=6h
# Servis başarısız olursa e-posta gönder (postfix kurulu olmalı)
# OnFailure=status-email@%n.service

Şimdi timer dosyasını oluşturun:

# /etc/systemd/system/rclone-backup.timer
[Unit]
Description=Rclone Yedekleme Zamanlayıcı
Requires=rclone-backup.service

[Timer]
# Her gün 02:30'da çalıştır
OnCalendar=*-*-* 02:30:00
# Sistem yeni açıldıysa ve timer geçtiyse 15 dakika içinde çalıştır
Persistent=true
# Rastgele gecikme ekle (aynı anda çok sayıda sunucu varsa)
RandomizedDelaySec=300

[Install]
WantedBy=timers.target

Aktifleştirme ve yönetim komutları:

# Servisleri yükle ve timer'ı başlat
systemctl daemon-reload
systemctl enable rclone-backup.timer
systemctl start rclone-backup.timer

# Durumu kontrol et
systemctl status rclone-backup.timer
systemctl list-timers rclone-backup.timer

# Manuel olarak çalıştır
systemctl start rclone-backup.service

# Logları izle
journalctl -u rclone-backup.service -f

Systemd timer’ın cron’a göre avantajları:

  • Persistent=true: Sistem kapalıyken geçen timer’ları yakalar ve sistem açıldığında çalıştırır
  • RandomizedDelaySec: Birden fazla sunucu varsa aynı anda aynı remote’a bağlanmayı önler
  • Bağımlılık yönetimi: After=network-online.target ile ağ hazır olmadan başlamaz
  • Journal entegrasyonu: Tüm loglar journald’a otomatik gider

Çoklu Remote ile Yük Dengeleme

Büyük veri hacimlerinde tek bir remote yetersiz kalabilir. Rclone’un union remote özelliği veya paralel transferler ile bunu çözebilirsiniz.

#!/bin/bash
# /usr/local/bin/multi-remote-backup.sh
# Farklı backup hedeflerine paralel yedekleme

BACKUP_SOURCE="/var/backups"
DATE=$(date +%Y-%m-%d)

# B2'ye kritik yedekleri gönder (daha yüksek öncelik)
rclone sync "${BACKUP_SOURCE}/critical" b2:company-critical 
    --bwlimit "09:00,5M 18:00,20M" 
    --log-file /var/log/rclone/b2-critical-${DATE}.log &

PID_B2=$!

# S3'e tam yedek gönder (daha düşük öncelik, daha kısıtlı bant genişliği)
rclone sync "${BACKUP_SOURCE}/full" s3:company-full-backup 
    --bwlimit "09:00,2M 18:00,10M" 
    --log-file /var/log/rclone/s3-full-${DATE}.log &

PID_S3=$!

# Her iki işlemin bitmesini bekle
wait $PID_B2
EXIT_B2=$?

wait $PID_S3
EXIT_S3=$?

if [ $EXIT_B2 -ne 0 ] || [ $EXIT_S3 -ne 0 ]; then
    echo "Yedekleme hatası! B2: ${EXIT_B2}, S3: ${EXIT_S3}" >&2
    exit 1
fi

echo "Tüm yedeklemeler başarıyla tamamlandı."

Transfer Parametreleri ile Performans Optimizasyonu

Bant genişliği sınırlamasıyla birlikte transfer parametrelerini de doğru ayarlamak önemli. Yanlış ayarlar bant genişliğini verimsiz kullanmanıza neden olabilir.

rclone sync /backup/ remote:backup 
    --bwlimit 20M 
    --transfers 8 
    --checkers 16 
    --buffer-size 64M 
    --multi-thread-streams 4 
    --multi-thread-cutoff 250M 
    --fast-list 
    --log-level INFO 
    --stats 30s

Parametrelerin ne işe yaradığını açıklayalım:

  • –transfers 8: Aynı anda 8 dosya transferi yapar. SSD’li sistemlerde artırabilirsiniz.
  • –checkers 16: Değişen dosyaları kontrol eden worker sayısı. Çok sayıda küçük dosya için artırın.
  • –buffer-size 64M: Her transfer için bellek tamponu. RAM’iniz yeterliyse artırın.
  • –multi-thread-streams 4: Büyük dosyaları paralel parçalar halinde gönderir.
  • –multi-thread-cutoff 250M: Bu boyutun üzerindeki dosyalar için multi-thread kullanılır.
  • –fast-list: Destekleyen remote’larda (S3, B2) listelemeyi tek API çağrısıyla yapar, API maliyetini düşürür.

Gerçek Dünya Senaryosu: E-ticaret Sunucusu

Bir müşterim için kurduğum gerçek bir yapıyı paylaşayım. Senaryo: 150 GB MySQL dump + 80 GB medya dosyaları, günde bir kez Wasabi’ye yedekleme, mesai saatlerinde (09:00-21:00) maksimum 5 MB/s, gece sınırsız.

#!/bin/bash
# /usr/local/bin/ecommerce-backup.sh

set -euo pipefail

# Konfigürasyon
DB_DUMP_DIR="/var/backups/mysql"
MEDIA_DIR="/var/www/html/media"
REMOTE="wasabi:ecommerce-prod"
LOG_DIR="/var/log/rclone"
LOCK_FILE="/tmp/ecommerce-backup.lock"
DATE=$(date +%Y-%m-%d_%H%M)
RETENTION_DAYS=30

mkdir -p "$LOG_DIR"

# Lock kontrolü
exec 9>"$LOCK_FILE"
if ! flock -n 9; then
    echo "$(date): Yedekleme zaten çalışıyor, çıkılıyor." | tee -a "${LOG_DIR}/ecommerce.log"
    exit 1
fi

echo "$(date): Yedekleme başlıyor..." | tee -a "${LOG_DIR}/ecommerce.log"

# MySQL dump al
mysqldump --single-transaction --all-databases | 
    gzip > "${DB_DUMP_DIR}/full-${DATE}.sql.gz"

# Rclone ile gönder - dinamik bant genişliği
rclone copy "${DB_DUMP_DIR}/full-${DATE}.sql.gz" 
    "${REMOTE}/database/" 
    --bwlimit "09:00,3M 21:00,off" 
    --retries 5 
    --retries-sleep 60s 
    --transfers 2 
    --log-file "${LOG_DIR}/db-${DATE}.log" 
    --log-level INFO 
    --stats 60s

# Medya dosyalarını sync et
rclone sync "$MEDIA_DIR" "${REMOTE}/media/" 
    --bwlimit "09:00,2M 21:00,off" 
    --transfers 4 
    --checkers 8 
    --exclude "*.tmp" 
    --exclude ".cache/**" 
    --log-file "${LOG_DIR}/media-${DATE}.log" 
    --log-level INFO 
    --stats 120s

# Eski yedekleri temizle (sadece uzak sunucudan)
rclone delete "${REMOTE}/database/" 
    --min-age "${RETENTION_DAYS}d" 
    --log-file "${LOG_DIR}/cleanup-${DATE}.log"

echo "$(date): Yedekleme tamamlandı." | tee -a "${LOG_DIR}/ecommerce.log"

# Eski log dosyalarını temizle
find "$LOG_DIR" -name "*.log" -mtime +7 -delete

Bu script’te dikkat edilmesi gereken önemli noktalar:

  • set -euo pipefail: Herhangi bir hata olduğunda script durur
  • flock: Aynı anda iki yedekleme çalışmasını engeller
  • –exclude: Gereksiz geçici dosyaları yedeklemeyi atlar
  • Veritabanı ve medya için farklı bant genişliği sınırları (veritabanı daha kritik)

Rclone RC ile Canlı Bant Genişliği Değiştirme

Çalışan bir rclone işleminin bant genişliğini durdurmadan değiştirmek ister misiniz? rclone rc (remote control) özelliği tam bunun için var.

# Rclone'u RC ile başlat
rclone sync /backup/ remote:backup 
    --bwlimit 5M 
    --rc 
    --rc-addr :5572 &

# Çalışırken bant genişliğini değiştir
rclone rc core/bwlimit rate=10M

# Mevcut bant genişliğini sorgula
rclone rc core/bwlimit

# Sınırı kaldır
rclone rc core/bwlimit rate=off

# Transfer istatistiklerini al
rclone rc core/stats

Bu özellik özellikle beklenmedik bir durum olduğunda (örneğin acil bir deployment) çok işe yarıyor. Transfer işlemini öldürmeden bant genişliğini neredeyse sıfıra çekebilirsiniz.

Güvenlik için RC’yi sadece localhost’ta açmanızı ve şifre koruması eklemenizi öneririm:

rclone sync /backup/ remote:backup 
    --rc 
    --rc-addr 127.0.0.1:5572 
    --rc-user admin 
    --rc-pass guclu-bir-sifre

Transfer Sonrası Doğrulama

Bant genişliği kontrolü kadar önemli bir konu da transferin doğru yapıldığından emin olmak. Özellikle sınırlı bant genişliğinde uzun süren transferlerde veri bütünlüğü kritik.

#!/bin/bash
# Yedekleme sonrası doğrulama scripti

SOURCE="/var/backups/critical"
REMOTE="b2:company-critical"

echo "Yedekleme başlıyor..."
rclone sync "$SOURCE" "$REMOTE" 
    --bwlimit "09:00,3M 18:00,off" 
    --checksum 
    --log-file /var/log/rclone/backup.log

echo "Doğrulama başlıyor..."
rclone check "$SOURCE" "$REMOTE" 
    --checksum 
    --log-file /var/log/rclone/verify.log

if [ $? -eq 0 ]; then
    echo "Doğrulama başarılı - tüm dosyalar tutarlı"
else
    echo "UYARI: Doğrulama başarısız! Log dosyasını kontrol edin."
    exit 1
fi

–checksum parametresi, dosya boyutu ve tarih yerine gerçek hash değerlerini karşılaştırır. Bu daha yavaş ama çok daha güvenilirdir.

Log Yönetimi ve İzleme

Uzun süreli yedekleme operasyonlarında log yönetimi kritik. Rclone’un log formatını iyi anlamak sorun tespitini kolaylaştırır.

# Detaylı istatistiklerle çalıştır
rclone sync /backup/ remote:backup 
    --bwlimit 10M 
    --log-file /var/log/rclone/backup.log 
    --log-level INFO 
    --stats 30s 
    --stats-file /var/log/rclone/stats.json 
    --use-json-log

# Logları gerçek zamanlı izle
tail -f /var/log/rclone/backup.log | grep -E "(ERROR|WARN|Transferred|ETA)"

Logrotate ile log dosyalarını yönetin:

# /etc/logrotate.d/rclone
/var/log/rclone/*.log {
    weekly
    rotate 4
    compress
    delaycompress
    missingok
    notifempty
    create 0640 backup backup
}

Sonuç

Rclone’u bant genişliği kontrolü olmadan çalıştırmak, araba kullanırken fren olmadan gitmek gibi bir şey. Bir yere kadar gidebilirsiniz ama sonunda bir şey kırılacak.

Özetlersek, sağlıklı bir rclone yedekleme stratejisi için şunları mutlaka yapın:

  • Zaman dilimine göre dinamik bant genişliği ayarlayın (--bwlimit "09:00,3M 18:00,off")
  • Systemd timer veya flock’lu cron ile çakışmaları önleyin
  • Transfer parametrelerini ortamınıza göre optimize edin
  • rclone rc ile acil durum müdahalesi için hazırlıklı olun
  • --checksum ile düzenli doğrulama yapın
  • Logları düzgün tutun ve izleyin

En az bir kez production ortamda bant genişliği sorunuyla karşılaştıysanız bu yazıyı zaten hayatınıza uygulamışsınızdır. Karşılaşmadıysanız, inanın bana, karşılaşmadan önce bu ayarları yapmak çok daha keyifli.

Bir yanıt yazın

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