rclone ile S3 ve B2 Yedekleme: SSE ve Lifecycle

rclone ile yedek aktarımını ve saklama maliyetini planlamak

Yedekleme maliyeti; veri hacmi, sürüm sayısı, saklama süresi ve geri getirme sıklığının toplamıdır. rclone ile S3 ve Backblaze B2 yedekleme aktarımı ortak bir araçla yönetir; kaynak verinin tutarlılığını veya doğru saklama politikasını kendiliğinden sağlamaz.

Bu rehber AWS S3 ile rclone’un native B2 arka ucunu karşılaştırır. Kimlik bilgilerini bağlayacak, tamamlanmış yedekleri kopyalayacak, SSE ve yaşam döngüsü kurallarını değerlendirecek, Glacier’den geri getirme koşullarını ele alacağız. Komutlar GNU/Linux ve Bash içindir; rclone, arşiv örnekleri için ayrıca GNU tar ve zstd kurulu olmalıdır. Yollar ve kova adları kendi deneme ortamına uyarlanmalıdır.

Kaynak tutarlılığı ve saklama düzeni

Önce neyi geri getireceğini belirle. Canlı veritabanı dizinini sıradan dosya kopyasıyla yedekleme; veritabanına uygun yedek/dump veya tutarlı snapshot üret. Örneklerde /srv/backups/ready yalnızca üretimi bitmiş, doğrulanmış ve sonradan değiştirilmeyen dosyalar içerir. Her yedeğe benzersiz tarih/çalışma kimliği ver; günlük ve aylık kopyaları ayrı öneklerde tut. Aylık yedeği ayrıca seçip kopyalamak gerekir; lifecycle ay sonunu otomatik seçmez.

SSE, nesne depoda saklanırken şifreleme sağlar; aktarım için TLS, sağlayıcıya ulaşmadan önce şifrelemek için rclone crypt ayrı katmanlardır. crypt kullanılırsa parola, varsa salt ve yapılandırma geri dönüş boyunca korunmalıdır. S3 ve B2 erişimini gereken kova/önek ve işlemlerle sınırla.

Küçük dosyaları arşivlemek istek sayısını azaltabilir; karşılığında tek dosyayı geri almak için daha büyük bir arşiv indirmen gerekebilir. Depolama, istek, sınıf geçişi, minimum saklama, geri getirme, KMS ve veri çıkış maliyetlerini birlikte hesapla. Daha soğuk sınıf her durumda daha ucuz değildir.

S3 ve native B2 bağlantılarını tanımlamak

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

AWS için ortamdan kimlik bilgisi kullanacaksan S3 remote’unda env_auth=true gerekir; dosyada ayrıca sabit erişim anahtarı tanımlama. Geçici kimlik bilgilerinde AWS_SESSION_TOKEN da gereklidir. Native B2 değişken adları RCLONE_B2_ACCOUNT ve RCLONE_B2_KEY şeklindedir. Aşağıdaki temsili değerleri komut geçmişine gerçek sır yazarak doldurmak yerine parola/secret yöneticisinden sürece aktar.

# Runtime environment supplied securely to the backup process:
export AWS_ACCESS_KEY_ID='REPLACE_WITH_ACCESS_KEY_ID'
export AWS_SECRET_ACCESS_KEY='REPLACE_WITH_SECRET_ACCESS_KEY'
# For temporary AWS credentials, also set the matching AWS_SESSION_TOKEN.
export RCLONE_B2_ACCOUNT='REPLACE_WITH_APPLICATION_KEY_ID'
export RCLONE_B2_KEY='REPLACE_WITH_APPLICATION_KEY'

Uzakları adlandırmak: Sadelik iyidir

rclone config file ile kullanılan yapılandırma yolunu öğren. Mevcut dosyayı koruyarak editörde aşağıdaki remote tanımlarını ekle; yalnızca dosya sahibi okuyabilsin. Ortam değişkenleri çalışma anında kimlik bilgilerini tamamlar. Örnek S3 kovası eu-central-1 bölgesinde önceden oluşturulmuş olmalıdır; native B2 için bölge/endpoint eklemiyoruz.

[backup-s3]
type = s3
provider = AWS
env_auth = true
region = eu-central-1
server_side_encryption = AES256

[backup-b2]
type = b2
hard_delete = false

Native B2’de hard_delete=false silme isteğinde dosyayı gizler; üzerine yazmak yeni sürüm oluşturur. hard_delete=true hedeflenen sürümü kalıcı siler; sürümlemeyi açıp kapatan bir seçenek veya bütün eski sürümleri temizleyen bir komut değildir. Eski sürümlerin ne kadar kalacağını kovanın lifecycle kuralları belirler.

İlk kopya ve ayrı bir ayna denemesi

Tamamlanmış yedek dosyalarını önce silme yapmayan copy ile aktar. Yine de copy aynı adlı değişmiş hedef dosyayı güncelleyebilir; geçmişi korumak için benzersiz adlar gerekir. Aşağıdaki sync örneği ayrı bir mirror-test/ öneğinde yalnızca önizlemedir: kaynakta olmayan hedef dosyalar silineceği için çıktıyı incelemeden --dry-run kaldırma.

rclone copy /srv/backups/ready backup-s3:mybucket/prod/daily   --checksum --transfers 4 --checkers 8 --progress

rclone sync /srv/backups/ready backup-s3:mybucket/mirror-test   --dry-run --checksum --transfers 4 --checkers 8

Düşük eşzamanlılıkla başla ve ölç. --fast-list desteklenen depolarda istek sayısını azaltabilir ama listeyi RAM’de tutar. S3 multipart belleği yaklaşık transfers × upload-concurrency × chunk-size kadar ek alan kullanabilir: 8 aktarım, 4 parça ve 64 MiB parça yaklaşık 2 GiB eder. Bu nedenle yüksek değerler her VPS’e uygun değildir.

rclone check /srv/backups/ready backup-s3:mybucket/prod/daily --one-way

check dosya boyutunu ve iki tarafta kullanılabilen ortak hash’i karşılaştırır; rapordaki atlanan hash kontrollerini incele. --size-only yalnızca boyuta bakar ve aynı boyuttaki farklı içerikleri ayıramaz. --one-way hedefteki fazladan dosyaları hata saymaz. Ortak hash yoksa seçili veriyi --download ile okuyarak veya güvenilir checksum kaydıyla doğrula; bunun aktarım ve geri getirme bedeli olabilir.

S3 ve B2 için sunucu tarafı şifreleme

AWS S3’e yeni yüklemeler varsayılan olarak SSE-S3 ile şifrelenir; bu, tüm S3 uyumlu sağlayıcılar için aynı varsayımın yapılabileceği anlamına gelmez. AES256 seçeneği SSE-S3 ister. SSE-KMS kullanacaksan kovanın politikası, anahtarın erişilebilirliği ve geri yükleyen kimliğin KMS yetkileri birlikte uygun olmalıdır. Açık AES256 ayarı, KMS varsayılanından farklı bir istektir; ayarları birbiriyle uyumlu tut.

# Completed, verified artifact; exact destination object name:
rclone copyto /srv/dumps/db.sql.zst backup-s3:mybucket/prod/db/db.sql.zst   --s3-server-side-encryption AES256

# Alternative for a KMS-enabled policy; replace the ARN before use:
rclone copyto /srv/secrets.tar backup-s3:mybucket/prod/secure/secrets.tar   --s3-server-side-encryption aws:kms   --s3-sse-kms-key-id 'REPLACE_WITH_FULL_KMS_KEY_ARN'

Native B2 örneğinde, Backblaze web konsolunda ilgili kovanın varsayılan şifrelemesini SSE-B2 olarak etkinleştir ve yeni bir deneme yüklemesinin şifreleme bilgisini kontrol et. Bu kova ayarı daha sonra yüklenen/kopyalanan nesnelere uygulanır; mevcut nesneleri yeniden şifrelemez. SSE-C farklı müşteri anahtarı yönetimi gerektirir ve native B2’nin kendi seçenekleri vardır; S3 komut bayraklarını native B2’ye taşımak doğru değildir.

KMS yüklemede kms:GenerateDataKey, indirmede kms:Decrypt; multipart yüklemede her ikisi gerekebilir. S3 yetkileri tek başına yeterli değildir. Kullanılan bayraklar ve hash davranışı için rclone S3 belgelerini incele; sırları komut argümanlarına veya günlüklere yazma.

Lifecycle, Glacier sınıfları ve silme koşulları

AWS’de GLACIER_IR (Instant Retrieval) doğrudan GET ile erişilebilir. GLACIER (Flexible Retrieval) ve DEEP_ARCHIVE indirmeden önce geri getirme isteği ve bekleme gerektirir. Minimum ücretlendirilen süre Standard-IA için 30, iki Glacier sınıfı için 90, Deep Archive için 180 gündür; süreyi ilgili sınıfta geçirilen zamana göre değerlendir. Bu süreden önce silmek/taşımak ek ücret doğurabilir.

Aşağıdaki örnek yalnızca prod/logs/ öneğini hedefler: nesne yaşına göre 30. gün Standard-IA, 90. gün Flexible Retrieval, 365. gün expiration. Önce deneme kovasında ve saklama gereksinimine göre değerlendir. Küçük nesneler, minimum süreler ve işlem ücretleri tasarruf sonucunu değiştirebilir; yeni/güncellenmiş politikalarda 128 KB altındaki nesneler varsayılan olarak sınıf değiştirmez.

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

Sürümleme kapalı S3 kovasında expiration kalıcı silmeye gider; sürümleme açık kovada güncel nesne genellikle delete marker ile görünmez olur ve eski sürüm kalır. Noncurrent sürüm temizliği ayrıca tanımlanmalıdır. B2’de ise yaşa dayalı gizleme/silme vardır, “son N sürümü tut” sayacı yoktur. Örneğin yalnızca prod/daily/ için yüklemeden 45 gün sonra gizleme ve gizlenmeden 7 gün sonra silme düşünülebilir; üzerine yazılmış sürümler daha erken gizlenmiş olabilir. Bu süreler örnektir ve işlem anlık değildir. B2 lifecycle kuralları ile önek kapsamını doğrula; aylık kopyaları bu kuralın dışında tut.

Sınıfların erişim davranışını ve minimumlarını S3 depolama sınıfları belgelerinden karşılaştır. Object Lock veya legal hold varsa saklama süresi dolmadan silme engellenebilir. Kova üzerinde Object Lock özelliğinin açık olması tek başına her nesnenin korunduğunu göstermez.

Kopyalama, akış ve filtre örnekleri

Sync mi, Copy mi, rcat mi?

Tarihsel yedekler için copy ve benzersiz adlar, sürekli aynı durumu gösteren ayrı bir ayna için ise doğrulanmış sync kullan. rcat standart girdiyi tek nesneye yazar ve aynı adı üzerine yazabilir. Akışı baştan yeniden deneme olanağı sınırlıdır; bütün kaynak akışı saklanmadığı için tamamını otomatik tekrar oynatamaz. Yeniden deneme ve checksum için önce yerel, tamamlanmış arşiv üretmek çoğu iş akışını kolaylaştırır.

# Prepared immutable media snapshot, not a changing live tree:
rclone copy /srv/media-snapshot backup-b2:site-media/prod/daily   --transfers 4 --checkers 8 --progress

# Advanced streaming example: run in Bash, from a stable snapshot only.
set -euo pipefail
RCLONE_RUN_ID="$(date -u +%Y%m%dT%H%M%SZ)"
tar -I 'zstd -3' -C /srv/site-snapshot -cf - .   | rclone rcat "backup-s3:mybucket/prod/staging/site-${RCLONE_RUN_ID}.tar.zst.partial"

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

Akış örneğindeki pipefail arşiv üreticisinin hatasını da işin başarısızlığına dönüştürür; hata halinde uzakta kısmi nesne kalabilir. .partial dosyasını geri dönüş kataloğuna alma. Başarılı akıştan sonra da arşivi indirip doğrulamadan tamamlanmış yedek sayma. Filtreler ise yalnızca yeniden üretilebilir veya gereksiz dosyaları dışlamalı; bağımlılık kilit dosyaları ve uygulama yapılandırması gibi gereken veriyi sakla.

rclone copy /srv/app-snapshot backup-s3:mybucket/prod/app   --exclude '.cache/**'   --exclude 'node_modules/**'   --exclude '*.tmp'   --progress

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

Bant genişliği takvimi çalışmayı geceleri hızlandırıp gündüz sınırlandırabilir. rclone’daki M, Mbit/s değil MiB/s anlamındadır. Aşağıdaki değerler örnek sınırlardır; sunucunun gerçek bağlantısına ve diğer işlerine göre ayarla.

# Local timezone: 22:00-06:00 at 50 MiB/s, otherwise 5 MiB/s.
rclone copy /srv/backups/ready backup-b2:team/prod/daily   --bwlimit '22:00,50M 06:00,5M'   --progress

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

S3’ten native B2’ye kopyalanmış aynı veri kümesini doğrularken MD5 ve SHA1 gibi farklı hash’leri doğrudan eşitleyemezsin. Küçük bir deneme öneğinde aşağıdaki kontrol iki taraftan da veriyi okur; önce sınıfın okunabilirliğini ve maliyetini değerlendir. Komut bir kopya oluşturmaz.

rclone check backup-s3:mybucket/verification-sample backup-b2:myreplica/verification-sample --one-way --download

Bu karşılaştırma, seçili kaynak dosyalarının hedefte aynı içeriğe sahip olduğunu denetler; hedefteki ek dosyaları, kaynak yedeğin uygulama tutarlılığını veya tüm geçmiş sürümleri doğrulamaz. Sonuç kodu ve hata raporu izlenmelidir.

Maliyet hesabında hangi kalemler bulunmalı?

Saklama penceresini iş ihtiyacına göre seç: günlüğü kısa, ay sonunu uzun tutmak ancak gerçekten ayrı ve kullanılabilir kopyalar varsa işe yarar. S3 arşiv nesnelerinin ek metaveri maliyeti ve nesne başına geçiş isteği bulunur. Gereksiz sürüm temizliği kapasiteyi azaltabilir, fakat bağımlı yedek parçalarını veya gereken WAL’ı silmek geri dönüşü bozar.

Katalogda nesne adı, yedek zamanı, checksum, üretim yöntemi, şifreleme ve gerekiyorsa bağımlılıkları bulunsun. Örneğin prod/daily/ ile prod/monthly/ farklı saklama kurallarına sahip olabilir. Aylık kopyayı, doğrulanmış günlükler arasından bir iş seçip ayrı öneğe yüklemelidir; eski yerel günlüklerin sürekli yeniden yüklenmesi lifecycle temizliğini etkisiz bırakabilir.

İstek sayısı, ortalama nesne boyutu, aktarım süresi ve en yüksek bellek kullanımını ölç. Sıkıştırma seviyesi, parça boyutu ve eşzamanlılığı tek tek değiştirerek karşılaştır; yalnızca depolama GB fiyatına bakıp sonuç çıkarma.

Glacier ve normal depodan geri dönüş provası

Yakın tarihli yedek için doğrudan indirme, Flexible Retrieval/Deep Archive için önce arşiv geri getirme gerekir. Aşağıdaki nesne adı temsilidir; katalogdan gerçekten var olan tek nesneyi seç. Geri getirme isteği birden fazla nesneye yanlışlıkla yayılmasın diye dizin ve dosya filtresi birlikte kullanılır.

# GLACIER or DEEP_ARCHIVE only: preview the selected restore request.
rclone backend restore backup-s3:mybucket/prod/archives/   --include '/site-YYYYMMDD.tar.zst'   -o priority=Standard -o lifetime=2 --dry-run
# After reviewing that preview, repeat without --dry-run to request retrieval.
# Status lists the directory and ignores filters; locate site-YYYYMMDD.tar.zst.
rclone backend restore-status backup-s3:mybucket/prod/archives/
# Wait until retrieval of that object finishes before downloading:
rclone copyto backup-s3:mybucket/prod/archives/site-YYYYMMDD.tar.zst /restore/site.tar.zst

# Select visible log files modified within 30 days; not a version-history restore:
rclone copy backup-b2:team/prod/logs /var/tmp/restore-logs   --include '*.log' --max-age 30d

Standard geri getirme Flexible Retrieval için tipik 3–5 saat, Deep Archive için tipik 12 saate kadar sürebilir; Deep Archive Bulk tipik 48 saate kadar sürer. Bunlar tüm sistemin geri dönme garantisi değildir; indirme ve uygulama kurulumu da eklenir. Geçici okunabilir kopyanın iki günlük süresi, asıl arşivin saklama süresi değildir. Hash ve arşiv açma kontrolünden sonra izole ortamda uygulamayı doğrula; sonuçları RTO/RPO ve felaket kurtarma runbook’una kaydet.

Otomasyon ve başarısız işlerin görünürlüğü

Aşağıdaki alternatiflerden yalnızca birini etkinleştir. Önceden oluşturulmuş rclonebackup hizmet hesabı kaynak /srv/backups/ready dizinini okuyabilmeli. Aynı remote tanımlarını /etc/rclone/backup.conf dosyasına, çalışma zamanı kimlik bilgilerini /etc/rclone/backup.env dosyasına kaydet; bunlar root:rclonebackup sahipliğinde 0640 olmalı. Ortam dosyası basit KEY=value satırları içermeli, export kullanmamalıdır. /var/log/rclone hizmet hesabınca yazılabilir ve diğer kullanıcılara kapalı olmalı. Kaynak üreticisi dosyaları ancak doğruladıktan sonra ready dizinine almalıdır.

Aşağıdaki içeriği /usr/local/sbin/rclone-backup dosyasına root sahipliğinde 0755 izinle kaydet:

#!/bin/bash
set -euo pipefail
set -a
source /etc/rclone/backup.env
set +a
exec /usr/bin/rclone --config /etc/rclone/backup.conf   copy /srv/backups/ready backup-s3:mybucket/prod/daily   --checksum --transfers 4 --checkers 8   --log-level INFO --log-file /var/log/rclone/backup.log

rclonebackup kullanıcısının crontab’ına tek fiziksel satır ekle:

15 2 * * * /usr/local/sbin/rclone-backup

systemd kullanacaksan aşağıdaki içerikleri belirtilen iki ayrı dosyaya kaydet. Aynı sarmalayıcı kaynak/kimlik bilgisi ayarlarını paylaşır; Type=oneshot iş bitince kapanır. Timer’ın etkin olması başarılı yedek oluştuğunu kanıtlamaz.

# /etc/systemd/system/rclone-backup.service
[Unit]
Description=Copy completed backup artifacts to S3
[Service]
Type=oneshot
User=rclonebackup
TimeoutStartSec=infinity
ExecStart=/usr/local/sbin/rclone-backup

# /etc/systemd/system/rclone-backup.timer
[Unit]
Description=Nightly backup upload
[Timer]
OnCalendar=*-*-* 02:15:00
Persistent=true
[Install]
WantedBy=timers.target

Dosyalar ve erişimler hazır olduğunda:

sudo systemctl daemon-reload
sudo systemctl enable --now rclone-backup.timer
systemctl list-timers rclone-backup.timer

İşin çıkış kodunu, son başarı zamanını, gönderilen dosyaları ve doğrulama sonucunu izle. Cron çakışmalarını kilit veya zamanlama ile engelle; systemd etkin hizmeti yeniden başlatmaz, kaçan her geceyi ayrı ayrı kuyruğa almaz. Takılan iş ve eksik yeni yedek için süre/yaş alarmı kur. Günlükleri döndür; başarı bildirimi ancak iş ve gerekli kontroller geçince gönderilsin.

Kova, IAM ve lifecycle değişikliklerini gözden geçirilebilir yapılandırma olarak saklamak, geri dönüşte aynı ortamı kurmayı kolaylaştırır. Terraform ile VPS ve DNS otomasyonu bu yaklaşımın altyapı tarafını ele alır; saklama kuralları uygulanmadan önce mevcut nesnelere etkisi ayrıca incelenmelidir.

Anahtar erişimi ve saklama sınırları

İzinler yapılan işlere göre değişir: listeleme, yükleme, okuma, multipart işlemleri ve gerekiyorsa silme/geri getirme ayrı ihtiyaçlardır. Basit “list, put, get” listesi her rclone senaryosu için tam bir IAM politikası değildir. B2 uygulama anahtarını uygun kova ve önekle sınırla. Süreç ortamı tek başına sır kasası değildir; aynı hesap ve root erişimini de hesaba kat.

SSE-C veya crypt kullanıyorsan yedekler saklandığı sürece gereken anahtarlar erişilebilir kalmalıdır. KMS anahtarını devre dışı bırakmak veya silmek geri dönüşü engelleyebilir. Object Lock governance modu yetkili kimliklerce aşılabilir; compliance modundaki korunan sürümün süresi kullanıcılar tarafından kısaltılamaz. Bu korumaları gerçek nesne ayarından doğrula.

Hangi yedeğin hangi anahtar/politika ile yazıldığını katalogda belirt; sırrın kendisini katalogla birlikte herkese açma. Başka bir yetkili kişinin kaynak sunucu olmadan geri getirme yapabilmesini dene.

WordPress ve PostgreSQL için tutarlı kaynak hazırlamak

WordPress dosyaları ve medya arşivleri

Canlı Docker volume’üne tar uygulamak, WordPress dosyaları ile veritabanının aynı ana ait olmasını sağlamaz. Uygulamaya uygun yöntemle tutarlı dosya snapshot’ı ve eşleşen MariaDB/MySQL yedeği oluştur. Aşağıdaki kaynak /srv/wordpress-snapshot bu hazırlanmış kümedir; örnek canlı volume yolunu kullanmaz. Önceden hazırlanmış staging ve ready dizinleri aynı dosya sisteminde olmalıdır. Yerel arşiv başarılı oluşursa staging alanından ready dizinine atomik olarak geçer ve yeniden denenebilir.

# Bash; the source snapshot is stable and includes the matching database export.
set -euo pipefail
RCLONE_RUN_ID="$(date -u +%Y%m%dT%H%M%SZ)"
RCLONE_ARCHIVE="/srv/backups/ready/wp-${RCLONE_RUN_ID}.tar.zst"
RCLONE_TMP="/srv/backups/staging/wp-${RCLONE_RUN_ID}.tar.zst.partial"
tar -I 'zstd -3' -C /srv/wordpress-snapshot -cf "$RCLONE_TMP" .
tar -I zstd -tf "$RCLONE_TMP" >/dev/null
mv -- "$RCLONE_TMP" "$RCLONE_ARCHIVE"
rclone copyto "$RCLONE_ARCHIVE" "backup-b2:site-media/prod/daily/wp-${RCLONE_RUN_ID}.tar.zst"

Arşivin açılabilmesi uygulama doğrulamasının yerine geçmez. Veritabanını ve dosyaları birlikte ayrı ortamda geri getir; Docker Compose ile WordPress yapılandırması hizmet ve volume ilişkilerini anlamaya yardımcı olur.

PostgreSQL: WAL akarken güvenli bir liman

PostgreSQL’de uygun fiziksel yedek ve gereken WAL zinciri birlikte korunmalıdır. pgBackRest ile WAL arşivleme bunun veritabanı tarafını açıklar. Çalışan pgBackRest deposunu gelişigüzel sync etmek veya lifecycle ile bazı parçalarını silmek tutarlı bağımsız kopya sağlamaz. pgBackRest’in desteklediği repository yöntemini ya da açıkça koordineli, doğrulanmış depo kopyasını kullan.

Sunucuyu baştan kurmak gerektiğinde

Sunucu yeniden kurulum bilgisi de yedek planının parçasıdır. cloud-init ve Ansible ile tekrar üretilebilir VPS yaklaşımı sürümleri ve servis kurulumunu kaydetmeye yardımcı olur. Kurtarma ortamında eski zamanlanmış işleri ve dış entegrasyonları veri doğrulanmadan açma.

Tamamlanmış bir yedek akışının ölçütü

rclone aktarımı; tutarlı kaynak, ayrı geçmiş kopyaları, anlaşılmış saklama kuralları ve ölçülmüş geri dönüşle birlikte anlamlıdır. Yeni bir sınıfa veya şifreleme düzenine geçince eski kullanılabilir yedekleri silmeden önce yeni akışın geri getirmesini doğrula.