rclone ile S3/Backblaze B2 Yedek Senkronizasyonu: SSE, Lifecycle ve Glacier ile Masrafı Nasıl Tatlı Tatlı Düşürürüz?

Bir Fatura, Bir Ders: Yedekler Nereye Koşuyor?

Hiç öyle bulanık bir pazartesi sabahı, kahveni alıp masaya oturmuşken bir anda gelen depolama faturasıyla irkilip, “Ben bu kadar veri mi tuttum?” diye düşündün mü? Ben düşündüm. O gün, yedeklerin sadece diskte değil, akılda da bir stratejiye ihtiyaç duyduğunu hatırladım. Çünkü yedek almak tek başına kahramanlık sayılmıyor; neyi, nereye, ne kadar süreyle, hangi şifrelemeyle ve hangi sınıfta tuttuğun, işin asıl masalsı kısmı.

İşte burada rclone devreye giriyor. S3 ve Backblaze B2 gibi bulut depolama servislerine, sanki elinde bir dümen varmış gibi seri ve güvenli şekilde evrak taşıyorsun. Araya SSE ile sunucu tarafı şifreleme serpiştiriyorsun, lifecycle kuralları ekleyip yaşlanan veriyi soğuk bölgelere gönderiyorsun, gerektiğinde S3’te Glacier’e yatırıyorsun. Hepsi bir ritim tutturunca, masraf grafiği aşağı doğru süzülüyor. Bu yazıda, pratik komutlarla, örneklerle ve “gerçekten böyle olabiliyor mu?” diyeceğin küçük ipuçlarıyla bu ritmi birlikte kuracağız.

Neyi, Nereye ve Neden? Stratejinin İskeleti

Önce niyet. Günlük yedekler nerede dursun, aylık arşivler nereye insin, kritik dosyalar ne kadar süre saklansın? Mesela şöyle düşün: Uygulamanın günlük dosyalarını ve medyalarını S3’te sıcak tut, 30 günü aşanları kademeli şekilde soğut, üç ayı geçenleri Glacier’e park et. B2 tarafında da eski versiyonları belirli bir sürede temizle, sadece ay sonu anlık görüntülerini sakla. Kulağa düzen gibi geliyor, değil mi?

Sonra güvenlik. Asla çıplak veriyi dışarı göndermemek, en azından sunucu tarafında bir perde kullanmak, yani SSE. Yetmiyorsa uçtan uca şifreleme için rclone’un crypt uzantısını düşün. Erişim anahtarlarını da gereksiz geniş tutma; hem S3 hem B2 tarafında sadece gerekli izinleri ver, bir klasörün dışına taşmasınlar.

Ve en sevdiğimiz kısım: maliyet. Küçük dosyaların sayısı arttıkça API çağrıları şişer. Bazen büyük bir arşiv dosyası oluşturup akıtmak daha tatlıdır. Bazense doğrudan senkron iyi çalışır. İşin sihri, senin verinin doğasına göre denge kurmakta.

rclone ile İlk Temas: S3 ve B2 Uzaktan Bağlantıları

Ortam değişkenleriyle temiz bir başlangıç

Hesap anahtarlarını dosyaya yaymak yerine ortam değişkenleriyle beslemek hem pratik hem tertipli. Küçük bir örnek bırakayım.

# S3 (AWS uyumlu) için
export AWS_ACCESS_KEY_ID="AKI..."
export AWS_SECRET_ACCESS_KEY="..."

# Backblaze B2 için
export B2_ACCOUNT_ID="..."
export B2_ACCOUNT_KEY="..."

Uzakları adlandırmak: Sadelik iyidir

rclone’da her hedeften önce ona bir isim veriyoruz. Basit, akılda kalıcı, mümkünse ortamı da anlatan bir ad seç. “backup-s3” ve “backup-b2” gibi.

# S3 remotesi (SSE: AES256 örnek)
rclone config create backup-s3 s3 
  provider AWS 
  region eu-central-1 
  acl private 
  server_side_encryption AES256

# B2 remotesi
rclone config create backup-b2 b2 
  hard_delete true

Burada S3 için SSE’yi remotenin varsayılanı yaptık. B2 için de “hard delete” seçeneğiyle gerçekten silinsin mi, versiyonlama mı? kararını bilerek veriyorsun. Versiyonlamayı açık tutacaksan hard delete’i kapatmak daha uygun olur.

İlk senkron: Küçük bir prova

Elinde yerel bir klasör var: “/srv/backups”. Bunu S3’e akıtalım. Basit ama iş gören bir komut şöyle:

rclone sync /srv/backups backup-s3:mybucket/prod 
  --checksum 
  --fast-list 
  --transfers 8 
  --checkers 16 
  --s3-chunk-size 64M 
  --progress

Senin dosyaların çok küçükse aktarımları artırmak işine yarayabilir; çok büyük dosyalar içinse parça boyutunu büyütmek süreklilik sağlar. Hemen ardından bir kontrol de ekleyelim:

rclone check /srv/backups backup-s3:mybucket/prod --one-way --size-only

Burada checksum yerine boyuttan kontrol ettik; çok sayıda dosyada hız kazanırsın. Önemli olan, bir standarda bağlayıp düzenli tekrar etmek.

SSE Neden Önemli? S3’te, B2’de Nasıl Açılır?

Sunucu tarafı şifreleme, veriyi depoda şifreli tutar. Sen veriyi gönderdikten sonra servis sağlayıcı anahtarı kendi tarafında yönetir. Bu sayede “çimde unuttum” diye üzülmezsin. S3’te iki pratik yol var: sağlayıcının anahtarını kullanmak (AES256) ya da yönetilen bir anahtar servisiyle idare etmek (KMS). İkisi de işini görür; güvenlik politikana göre seçersin.

# S3'te komut bazında SSE'yi zorlamak
rclone copy /srv/dumps/db.sql.zst backup-s3:mybucket/prod/db 
  --s3-server-side-encryption AES256

# KMS kullanacaksan örnek (KMS anahtar kimliği gerektirir)
rclone copy /srv/secrets.tar backup-s3:mybucket/prod/secure 
  --s3-server-side-encryption aws:kms 
  --s3-sse-kms-key-id "arn:aws:kms:...:key/xxxx"

Backblaze B2 tarafında da sunucu tarafı şifreleme seçenekleri bulunuyor. Genelde kovayı oluştururken veya hesap ayarlarında varsayılanı tanımlarsın, rclone tarafında da uzaktan ayara ekleyebilirsin. Net olan şu: şifrelemeyi bir defa alışkanlık haline getirince, yedeklerin içini çok daha rahat eder şekilde uyursun.

Konu derinleşsin istersen, rclone S3 seçenekleri sayfasına ara sıra göz atmak iyi gelir; seçenek isimleri ve küçük nüanslar orada taptaze durur.

Lifecycle Dokunuşu ve Glacier’e Giden Yol

Yedeklerin çoğu ilk gün çok değerli, onuncu gün hâlâ önemli, doksanıncı gün ise artık arşiv. İşte lifecycle burada hayat kurtarıyor. S3 tarafında “30 günden sonra daha soğuk sınıfa indir, 90 günde Glacier’e koy, 365’te sil” gibi kurallar kibarca iş görür. Arada “glacier’e taşınan dosyayı sildiğimde versiyonunu şu kadar süre daha sakla” diyerek ince ayar da yapılabilir.

Örnek bir S3 Lifecycle politikası; konsoldan da yapılır, kodla da. Mantık anlaşılır olsun diye sadeleştirdim:

{
  "Rules": [
    {
      "ID": "prod-logs",
      "Filter": { "Prefix": "prod/logs/" },
      "Status": "Enabled",
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER" }
      ],
      "Expiration": { "Days": 365 }
    }
  ]
}

Backblaze B2’de yaklaşım biraz farklı. B2’nin güçlü yanı, dosya versiyonlarını ve saklama politikasını basitçe yönetebilmen. “30 günden eski versiyonları sil, sadece son versiyonu tut” gibi kurallarla masrafını kontrol edersin. Dilersen ay sonunda oluşturduğun büyük arşivleri aylarca tutar, günlük küçükleri çabuk temizlersin. Detay için Backblaze B2 lifecycle kuralları sayfasına göz atman pratik olur.

Depolama sınıfları ve arşiv tarafında, S3’in resmî anlatımı da elinin altında olsun istersen, S3 depolama sınıfları ve Glacier yazısı akılda kalan bir özet sunuyor.

Pratik rclone Komutları ve Küçük Sihirler

Sync mi, Copy mi, rcat mi?

“sync” yerel ile uzak hedefi aynı hale getirir; yerelde silinen dosya uzak taraftan da uçar. Bu güzel ama risklidir. “copy” ise sadece ekler/günceller, silmez. İlk kurduğun akışlarda “copy” daha güvenlidir; senkrona sonra geçersin. “rcat” ise favorilerimden: bir akışı doğrudan uzak tarafa boru gibi dökersin, dosyayı diske yazmadan.

# Sadece ekle/güncelle
rclone copy /srv/media backup-b2:site-media/prod 
  --transfers 16 --checkers 32 --fast-list --progress

# Borudan akıt: büyük arşivleri diske yazmadan Gönder
sudo tar -I 'zstd -19 --long=31' -cf - /var/www 
 | rclone rcat backup-s3:mybucket/prod/archives/site-$(date +%F).tar.zst

Filtrelemek: Her şeyi taşımak zorunda değilsin

Yedeklerde gereksiz dosyalar çabuk şişirir. Örneğin “node_modules” ya da geçici cache’leri taşımayabilirsin. rclone’un dahil/hariç filtreleri hayat kurtarır.

rclone sync /srv/app backup-s3:mybucket/prod/app 
  --exclude ".cache/**" 
  --exclude "node_modules/**" 
  --exclude "*.tmp" 
  --progress

Hız ayarı: Trafiği nazikçe kullan

Geceleri daha hızlı, gündüzleri nazik çalışmak isteyebilirsin. Bant genişliği sınırlamak bazen komşunu, bazen sunucunu korur.

# 22:00-06:00 arasında 0.5Gbit/s, diğer zamanlarda 50Mbit/s
rclone sync /srv/backups backup-b2:team/prod 
  --bwlimit "22:00,500M 06:00,50M" 
  --progress

Doğrulama: Güven iyidir, check daha iyi

Arada bir “check” çalıştırmak rahatlatır. Özellikle büyük temizliklerden sonra.

rclone check backup-s3:mybucket/prod backup-b2:myreplica/prod --one-way

Böylece S3’te olanın B2 tarafında da göründüğünü, en azından boyut ve varsa imzalarla teyit etmiş olursun.

Masrafı Düşürmenin Günlük Halleri

İşin sırrı küçük alışkanlıklarda. Birincisi, gereksiz sürümleri hızlıca süpürmek. Günde onlarca küçük sürüm tutmak yerine, saatlikleri kısa, günlükleri orta, aylıkları uzun saklamak masrafı inceltir. İkincisi, küçük dosya selini bir arşivde toplayıp akıtmak; API çağrısı sayısı ve meta veri maliyeti düşer. Üçüncüsü, S3’te sınıf geçişlerini cesurca kurgulamak; sık bakmadığın veriyi ısrarla sıcak elde tutmanın anlamı yok.

Dördüncüsü, yeniden indirme ihtiyacını azaltan bir katalog düzeni kurmak. Dizin yapını “prod/ay/yıl/gün” gibi insanın bakınca anladığı bir düzende kurgula. Beşincisi, kimlerin eriştiğini bilmek ve günlükleri arada bir gözden geçirmek; gereksiz bölgelere ödediğin trafik ücreti gözünün ucundan kaçmasın.

Ve elbette, deneme. Bir hafta daha büyük parça boyutu, bir hafta daha küçük; bir hafta daha fazla eşzamanlı aktarım, sonra tam tersi. Senin verin nasıl akmak istiyorsa en iyi cevabı o söylüyor.

Kurtarma Provası: Dosyayı Geri Almak, Sistemi Ayağa Kaldırmak

Yedek almak kadar geri dönebildiğini görmek de önemli. Bunun için küçük ritüeller belirle. Ayda bir, rastgele bir dosyayı indir ve aç. Üç ayda bir, ciddi bir geri dönüş simülasyonu yap. Bir WordPress arşivini indir, başka bir klasöre aç, “çalışıyor mu?” sorusunun cevabını kendin duy.

# Seçili klasörü geri getir
rclone copy backup-s3:mybucket/prod/archives/site-2024-11-01.tar.zst /restore/

# Sadece logları indir
rclone copy backup-b2:team/prod/logs /var/tmp/restore-logs 
  --include "*.log" 
  --max-age 30d

Planı yazıya dökmek, ekibin birlikte prova yapmasıyla anlam kazanır. Burada şu yazı, düşünceyi derli toplu hale getirmekte iyi bir yoldaş: felaket kurtarma planı ve RTO/RPO’yu netleştirmek. Okurken bir iki “kendi işime nasıl uyarlarım?” notu düşersen sonraki provada meyvesini görürsün.

Otomasyon: Cron, systemd ve Sağlık Kontrolleri

Elle çalıştırılan yedek, en iyi ihtimalle bugün vardır; yarın kalmayabilir. Otomasyon bu yüzden var. Basit bir cron satırıyla işe başlamak her zaman mümkün.

# Her gece 02:15'te S3'e senkron
15 2 * * * /usr/bin/rclone sync /srv/backups backup-s3:mybucket/prod 
  --fast-list --checksum --log-level INFO 
  --log-file /var/log/rclone-backup-s3.log

systemd sevenlere ufak bir iskelet:

# /etc/systemd/system/rclone-backup.service
[Unit]
Description=Rclone backup to S3

[Service]
Type=oneshot
EnvironmentFile=/etc/default/rclone-backup
ExecStart=/usr/bin/rclone sync /srv/backups backup-s3:mybucket/prod 
  --checksum --fast-list --log-level INFO 
  --log-file /var/log/rclone-backup-s3.log

# /etc/systemd/system/rclone-backup.timer
[Unit]
Description=Nightly rclone backup

[Timer]
OnCalendar=*-*-* 02:15:00
Persistent=true

[Install]
WantedBy=timers.target

Bir de sağlık sinyali alışkanlığı ekleyebilirsin: İş bittiğinde küçük bir HTTP çağrısı atmak, grafikte yeşil bir tik görmek iyi gelir. Logları döngüsel tutup arada “ERROR” taraması yapmak da minik bir cankurtaran.

Altyapıyı kodla yönetiyorsan, yedek kovalarını ve kurallarını da kodda tutmak huzur verir. İlham arıyorsan, şu yazı fikir verir: Terraform ile VPS ve DNS otomasyonu. Aynı zihniyetle S3 Lifecycle, IAM kullanıcıları ve B2 kovaları da tekrar üretilebilir olur.

Güvenlik: Anahtarlar, İzinler ve Sınırlar

Yedek anahtarları, şifresiz hazine gibidir. En az yetki kuralını benimse. S3 için sadece “list, put, get” gibi gerekli izni ver, kovayı ve mümkünse alt yol ön ekiyle sınırla. B2’de uygulama anahtarını tek bir kovayla ve belirli bir önekle kilitle, süresini de kısıtla. Ortam değişkenlerini sadece yedek kullanıcısına görünür kıl, loglarda sızdırma.

İkinci adım, şifreleme disiplinini bırakmamak. SSE’yi varsayılan yap, özel dosyalarda daha sıkı bir anahtar yönetimi uygula. Uçtan uca isteyenler için rclone crypt bir seçenek; ama anahtarların güvenli saklanması, yedeklerin erişilebilirliğinden daha önemli hale gelebilir. Dengeyi senin güvenlik gereksinimin belirlesin.

Son olarak, iz sürme. Hangi işlemler ne zaman yapılmış bilmek, sorun olduğunda hem süreci hem de güvenliği hızlıca toparlamanı sağlar.

Gerçek Dünya: WordPress ve PostgreSQL ile Küçük Senaryolar

WordPress dosyaları ve medya arşivleri

WordPress’i konteynerlerle çalıştırıyor olabilirsin. Dosyaları sık sık oynar, medya klasörü büyür. Dosyayı değil akışı yedeklemek istediğin günlerde şu tarz bir boru pek tatlıdır:

cd /var/lib/docker/volumes/wp_data/_data
sudo tar -I 'zstd -19 --long=31' -cf - . 
 | rclone rcat backup-b2:site-media/prod/archives/wp-$(date +%F).tar.zst

Uygulamanın nasıl kurulduğuna dair akışları seviyorsan, bu yazı hoşuna gidebilir: Docker Compose ile WordPress’i tatlı tatlı yedeklemek. Oradaki hacim mantığını bu yazının rclone akışlarıyla evlendirince, her gece uykun daha rahat olur.

PostgreSQL: WAL akarken güvenli bir liman

Veritabanında en sevdiğim yaklaşım, günlük tam yedek + ara adımlarda sürekli WAL arşivlemek. Günlük yedeği sıkı sıkıya bir arşive al, sonra rclone ile uzak depoya taşı. Ayrıntılarıyla bir yol haritası arıyorsan, şu kaynak çok iş görüyor: pgBackRest ile WAL arşivleme. Oradaki akışı B2’ye ya da S3’e akıtmak için, bu yazıdaki rclone parçalarını ufak oynamalarla yerleştirmek yeterli.

Sunucuyu baştan kurmak gerektiğinde

Bir gün sıfırlamak gerekirse, yedekleri indirip servisleri ayağa kaldırmak kadar, altyapıyı da hızlı kurabilmek önemli. Ben genelde sunucu kurulumunu tekrar üretilebilir tutmayı seviyorum. Bu yolda fikir veren iki dost daha var: cloud-init ve Ansible ile tekrar üretilebilir VPS ve az önce paylaştığım otomasyon yazısı. Yedek + otomasyon ikilisi, felaket gününde bir anda en yakın arkadaşına dönüşüyor.

Kapanış: Akış Kurulduğunda Sessizce Çalışır

Bir yedek, bir komut, sonra bir diğeri… derken ortaya akan bir nehir çıkıyor. rclone ile S3/Backblaze B2 yedek senkronizasyonu, ilk bakışta “komut ezberleme” işi gibi görünse de, aslında düzen kurma sanatı. SSE ile veriyi içeride güvene alıyorsun, lifecycle ile yaşlanan veriyi nazikçe kenara alıyorsun, Glacier’e inen uzun uykularda masraf sakinleşiyor. B2’de de versiyon politikasını iyi kurunca, gereksiz yükleri hızlıca atıyorsun.

Pratik bir kapanış listesi bırakayım, ama cümleler halinde: Önce küçük bir klasörle başla, copy ile akıt; sonra check ile doğrula. SSE’yi varsayılana çek; lifecycle’ı yazıya döküp kovaya uygula. Bir gece senkronu, bir de haftalık büyük arşivi rutine bağla. Ayda bir geri dönüş provası yap; bir dosyayı indir aç, bir sistemi sandbox’ta ayağa kaldır. Anahtarları dar izinde tut; logları kısa aralıklarla kokla. Ve akışı sev; akış oturunca gündeminden kendiliğinden düşer.

Umarım bu yazı yedek yolculuğunda iyi bir eşlikçi olmuştur. Eğer tüm bu akışı, daha geniş bir iş sürekliliği hikayesine bağlamak istersen, şu yazı çok güzel tamamlar: felaket kurtarma planı ve RTO/RPO’yu netleştirmek. Soruların olursa, notlarını topla; bir sonraki yazıda onları konuşalım. Görüşmek üzere.