Restic ve Rclone Karşılaştırması: Hangisi Ne Zaman?

Yedekleme dünyasında iki araç var ki her sysadmin’in masasında bir noktada karşısına çıkıyor: Restic ve Rclone. İkisi de açık kaynak, ikisi de güçlü, ikisi de uzak depolama alanlarını destekliyor. Ama bu iki araç temelden farklı felsefelere sahip ve hangisini kullanacağını bilmeden kurulum yapmak, sonradan ciddi baş ağrısına dönüşebiliyor. Bu yazıda her iki aracı derinlemesine inceleyeceğiz, gerçek dünya senaryolarıyla hangisinin ne zaman tercih edilmesi gerektiğini net biçimde ortaya koyacağız.

Restic Nedir, Rclone Nedir?

Önce kafamızı netleştirelim. Bu iki araç aynı kategoride gibi görünse de aslında farklı problemleri çözüyor.

Restic, bir yedekleme aracıdır. Veriyi alır, chunk’lara böler, deduplikasyon uygular, şifreler ve bir repository’ye yazar. Snapshot mantığıyla çalışır. Her yedekleme bir snapshot oluşturur ve bu snapshot’lar birbirine referans vererek depolama alanından tasarruf sağlar. Restic’in odak noktası bütünlük, güvenlik ve verimli depolama.

Rclone ise bir dosya senkronizasyon ve bulut yönetim aracıdır. Temelde “bu dosyaları şuradan şuraya taşı/senkronize et” mantığıyla çalışır. 40’tan fazla bulut depolama sağlayıcısını destekler. Rclone’un odak noktası esneklik, geniş destek ve dosya düzeyinde kontrol.

Peki neden ikisi sık sık karşılaştırılıyor? Çünkü her ikisi de uzak depolama alanına yedekleme senaryolarında kullanılabiliyor. Ama kullanım biçimleri, yetenekleri ve zayıflıkları çok farklı.

Kurulum ve İlk Adımlar

Her iki aracı da hızlıca kuralım ve temel mantığı görelim.

# Restic kurulumu (Ubuntu/Debian)
sudo apt install restic

# Veya en güncel versiyonu binary olarak indirmek için
wget https://github.com/restic/restic/releases/download/v0.16.4/restic_0.16.4_linux_amd64.bz2
bunzip2 restic_0.16.4_linux_amd64.bz2
chmod +x restic_0.16.4_linux_amd64
sudo mv restic_0.16.4_linux_amd64 /usr/local/bin/restic

# Rclone kurulumu
curl https://rclone.org/install.sh | sudo bash

# Versiyon kontrolü
restic version
rclone version

Restic ile yedekleme yapmadan önce bir repository başlatmanız gerekiyor. Bu adım kritik, çünkü Restic’in tüm deduplikasyon ve şifreleme altyapısı bu repository üzerinden yönetiliyor.

# Yerel repository başlatma
restic init --repo /mnt/backup/myrepo

# S3 üzerinde repository başlatma
export AWS_ACCESS_KEY_ID="your-access-key"
export AWS_SECRET_ACCESS_KEY="your-secret-key"
restic init --repo s3:s3.amazonaws.com/my-bucket/restic-repo

# Şifre environment variable olarak vermek (otomasyonda kullanışlı)
export RESTIC_PASSWORD="güçlü-bir-şifre"

Rclone tarafında ise önce bir remote yapılandırmanız gerekiyor:

# Interaktif yapılandırma sihirbazını başlat
rclone config

# Yapılandırmadan sonra mevcut remote'ları listele
rclone listremotes

# S3 remote'u test etmek için
rclone ls s3remote:my-bucket

# Basit bir kopyalama işlemi
rclone copy /local/data s3remote:my-bucket/backup/

Deduplikasyon: Restic’in Asıl Gücü

Restic’i öne çıkaran en önemli özellik content-defined chunking ile yapılan deduplikasyon. Bu ne demek? Yedeklediğiniz dosya değiştiğinde Restic sadece değişen parçaları yükler. 10 GB’lık bir veritabanı yedeğinde 100 MB’lık bir değişiklik olduysa, Restic sadece o 100 MB’ı yükler.

Rclone’da bu mekanizma varsayılan olarak yok. rclone sync veya rclone copy komutları dosyaların değişip değişmediğini kontrol eder ama değişen dosyayı baştan sona yükler. Bu, büyük dosyalar söz konusu olduğunda ciddi bant genişliği farkına yol açıyor.

# Restic ile bir dizini yedekle
restic backup /var/www/html --repo /mnt/backup/repo

# İkinci yedekleme - sadece değişiklikler yüklenir
restic backup /var/www/html --repo /mnt/backup/repo

# Snapshot listesini görmek için
restic snapshots --repo /mnt/backup/repo

# Depolama istatistiklerini gör (deduplikasyon tasarrufunu görmek için)
restic stats --repo /mnt/backup/repo

Yukarıdaki stats komutunun çıktısında Total Blob Count ve Total Size değerlerine bakarak deduplikasyonun ne kadar alan kazandırdığını görebilirsiniz. Genellikle birden fazla snapshot sonrasında bu fark dramatik olmaya başlar.

Şifreleme: Restic Varsayılan, Rclone Opsiyonel

Restic’te şifreleme zorunlu. Repository oluştururken bir şifre belirlemek zorundasınız ve veriler AES-256 ile şifrelenerek depolanıyor. Bu, özellikle üçüncü taraf depolama alanı kullanıyorsanız (S3, Backblaze, Google Cloud Storage vb.) büyük bir avantaj.

Rclone’da şifreleme opsiyonel ve ayrı bir katman olarak ekleniyor. crypt remote tipiyle bir şifreleme katmanı ekleyebilirsiniz:

# Rclone'da şifreli remote oluşturma (config dosyasına eklenecek)
# Önce rclone config ile "crypt" tipinde yeni bir remote oluşturun
# remote = s3remote:my-bucket
# filename_encryption = standard
# directory_name_encryption = true

# Şifreli remote ile kopyalama
rclone copy /local/data cryptremote:backup/

# Dosya adlarının da şifreli olduğuna dikkat edin
rclone ls cryptremote:backup/

Pratik dünyada bu fark şu anlama geliyor: Eğer güvenlik önceliğinizse ve verileriniz bulut storage’a gidiyorsa, Restic daha az adımda daha güvenli bir yapı kuruyor. Rclone’la aynı güvenlik seviyesini elde edebilirsiniz ama yapılandırma daha karmaşık.

Gerçek Dünya Senaryosu 1: Web Sunucusu Yedeği

Diyelim ki 50 GB’lık bir web uygulamanız var, günlük değişim %2-3 civarında. Veriler kritik ve aylarca geri dönme imkanı olmasını istiyorsunuz.

Bu senaryo Restic için biçilmiş kaftan.

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

export RESTIC_REPOSITORY="s3:s3.amazonaws.com/company-backups/webapp"
export RESTIC_PASSWORD_FILE="/etc/restic/password"
export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"

# Yedekleme al
restic backup /var/www/html /etc/nginx --tag webapp --tag production

# 7 günlükten fazla günlük snapshot'ı temizle
# 4 haftadan fazla haftalık snapshot'ı temizle
# 12 aydan fazla aylık snapshot'ı temizle
restic forget 
  --keep-daily 7 
  --keep-weekly 4 
  --keep-monthly 12 
  --prune 
  --tag webapp

# Repository bütünlüğünü kontrol et (haftada bir çalıştırın)
# restic check

echo "Yedekleme tamamlandı: $(date)"

Bu script’i crontab’a ekleyip her gece çalıştırabilirsiniz:

# Crontab girişi
0 2 * * * /usr/local/bin/backup-webapp.sh >> /var/log/restic-backup.log 2>&1

Aynı senaryoyu Rclone ile yapmaya çalışsanız:

Snapshot desteği yok, eski versiyonlara geri dönmek için kendi versiyonlama mantığınızı kurmanız gerekir
50 GB’lık verinin tamamı ilk yüklemede gidiyor, sonraki günlerde değişen dosyalar tekrar tam olarak yükleniyor
Retention policy yönetimi için ek script yazmanız gerekiyor

Gerçek Dünya Senaryosu 2: Medya Dosyaları Arşivi

Şimdi farklı bir senaryo: Fotoğraf stüdyosu için RAW fotoğraf arşivi. Dosyalar bir kez yükleniyor, nadiren değişiyor, boyutları büyük (her biri 30-50 MB) ve toplamda 2 TB’ı aşıyor. Sadece senkronize bir kopyasının bulutta olması yeterli.

Bu senaryo Rclone için daha uygun.

#!/bin/bash
# Medya arşivini Google Drive'a senkronize et

# Sadece yeni dosyaları kopyala, silinenleri silme
rclone copy /mnt/storage/photos gdrive:PhotoArchive/ 
  --progress 
  --transfers 4 
  --checkers 8 
  --log-file /var/log/rclone-photos.log 
  --log-level INFO

# Veya tam senkronizasyon (silinen dosyaları da sil)
rclone sync /mnt/storage/photos gdrive:PhotoArchive/ 
  --progress 
  --backup-dir gdrive:PhotoArchive-deleted/$(date +%Y%m%d) 
  --transfers 4

Bu senaryoda Restic kullanmak overkill olur çünkü:

Dosyalar değişmiyor, deduplikasyon çok az tasarruf sağlar
Snapshot geçmişi gereksiz ek depolama maliyeti yaratır
RAW dosyalar zaten yüksek oranda sıkıştırılmış olduğundan Restic’in sıkıştırma özelliği fayda sağlamaz

Gerçek Dünya Senaryosu 3: Veritabanı Yedeği

Production MySQL veritabanı yedeği. Veritabanı 100 GB, günlük dump alınıyor, 30 günlük geri dönüş gerekiyor.

#!/bin/bash
# MySQL dump + Restic yedekleme

BACKUP_DIR="/tmp/mysql-dumps"
DB_NAME="production_db"
DUMP_FILE="${BACKUP_DIR}/${DB_NAME}-$(date +%Y%m%d_%H%M%S).sql.gz"

export RESTIC_REPOSITORY="b2:my-bucket:mysql-backups"
export RESTIC_PASSWORD_FILE="/etc/restic/password"
export B2_ACCOUNT_ID="your-b2-account-id"
export B2_ACCOUNT_KEY="your-b2-account-key"

# Database dump al
mkdir -p $BACKUP_DIR
mysqldump --single-transaction --routines --triggers $DB_NAME | gzip > $DUMP_FILE

if [ $? -eq 0 ]; then
  # Restic ile yedekle
  restic backup $DUMP_FILE --tag mysql --tag $DB_NAME
  
  # Yerel geçici dosyayı sil
  rm -f $DUMP_FILE
  
  # Eski snapshot'ları temizle
  restic forget --keep-daily 30 --prune --tag mysql
else
  echo "HATA: MySQL dump başarısız!" | mail -s "Yedekleme Hatası" [email protected]
  exit 1
fi

Veritabanı dump dosyaları günlük olarak değiştiğinden ve Restic benzer içerikleri deduplike edebildiğinden, 30 günlük dump saklamak göründüğü kadar pahalı olmaz. İçeriğin %80’i her gün aynıysa, gerçekte birkaç günlük ek depolama maliyetiyle 30 snapshot saklayabilirsiniz.

Geri Yükleme Karşılaştırması

Felaket anında geri yükleme süreci kritik. İki araç arasındaki fark burada da belirgin.

# Restic ile geri yükleme
# Önce snapshot listesini gör
restic snapshots --repo s3:s3.amazonaws.com/my-bucket/repo

# Belirli bir snapshot'ı geri yükle
restic restore abc12345 --target /tmp/restore --repo s3:s3.amazonaws.com/my-bucket/repo

# Belirli bir dosyayı geri yükle
restic restore latest --include "/var/www/html/config.php" 
  --target /tmp/restore 
  --repo s3:s3.amazonaws.com/my-bucket/repo

# Tarih bazlı geri yükleme
restic restore latest 
  --before "2024-01-15 10:00:00" 
  --target /var/www/html-restore 
  --repo s3:s3.amazonaws.com/my-bucket/repo

Rclone’da geri yükleme basit ama daha az esnek:

# Rclone ile geri yükleme (tek yön)
rclone copy s3remote:my-bucket/backup/ /local/restore/ --progress

# Belirli bir dosyayı geri yükle
rclone copy s3remote:my-bucket/backup/important-file.txt /local/restore/

# Senkronize et (hedefte fazla dosyaları sil)
rclone sync s3remote:my-bucket/backup/ /local/data/ --dry-run
# --dry-run'ı kaldırarak gerçek işlemi yap
rclone sync s3remote:my-bucket/backup/ /local/data/

Restic’in restore latest --before özelliği gerçek dünyada hayat kurtarıcı. “Dün saat 14:00’te bir şeyler bozuldu, o noktaya dönelim” dediğinizde Restic tam olarak istediğinizi yapıyor. Rclone’da bu tür nokta bazlı geri dönüş için ya versiyonlama özelliği olan bir storage kullanmanız (S3 versioning gibi) ya da kendi zaman damgalı klasör yapınızı kurmanız gerekiyor.

Performans ve Bant Genişliği

Rclone paralel transfer konusunda daha esnek ve ince ayarlara izin veriyor:

# Rclone bant genişliği limiti ile senkronizasyon
rclone sync /local/data remote:bucket 
  --bwlimit 10M 
  --transfers 8 
  --checkers 16 
  --buffer-size 256M 
  --fast-list

# Sadece belirli saatlerde tam bant genişliğiyle çalış
# 08:00-18:00 arası 2M, diğer saatlerde limitsiz
rclone sync /local/data remote:bucket 
  --bwlimit "08:00,2M 18:00,off"

Restic’te de bant genişliği yönetimi mevcut ama daha basit:

# Restic upload/download hız limiti (megabytes cinsinden)
restic backup /data --limit-upload 5000 --limit-download 10000

# Paralel worker sayısını ayarla
restic backup /data --pack-size 128

Büyük dosyaların ilk kez yüklenmesinde Rclone daha hızlı çünkü dosyayı direkt yüklüyor, chunk işlemi yapmıyor. Restic her dosyayı parçalara böldüğünden ilk yükleme biraz daha uzun sürebiliyor. Ancak sonraki yüklemelerde Restic ciddi avantaj kazanıyor.

Desteklenen Depolama Alanları

Bu konuda Rclone açık ara öndedir:

Rclone desteklediği önemli platformlar şunlar:

Amazon S3 ve S3-uyumlu her servis (MinIO, Wasabi, Backblaze B2 S3 API)
Google Drive ve Google Cloud Storage
Microsoft OneDrive ve Azure Blob Storage
Dropbox, Box, pCloud
FTP/SFTP sunucuları
WebDAV uyumlu her sistem
Mega, yandex disk, hatta bazı NAS cihazları

Restic’in desteklediği backend’ler daha sınırlı ama yeterli:

Local dosya sistemi
SFTP
Amazon S3 ve S3-uyumlu servisler
Azure Blob Storage
Google Cloud Storage
Backblaze B2
REST Server (Restic’in kendi REST sunucu implementasyonu)
rclone ile entegrasyon (evet, Restic Rclone’u backend olarak kullanabiliyor!)

Bu son nokta önemli: Restic’in desteklemediği bir depolama alanına yedeklemek istiyorsanız, Rclone’u Restic backend’i olarak kullanabilirsiniz.

# Rclone'u Restic backend olarak kullanma
# Önce rclone remote'unu yapılandırın, sonra:
restic -r rclone:gdrive:restic-repo init
restic -r rclone:gdrive:restic-repo backup /data

Bu kombinasyon güçlü bir seçenek: Rclone’un geniş storage desteğini, Restic’in deduplikasyon ve şifreleme yetenekleriyle birleştiriyorsunuz.

Monitoring ve Alerting

Production ortamında yedekleme başarı/başarısızlığını takip etmek kritik.

#!/bin/bash
# Restic yedekleme sonucunu Slack'e bildir

WEBHOOK_URL="https://hooks.slack.com/services/xxx/yyy/zzz"

restic backup /var/www /etc --repo s3:s3.amazonaws.com/bucket/repo
EXIT_CODE=$?

if [ $EXIT_CODE -eq 0 ]; then
  MESSAGE="✅ Yedekleme başarılı: $(hostname) - $(date)"
  COLOR="good"
else
  MESSAGE="❌ Yedekleme BAŞARISIZ: $(hostname) - $(date) - Exit: $EXIT_CODE"
  COLOR="danger"
fi

curl -s -X POST $WEBHOOK_URL 
  -H 'Content-type: application/json' 
  -d "{"attachments": [{"color": "$COLOR", "text": "$MESSAGE"}]}"

# Healthchecks.io ile entegrasyon (başarılı tamamlanmayı ping at)
if [ $EXIT_CODE -eq 0 ]; then
  curl -s https://hc-ping.com/your-uuid
fi

Rclone’da --log-file ve --log-level ile detaylı loglama yapılabiliyor. Loglara bakarak başarısız transferleri takip etmek mümkün, ama Restic’in bütünleşik bütünlük kontrol mekanizması kadar kapsamlı değil.

Hangisini Ne Zaman Seçmelisiniz?

Restic’i tercih edin eğer:

Kritik veriler yedekliyorsanız ve geri dönüş gerekebilecekse
Sık değişen dosyalarınız varsa (veritabanları, kod, konfigürasyon)
Uzun retention gerekiyorsa (aylarca, yıllarca snapshot saklamak)
Şifreleme önceliğinizse ve yapılandırma karmaşıklığı istemiyorsanız
Depolama maliyetini minimize etmek istiyorsanız (deduplikasyon sayesinde)
Belirli bir zamana geri dönme ihtiyacınız olabilecekse

Rclone’u tercih edin eğer:

Dosya senkronizasyonu yapıyorsanız (iki lokasyon arası eşitleme)
Desteklenmeyen bir platform kullanıyorsanız (Google Drive, OneDrive, Mega vb.)
Verilerinizin okunabilir biçimde bulutta durmasını istiyorsanız (Restic repository şifreli ve kendi formatında)
Büyük ve değişmeyen dosya arşivlerini yönetiyorsanız
Bulutlar arası veri taşıma veya eşitleme yapıyorsanız
Script olmadan GUI veya komut satırıyla manuel yönetim yapacaksanız

İkisini birlikte kullanın eğer:

Restic’in desteklemediği bir platforma yedekleme yapacaksanız (rclone backend ile)
Birincil yedeklemeyi Restic ile yapıp sonuç repository’yi başka bir lokasyona Rclone ile taşımak istiyorsanız

Sonuç

Restic ve Rclone birbirinin rakibi değil, farklı problemlerin çözümü için tasarlanmış araçlar. Restic bir yedekleme motoru, Rclone ise bir veri taşıma ve senkronizasyon katmanı.

Sysadmin olarak masama gelen kurumsal senaryoların büyük çoğunluğunda Restic’e yöneliyorum. Neden? Çünkü yedeklemenin asıl amacı geri dönebilmek. “Dün gece 23:45’teki haline döndür” dediğinizde Restic bunu yapabiliyor. Rclone tek başına bu soruya cevap veremiyor.

Ama Rclone olmadan da hayat zor. Özellikle Google Drive veya OneDrive gibi Restic’in natively desteklemediği platformları kullanmak zorundaysanız, ya da basit dosya mirror/senkronizasyon ihtiyaçlarınız varsa Rclone’un sadeliği ve esnekliği rakipsiz.

En iyi senaryo? İkisini birlikte kullanmak. Restic ile akıllı, şifreli, deduplikasyonlu yedekler alın. Gerekirse Rclone’u backend olarak entegre edin veya Restic repository’sini başka lokasyonlara Rclone ile senkronize edin. Böylece her iki aracın güçlü yanlarından yararlanmış olursunuz.

Yedekleme sistemi kurmanın en kötü zamanı, disaster strike ettikten sonradır. Her iki aracı da test ortamınızda deneyip gerçek geri yükleme senaryolarını prova etmenizi şiddetle tavsiye ederim. Çünkü test edilmemiş bir yedekleme sistemi, hiç olmayan bir yedekleme sistemiyle eşdeğerdir.

Restic ve Rclone Karşılaştırması: Hangisi Ne Zaman Kullanılmalı?