Bulut Depolama Alanına Doğrudan Arşiv Yükleme: rclone ve tar ile S3, Google Drive ve OneDrive Entegrasyonu

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

Disklerin dolduğu anlarda, backup scriptlerinin ortasında “no space left on device” hatası aldığınızda, ya da sabah 3’te uyandırılan birinin ilk refleksinin “neden doğrudan buluta yazmıyoruz ki?” olduğu anlarda bu yazı doğdu. Yıllarca önce diskte yer ayırıp oraya arşivler, sonra o arşivleri buluta taşırdık. İki adımlık bu süreç hem zaman kaybettiriyor hem de geçici disk alanı gerektiriyordu. Bugün bunun yerine tar ve rclone‘u birleştirerek doğrudan bulut depolama alanına arşiv yazabiliyoruz. S3, Google Drive, OneDrive fark etmez.

rclone Nedir, Neden tar ile Beraber Kullanıyoruz?

rclone, bulut depolama servislerine dosya transferi için yazılmış, Go dilinde geliştirilmiş bir araç. Ama bunu sadece “bulut için rsync” olarak tanımlamak haksızlık olur. rclone‘un bizi ilgilendiren kısmı, rcat modunu desteklemesi: standart girişten (stdin) veri okuyup doğrudan buluta yazabiliyor.

tar ise zaten pipeline’larla çalışmak için tasarlanmış. -f - parametresiyle standart çıkışa yazıyor. Bu ikisini | ile bağladığınızda, disk üzerinde hiç geçici dosya oluşturmadan doğrudan buluta arşiv yazabiliyorsunuz.

Temel mantık şu:

tar czf - /kaynak/dizin | rclone rcat remote:bucket/arsiv.tar.gz

Basit görünüyor, ama içinde çözülmesi gereken birkaç nüans var. Onlara sırayla geleceğiz.

rclone Kurulumu ve Yapılandırması

Önce araçları yerli yerine koyalım. rclone‘u doğrudan resmi script ile kurmak en güvenilir yöntem:

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

Ya da paket yöneticinizden:

# Debian/Ubuntu
sudo apt install rclone

# RHEL/CentOS/Rocky
sudo dnf install rclone

# Arch
sudo pacman -S rclone

Kurulum sonrası yapılandırma için rclone config komutunu çalıştırıyorsunuz. Bu interaktif bir wizard başlatıyor. S3 için AWS credentials, Google Drive için OAuth, OneDrive için de benzer bir akış. Burada dikkat edilmesi gereken nokta: headless sunucularda OAuth akışını tamamlamak için --auth-no-browser flag’ini kullanmanız veya başka bir makinede token alıp transfer etmeniz gerekebilir.

S3 Yapılandırması

AWS S3 için yapılandırma dosyası şu formatta olur (~/.config/rclone/rclone.conf):

[s3-prod]
type = s3
provider = AWS
access_key_id = AKIAIOSFODNN7EXAMPLE
secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
region = eu-west-1

Bu yapılandırmayı elle yazabilirsiniz ya da rclone config ile oluşturabilirsiniz. IAM role kullanıyorsanız, EC2 instance üzerinde access_key_id ve secret_access_key boş bırakabilirsiniz, rclone instance metadata’yı otomatik kullanır.

Yapılandırmayı test etmek için:

rclone ls s3-prod:benim-bucket-adim/

Temel Kullanım: tar’dan rclone’a Stream

Şimdi asıl konuya gelelim. En temel formda bir dizini sıkıştırarak S3’e yazmak:

tar czf - /var/www/html | rclone rcat s3-prod:benim-bucket/html-$(date +%Y%m%d).tar.gz

Burada - ifadesi tar’a “dosyaya değil, stdout’a yaz” diyor. rclone rcat ise stdin’den okuyup belirtilen hedefe yazıyor. $(date +%Y%m%d) ile tarih bazlı isimlendirme yapıyoruz.

Sadece belirli dosyaları dahil etmek veya hariç tutmak için tar’ın --exclude parametresi hala geçerli:

tar czf - 
  --exclude='/var/www/html/cache' 
  --exclude='/var/www/html/tmp' 
  --exclude='*.log' 
  /var/www/html | rclone rcat s3-prod:benim-bucket/html-$(date +%Y%m%d).tar.gz

Google Drive Entegrasyonu

Google Drive için önce rclone config ile bir remote oluşturmanız gerekiyor. Yapılandırma dosyasında şuna benzer bir blok oluşur:

[gdrive]
type = drive
client_id = 123456789-abcdef.apps.googleusercontent.com
client_secret = GOCSPX-xxxxxxxxxxx
scope = drive
token = {"access_token":"...","token_type":"Bearer",...}

Token kısmı OAuth akışı tamamlandığında otomatik doluyor. Headless sunucularda bu adımı yerel makinenizde yapıp conf dosyasını sunucuya kopyalamanız daha pratik.

Google Drive’a arşiv yazmak:

tar czf - /home/kullanici/projeler | rclone rcat gdrive:Backups/projeler-$(date +%Y%m%d-%H%M).tar.gz

Google Drive’da dikkat edilmesi gereken bir nokta: rcat ile yüklenen dosyalar büyük boyutlarda otomatik olarak chunk’lara bölünüyor. Bu tamamen arka planda halloluyor ama büyük dosyalarda --drive-chunk-size parametresi ile chunk boyutunu artırmak transfer hızını iyileştirebilir:

tar czf - /veri/buyuk-dizin | rclone rcat --drive-chunk-size 128M gdrive:Backups/buyuk-arsiv.tar.gz

OneDrive Entegrasyonu

Microsoft OneDrive için yapılandırma:

[onedrive]
type = onedrive
client_id = xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
client_secret = xxxxxxxxxxxxxxxxxx
token = {"access_token":"..."}
drive_id = b!xxxxxxxxxxxxxxxxxxxxxxxxx
drive_type = personal

OneDrive’a yazma işlemi aynı pattern’i takip ediyor:

tar czf - /etc | rclone rcat onedrive:Backups/etc-$(date +%Y%m%d).tar.gz

OneDrive’ın API limitleri zaman zaman sorun çıkarabiliyor. Büyük dosyalarda --onedrive-chunk-size parametresi ve --transfers sayısını ayarlamak gerekebilir. Ama rcat tek bir stream olduğu için --transfers burada direkt etkili değil, daha çok rclone copy kullanımları için geçerli.

Bant Genişliği Kontrolü ve Transfer Optimizasyonu

Production sunucularında bu işlemi çalıştırırken ağ bant genişliğini kontrol altında tutmak önemli. rclone‘un --bwlimit parametresi tam burada devreye giriyor:

tar czf - /var/lib/mysql | rclone rcat --bwlimit 50M s3-prod:db-backups/mysql-$(date +%Y%m%d).tar.gz

Bu komut transfer hızını 50 MB/s ile sınırlıyor. Bant genişliği limitini zaman dilimine göre de ayarlayabilirsiniz:

# Gündüz 10MB/s, gece 100MB/s
--bwlimit "08:00,10M 00:00,100M"

Büyük arşivlerde pv aracını pipeline’a ekleyerek ilerlemeyi görebilirsiniz:

tar czf - /veri/buyuk-dizin | pv | rclone rcat s3-prod:backups/buyuk-arsiv.tar.gz

pv yüklü değilse:

sudo apt install pv  # Debian/Ubuntu
sudo dnf install pv  # RHEL tabanlı

Paralel Sıkıştırma ile Hız Artırımı: pigz

gzip tek çekirdek kullanır. Çok çekirdekli sunucularda sıkıştırma bottleneck haline gelebilir. pigz (parallel gzip) bu sorunu çözer:

tar cf - /veri/buyuk-dizin | pigz -p 4 | rclone rcat s3-prod:backups/buyuk-paralel.tar.gz

-p 4 ile 4 çekirdek kullanıyoruz. Sunucunuzun çekirdek sayısına göre bu değeri ayarlayın. pigz‘i kurmak için:

sudo apt install pigz   # Debian/Ubuntu
sudo dnf install pigz   # RHEL tabanlı

Benzer şekilde pbzip2 de paralel bzip2 sıkıştırması yapıyor, lbzip2 ise aynı işin başka bir implementasyonu.

Şifreleme Eklemek: gpg ile Güvenli Arşiv

Hassas verileri buluta yüklerken şifreleme şart. gpg ile pipeline’a şifreleme katmanı ekleyebilirsiniz:

tar czf - /var/lib/mysql | 
  gpg --batch --yes --passphrase-file /root/.backup-passphrase -c | 
  rclone rcat s3-prod:secure-backups/mysql-$(date +%Y%m%d).tar.gz.gpg

Passphrase’i bir dosyada tutmak (/root/.backup-passphrase) ve bu dosyanın izinlerini 600 yapmak iyi pratik:

chmod 600 /root/.backup-passphrase

Public key şifrelemesi için:

tar czf - /hassas/veri | 
  gpg --batch --recipient [email protected] --encrypt | 
  rclone rcat s3-prod:secure-backups/hassas-$(date +%Y%m%d).tar.gz.gpg

Gerçek Dünya Senaryosu 1: MySQL Backup Scripti

Üretim ortamında kullandığımız bir MySQL backup script’inin sadeleştirilmiş hali:

#!/bin/bash

set -euo pipefail

DB_NAME="uretim_db"
REMOTE="s3-prod"
BUCKET="sirket-backups"
DATE=$(date +%Y%m%d-%H%M%S)
BACKUP_FILE="mysql/${DB_NAME}-${DATE}.sql.gz.gpg"
LOG_FILE="/var/log/backup/mysql-$(date +%Y%m%d).log"

echo "[$(date)] Backup basliyor: ${DB_NAME}" >> "${LOG_FILE}"

mysqldump 
  --single-transaction 
  --routines 
  --triggers 
  --hex-blob 
  "${DB_NAME}" | 
  gzip | 
  gpg --batch --yes --passphrase-file /root/.backup-passphrase -c | 
  rclone rcat --bwlimit 80M "${REMOTE}:${BUCKET}/${BACKUP_FILE}"

if [ $? -eq 0 ]; then
  echo "[$(date)] Backup tamamlandi: ${BACKUP_FILE}" >> "${LOG_FILE}"
else
  echo "[$(date)] HATA: Backup basarisiz!" >> "${LOG_FILE}"
  exit 1
fi

# 30 gunden eski backuplari temizle
rclone delete --min-age 30d "${REMOTE}:${BUCKET}/mysql/"

Bu script’te set -euo pipefail kritik. Pipeline’ın herhangi bir aşamasında hata olursa script durduruluyor. Bu olmadan gzip hata verse bile script devam edebilir ve bozuk bir dosyayı başarılı gibi işaretleyebilir.

Gerçek Dünya Senaryosu 2: Çoklu Dizin, Tek Arşiv

Bazen birden fazla dizini tek arşivde toplamak gerekiyor:

#!/bin/bash

REMOTE="gdrive"
DATE=$(date +%Y%m%d)

tar czf - 
  --exclude='/etc/ssl/private' 
  /etc 
  /home 
  /var/spool/cron 
  /root/.ssh | 
  rclone rcat 
    --drive-chunk-size 64M 
    "${REMOTE}:ServerBackups/sistem-${DATE}.tar.gz"

echo "Tamamlandi: sistem-${DATE}.tar.gz"

Gerçek Dünya Senaryosu 3: Uygulama + Veritabanı Birlikte

Docker ortamlarında uygulama verisi ve veritabanını birlikte yedeklemek yaygın ihtiyaç. Şöyle yapılabilir:

#!/bin/bash

REMOTE="s3-prod"
BUCKET="app-backups"
APP_NAME="eticaret"
DATE=$(date +%Y%m%d-%H%M)

# PostgreSQL dump + uygulama dosyaları birlikte
{
  echo "=== DB_DUMP_START ==="
  pg_dump -Fc "${APP_NAME}" | base64
  echo "=== DB_DUMP_END ==="
} | tar czf - 
  --add-file=/dev/stdin 
  /var/www/${APP_NAME}/uploads 
  /var/www/${APP_NAME}/config | 
  rclone rcat "${REMOTE}:${BUCKET}/${APP_NAME}-${DATE}.tar.gz"

Pratikte bu yaklaşım yerine çoğunlukla ayrı dosyalar halinde yedeklemek daha yönetilebilir olur, ama senaryoya göre değişiyor.

rclone’un Sağladığı Ekstra Özellikler

Checksum Doğrulama

Transfer sonrası rclone check ile veri bütünlüğünü doğrulayabilirsiniz. Ancak rcat ile doğrudan stream ettiğinizde yerel dosya olmadığı için bu doğrulama ancak buluttaki farklı kopyalar arasında yapılabilir.

Server-Side Şifreleme

S3 için transfer esnasında server-side şifreleme isteği ekleyebilirsiniz:

tar czf - /kritik/veri | 
  rclone rcat 
    --s3-server-side-encryption aws:kms 
    --s3-sse-kms-key-id arn:aws:kms:eu-west-1:123456789:key/mrk-abc123 
    s3-prod:kritik-bucket/veri-$(date +%Y%m%d).tar.gz

Storage Class Ayarı

S3 Glacier veya IA (Infrequent Access) sınıflarına doğrudan yazmak uzun vadeli arşivlerde ciddi maliyet avantajı sağlıyor:

tar czf - /arsiv/eski-veriler | 
  rclone rcat 
    --s3-storage-class STANDARD_IA 
    s3-prod:uzun-vadeli-arsiv/eski-$(date +%Y).tar.gz

Cron ile Otomatikleştirme

Script hazır olduğunda cron’a eklemek standart adım. Ama birkaç noktaya dikkat etmek gerekiyor:

# /etc/cron.d/cloud-backup
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# Her gece 02:30'da MySQL backup
30 2 * * * root /usr/local/bin/mysql-cloud-backup.sh 2>&1 | logger -t cloud-backup

# Her Pazar 03:00'da tam sistem backup
0 3 * * 0 root /usr/local/bin/sistem-cloud-backup.sh 2>&1 | logger -t cloud-backup

logger komutu ile cron çıktısını syslog’a yönlendiriyoruz. Bu sayede journalctl -t cloud-backup ile logları görebilirsiniz.

Cron ortamında rclone yapılandırma dosyasının konumu sorun olabilir. Cron farklı bir HOME kullanabilir. Bunu açıkça belirtmek en sağlıklısı:

rclone --config /root/.config/rclone/rclone.conf rcat s3-prod:bucket/dosya.tar.gz

Sorun Giderme: Yaygın Hatalar

“Failed to create file system” hatası: Genellikle yapılandırma sorunu. rclone config show ile remote’u kontrol edin.

Pipeline bozuk arşiv üretiyor: set -o pipefail eklendiğinden emin olun. Aksi halde upstream hata pipeline boyunca sıfır exit code ile iletilmeyebilir.

Transfer yarıda kesildi: Büyük dosyalarda --retries ve --retries-sleep parametreleri:

tar czf - /buyuk/dizin | 
  rclone rcat 
    --retries 3 
    --retries-sleep 10s 
    s3-prod:backups/buyuk-$(date +%Y%m%d).tar.gz

rcat ile boyut bilgisi yok: rcat stream boyutunu bilmediği için bazı servislerin ilerleme göstergesi çalışmayabilir. Bu beklenen bir durum.

Sonuç

Bu yaklaşımın gerçek değeri ne? Disk alanından bağımsız arşivleme yapabilmek. 500 GB veriyi yedeklemek için 500 GB geçici alana ihtiyaç duymak yok. Özellikle kısıtlı disk alanına sahip sanal makinelerde bu fark hayat kurtarıcı oluyor.

tar | rclone rcat kombinasyonu sadece bir komut hilesi değil, doğru araçları doğru şekilde birleştirmenin güzel bir örneği. Unix felsefesinin 2024’teki hali: her araç bir iş yapar, ve iyi yapar. tar paketler, gzip sıkıştırır, gpg şifreler, rclone transfer eder. Hepsi birbirine stdin/stdout üzerinden bağlanır.

S3, Google Drive ve OneDrive arasında syntax farkı minimal. Remote adı ve bucket/path değişiyor, geri kalan her şey aynı. Bu da scriptleri taşınabilir yapıyor: bugün S3 kullanan bir müşteri için yazdığınız script, yarın Google Drive kullanan bir diğeri için minimal değişiklikle çalışır.

Son olarak: backup’ı almak işin yarısı. Restore testini de yapın. rclone cat remote:bucket/arsiv.tar.gz | tar xzf - -C /tmp/restore-test/ ile arşivin açılabildiğini periyodik olarak doğrulamak, backup’ın gerçekten çalıştığını kanıtlamanın tek yolu.

Bir yanıt yazın

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