Şifreli Bulut Yedekleme: Rclone Crypt ile Güvenli Yedek Yapılandırması
Bulut depolama alanlarına yedek alırken en büyük endişelerden biri güvenlik. Google Drive’a, Backblaze B2’ye ya da S3’e attığın yedek dosyaların karşı taraf tarafından okunup okunamayacağını hiç düşündün mü? Rclone Crypt tam da bu sorunu çözmek için var. Verilerini buluta göndermeden önce uçtan uca şifreleyen, açık kaynaklı ve son derece esnek bir katman. Bu yazıda Rclone Crypt’i sıfırdan yapılandıracak, gerçek dünya senaryolarında nasıl kullanacağını görecek ve üretim ortamı için en iyi pratikleri konuşacağız.
Rclone Crypt Nedir ve Neden Kullanmalısın?
Rclone, zaten birçok sysadmin’in hayatının ayrılmaz bir parçası. 70’ten fazla bulut sağlayıcısını destekleyen bu araç, basit bir rsync’in çok ötesine geçiyor. Crypt ise Rclone’un üzerine oturan bir “overlay” remote türü. Yani mevcut herhangi bir remote’un önüne geçip tüm veriyi şifreleyerek gönderip, şifreleyerek okuyabilen bir katman.
Neden bu önemli?
- Sıfır güven mimarisi: Bulut sağlayıcısına güvenmek zorunda kalmıyorsun. Veriler onların sunucularına ulaşmadan önce şifreleniyor.
- Yasal uyumluluk: KVKK, GDPR gibi regülasyonlar kapsamında hassas verileri şifreleyerek depolaman zorunlu olabilir.
- Hesap güvenliği: Bulut hesabın çalınsa bile şifreli verilerin anlamsız kalır.
- Dosya adı gizliliği: Sadece içerik değil, dosya adları ve dizin yapısı da şifrelenebilir.
Rclone Crypt, AES-256-CTR algoritmasını kullanıyor. Dosya içerikleri için Poly1305 MAC ile doğrulama yapılıyor. Yani hem şifreleme hem de bütünlük kontrolü mevcut.
Kurulum ve Ön Hazırlık
Önce Rclone’un güncel sürümünü kurduğundan emin ol:
# Linux için tek satır kurulum
curl https://rclone.org/install.sh | sudo bash
# Ya da paket yöneticisi ile
sudo apt install rclone # Debian/Ubuntu
sudo dnf install rclone # RHEL/Fedora
# Sürüm kontrolü
rclone version
Yapılandırma dosyası varsayılan olarak ~/.config/rclone/rclone.conf konumunda tutuluyor. Üretim ortamında bu dosyanın izinlerini hemen kısıtla:
chmod 600 ~/.config/rclone/rclone.conf
Bu yazıda örnek senaryo olarak Backblaze B2 kullanacağız ama mantık Dropbox, Google Drive, S3, OneDrive için de birebir aynı. Önce bir temel B2 remote’u oluştur, sonra bunun üzerine Crypt katmanını ekleyeceğiz.
Temel Remote Yapılandırması (B2 Örneği)
Interaktif yapılandırma yerine doğrudan config dosyasını düzenlemek, otomasyon için çok daha temiz bir yaklaşım. Ama ilk kurulumda rclone config komutunu da kullanabilirsin:
rclone config
# New remote > n
# Name: b2-main
# Type: backblaze b2
# account: SENIN_ACCOUNT_ID
# key: SENIN_APPLICATION_KEY
Ya da doğrudan config dosyasına ekle:
cat >> ~/.config/rclone/rclone.conf << 'EOF'
[b2-main]
type = b2
account = 000youraccountid000
key = K000yourApplicationKey000
hard_delete = false
EOF
Bağlantıyı test et:
rclone lsd b2-main:
rclone mkdir b2-main:encrypted-backups
Crypt Remote Oluşturma
İşte asıl kısım burası. Crypt remote’u oluştururken iki kritik parametre var: şifre ve tuz (salt). Bu iki değeri kaybedersen verilerine bir daha erişemezsin, bu yüzden çok dikkatli saklamanı öneririm.
# Interaktif yöntem
rclone config
# New remote > n
# Name: b2-encrypted
# Type: crypt (ya da numara ile seç)
# Remote: b2-main:encrypted-backups
# Filename encryption: standard
# Directory name encryption: true
# Password: (güçlü bir şifre gir)
# Salt: (farklı, güçlü bir değer gir)
Doğrudan config dosyasına eklemek istersen, önce şifreleri Rclone’un kendi formatına çevirmen gerekiyor:
# Şifreyi Rclone formatına çevir
rclone obscure "SuperGizliSifre123!"
# Çıktı: abc123xyz_rclone_formatted_password
rclone obscure "FarkliTuzDegeri456!"
# Çıktı: def456uvw_rclone_formatted_salt
Ardından config dosyasına ekle:
cat >> ~/.config/rclone/rclone.conf << 'EOF'
[b2-encrypted]
type = crypt
remote = b2-main:encrypted-backups
filename_encryption = standard
directory_name_encryption = true
password = abc123xyz_rclone_formatted_password
password2 = def456uvw_rclone_formatted_salt
EOF
Önemli not: rclone obscure komutu güvenlik şifrelemesi değil, sadece config dosyasında plain text görünmesini engelleyen bir encoding. Gerçek şifreleme, Crypt katmanının kendisi tarafından yapılıyor.
Filename Encryption Seçenekleri
Dosya adı şifrelemesi için üç seçenek var:
- standard: Dosya adı şifrelenir, uzantı korunmaz. En güvenli seçenek.
- obfuscate: Gerçek şifreleme yapmaz, sadece karakterleri karıştırır. Güvenlik açısından zayıf.
- off: Dosya adları şifrelenmez, sadece içerik şifrelenir. Dosya yapısı görünür kalır.
Üretim ortamı için standard kullan. Dizin adı şifrelemesi de açık olsun ki klasör yapın da gizli kalsın.
İlk Senkronizasyon ve Temel Operasyonlar
Remote hazır olduğunda normal bir Rclone remote’u gibi kullanabilirsin. Rclone şifreleme/çözme işlemini arka planda otomatik yapıyor:
# Dizin kopyala
rclone copy /var/backups/mysql b2-encrypted:mysql-backups
# Senkronize et (kaynak ile eşitle, eksikleri sil)
rclone sync /etc b2-encrypted:etc-configs
# Uzaktaki dosyaları listele (şifresi çözülmüş adlarla görürsün)
rclone ls b2-encrypted:
# Tek dosya indir
rclone copy b2-encrypted:mysql-backups/dump.sql.gz /tmp/restore/
B2 paneline gidip encrypted-backups bucket’ına bakarsan dosya adlarının tamamen anlamsız bir karakter dizisine dönüştüğünü göreceksin. Bu, tam istediğimiz şey.
Gerçek Dünya Senaryosu: Otomatik MySQL Yedeği
Şimdi bunu gerçekçi bir senaryoya taşıyalım. Bir production MySQL sunucusunun günlük yedeğini alıp şifreleyerek B2’ye gönderen bir script:
#!/bin/bash
# /usr/local/bin/mysql-backup-encrypted.sh
set -euo pipefail
# Değişkenler
DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_DIR="/var/backups/mysql"
BACKUP_FILE="${BACKUP_DIR}/mysql_full_${DATE}.sql.gz"
REMOTE_PATH="b2-encrypted:mysql-backups"
RETENTION_DAYS=30
LOG_FILE="/var/log/mysql-backup.log"
# Log fonksiyonu
log() {
echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a "$LOG_FILE"
}
log "Yedekleme basliyor..."
# Backup dizinini oluştur
mkdir -p "$BACKUP_DIR"
# MySQL dump al
mysqldump
--user=backup_user
--password="$(cat /etc/mysql/backup_password)"
--all-databases
--single-transaction
--routines
--triggers
2>>"$LOG_FILE" | gzip -9 > "$BACKUP_FILE"
log "MySQL dump tamamlandi: $BACKUP_FILE"
# Rclone ile şifreli upload
rclone copy
--progress
--transfers=4
--checkers=8
--retries=3
--log-file="$LOG_FILE"
--log-level=INFO
"$BACKUP_FILE"
"$REMOTE_PATH/"
log "Upload tamamlandi."
# Eski yerel dosyaları temizle (7 günden eski)
find "$BACKUP_DIR" -name "mysql_full_*.sql.gz" -mtime +7 -delete
log "Eski lokal dosyalar temizlendi."
# Uzaktaki eski dosyaları temizle (30 günden eski)
rclone delete
--min-age="${RETENTION_DAYS}d"
"$REMOTE_PATH/"
log "Uzaktaki eski dosyalar temizlendi."
log "Yedekleme tamamlandi."
Script’i çalıştırılabilir yap ve cron’a ekle:
chmod +x /usr/local/bin/mysql-backup-encrypted.sh
# Her gece 02:00'da çalıştır
echo "0 2 * * * root /usr/local/bin/mysql-backup-encrypted.sh" > /etc/cron.d/mysql-backup
Çoklu Sunucu Senaryosu: Merkezi Yedekleme
Birden fazla sunucun yedeklerini aynı B2 bucket’ına gönderiyorsan ama her sunucunun verilerini birbirinden izole tutmak istiyorsan, her sunucu için aynı Crypt remote üzerinde farklı bir prefix kullanabilirsin:
# web-server-01 için
rclone sync /var/www b2-encrypted:web-server-01/www
# db-server-01 için
rclone sync /var/lib/postgresql b2-encrypted:db-server-01/postgresql
# Tüm sunucuların listesini gör
rclone lsd b2-encrypted:
# web-server-01/
# db-server-01/
Daha da iyi bir yöntem: Her sunucu için farklı şifre kullanan ayrı Crypt remote’ları oluşturmak. Bu şekilde bir sunucunun şifresi ele geçirilse bile diğer sunucuların verileri güvende kalır.
Config Dosyasını Güvenli Tutmak
Rclone config dosyası, tüm şifrelerinizi (obscure formatında da olsa) barındırıyor. Bu dosyayı korumak kritik:
# Config dosyasını şifreli tutmak için rclone'un config şifreleme özelliği
rclone config
# s) Set configuration password seçeneğini kullan
# Ya da environment variable ile şifre ver
export RCLONE_CONFIG_PASS="MasterConfigSifresi"
rclone ls b2-encrypted:
Üretim ortamında environment variable yöntemini tercih et. Bu şekilde config şifresi disk üzerinde hiçbir yerde yazılı kalmıyor. Systemd servislerinde:
# /etc/systemd/system/rclone-backup.service
[Unit]
Description=Rclone Encrypted Backup
After=network-online.target
[Service]
Type=oneshot
User=backup
EnvironmentFile=/etc/rclone/backup.env
ExecStart=/usr/local/bin/mysql-backup-encrypted.sh
[Install]
WantedBy=multi-user.target
# /etc/rclone/backup.env - Bu dosyayı da koru!
chmod 600 /etc/rclone/backup.env
cat > /etc/rclone/backup.env << 'EOF'
RCLONE_CONFIG_PASS=MasterConfigSifresi
EOF
Yedekleri Test Etmek: Restore Prosedürü
Yedek aldın güzel, peki geri yükleyebiliyor musun? Bunu düzenli test etmezsen yedekten haberin olmaz. Basit bir restore testi:
#!/bin/bash
# /usr/local/bin/backup-restore-test.sh
RESTORE_DIR="/tmp/restore-test-$(date +%Y%m%d)"
REMOTE_PATH="b2-encrypted:mysql-backups"
mkdir -p "$RESTORE_DIR"
# Son yedeği bul ve indir
LATEST=$(rclone ls "$REMOTE_PATH/" | sort | tail -1 | awk '{print $2}')
echo "Son yedek: $LATEST"
rclone copy "${REMOTE_PATH}/${LATEST}" "$RESTORE_DIR/"
# Dosya bütünlüğünü kontrol et
if file "${RESTORE_DIR}/${LATEST}" | grep -q "gzip"; then
echo "BASARILI: Dosya gecerli bir gzip arsivi."
# MySQL'e yuklemeden once icerik kontrolu
zcat "${RESTORE_DIR}/${LATEST}" | head -20
else
echo "HATA: Dosya bozuk veya sifre yanlis!"
exit 1
fi
# Test klasorunu temizle
rm -rf "$RESTORE_DIR"
echo "Restore testi tamamlandi."
Bu scripti haftada bir çalıştırmak iyi bir uygulama. Alarm sisteminle entegre edip başarısız restore testlerinde bildirim gönderilmesini de sağlayabilirsin.
Bant Genişliği ve Performans Optimizasyonu
Büyük yedekler için bant genişliğini kontrol altında tutmak önemli. Özellikle gün içinde upload yapman gerekiyorsa:
# Bant genişliğini sınırla (upload: 10 MB/s)
rclone copy
--bwlimit="10M:off"
--transfers=4
--buffer-size=256M
--multi-thread-streams=4
/var/backups b2-encrypted:
# Çalışma saatleri için farklı limit (gündüz yavaş, gece hızlı)
rclone copy
--bwlimit="08:00,5M 20:00,off"
/var/backups b2-encrypted:
Büyük dosyalar için chunk upload’u aktif etmek de performansı ciddi artırır:
# B2 için chunk boyutunu ayarla
# rclone.conf içinde b2-main remote'una ekle:
# chunk_size = 96M
# upload_cutoff = 200M
rclone copy
--b2-chunk-size=96M
--b2-upload-cutoff=200M
/var/backups/large-db-dump.sql.gz
b2-encrypted:db-backups/
Şifre Yönetimi ve Felaket Senaryosu
Crypt şifresini kaybetmek tam anlamıyla bir felaket. Yedekleriniz var ama açamıyorsunuz. Bu durumu önlemek için:
Şifre saklama stratejisi:
- Şifreleri bir parola yöneticisinde sakla (Bitwarden, 1Password, KeePass)
- Şirket içi bir güvenli not sistemine de yaz (ofis kasası, fiziksel kağıt)
- Config dosyasının kendisini de şifreli olarak farklı bir konumda yedekle
# Config dosyasını kendisi de yedekle (farklı bir yere)
# Dikkat: Bu dosya şifreli olmalı!
gpg --symmetric --cipher-algo AES256
~/.config/rclone/rclone.conf
# Şifreli config'i güvenli bir yere at
scp rclone.conf.gpg backup-admin@offsite-server:/secure-vault/
Şifre rotasyonu: Crypt şifresini değiştirmenin tek yolu tüm dosyaları yeni şifreyle tekrar yüklemek. Bu yüzden şifre rotasyonunu çok nadiren yapmalı ve yaparsan tüm süreç için plan yapmalısın.
Monitoring ve Alerting
Yedeklerinizin durumunu izlemek için basit bir kontrol scripti:
#!/bin/bash
# /usr/local/bin/backup-health-check.sh
REMOTE_PATH="b2-encrypted:mysql-backups"
MAX_AGE_HOURS=26 # 24 saat + 2 saat tolerans
ALERT_EMAIL="[email protected]"
# Son yedeğin tarihini kontrol et
LAST_BACKUP_DATE=$(rclone ls "$REMOTE_PATH/"
2>/dev/null |
sort | tail -1 | awk '{print $2}' |
grep -oP 'd{8}')
if [ -z "$LAST_BACKUP_DATE" ]; then
echo "KRITIK: Hic yedek bulunamadi!" |
mail -s "[ALERT] Backup Missing" "$ALERT_EMAIL"
exit 1
fi
# Kaç saat önce alındığını hesapla
BACKUP_EPOCH=$(date -d "${LAST_BACKUP_DATE}" +%s)
CURRENT_EPOCH=$(date +%s)
DIFF_HOURS=$(( (CURRENT_EPOCH - BACKUP_EPOCH) / 3600 ))
if [ "$DIFF_HOURS" -gt "$MAX_AGE_HOURS" ]; then
echo "UYARI: Son yedek ${DIFF_HOURS} saat once alindi!" |
mail -s "[ALERT] Backup Stale" "$ALERT_EMAIL"
exit 1
fi
echo "OK: Son yedek ${DIFF_HOURS} saat once alindi."
Bunu da cron’a ekle:
# Her sabah 08:00'de yedek yaşını kontrol et
echo "0 8 * * * root /usr/local/bin/backup-health-check.sh" >> /etc/cron.d/backup-check
Sık Karşılaşılan Sorunlar
“Failed to decrypt” hatası: Büyük ihtimalle yanlış şifre ya da yanlış remote kullanıyorsun. Config dosyasındaki password ve password2 değerlerini kontrol et.
Dosya listeleme çalışıyor ama download yavaş: --transfers değerini artır, aynı zamanda --checkers parametresini de yükselt.
Config şifresi sonrası “no auth info” hatası: RCLONE_CONFIG_PASS environment variable set edilmemiş. Script başına export RCLONE_CONFIG_PASS=... ekle veya EnvironmentFile kullan.
B2’de görünen dosya boyutu yerel boyuttan büyük: Normal. Şifreleme overheadi yaklaşık dosya başına 32 byte + her 64KB chunk için 16 byte. Büyük dosyalarda fark minimum.
Sonuç
Rclone Crypt, bulut yedekleme için gerçekten sağlam ve esnek bir çözüm sunuyor. Yapılandırması birkaç adımdan ibaret ama dikkat edilmesi gereken noktalar var: şifrelerin güvenli saklanması, config dosyasının korunması ve yedeklerin düzenli olarak restore testi yapılması.
Özetle dikkat etmen gereken ana noktalar şunlar:
- Şifrelerini kaybet, yedeklerini kaybet: Crypt şifreleri için mutlaka çoklu yedek sakla.
- Hem içerik hem dosya adı şifrelemesini aç:
standardfilename encryption kullan. - Config dosyasını da şifrele:
rclone configüzerinden master şifre ekle. - Restore testlerini otomatikleştir: Haftada bir test çalıştıran script kur.
- Bant genişliği limitlerini ayarla: Üretim trafiğini etkilememek için
--bwlimitkullan.
Bu yapılandırmayla gece uyurken bulut hesabına erişen biri verilerini göremez, sağlayıcının çalışanları dosyalarına bakamaz ve olası bir veri ihlalinde şifreli blob’lardan bir şey çıkaramazlar. Bu seviyede bir güvenlik, birkaç saatlik kurulum için oldukça değerli bir yatırım.
