Özet: Modern bir yedekleme stratejisi olan 3-2-1-1-0 kuralı Proxmox Backup Server (PBS) ile pratik olarak şu şekilde uygulanır: ZFS tabanlı yerel datastore + ikinci bir PBS’e sync + S3 uyumlu object storage (PBS 4.2+) + en az bir immutable kopya + her hafta verify ile 0 hata. Kritik uyarı: PBS 4.2’de S3 stable oldu ama Object Lock henüz native desteklenmiyor — gerçek immutability için harici S3 bucket’ta bucket-level Object Lock yapılandırılmalı.

3-2-1-1-0 stratejisi nedir?

Klasik 3-2-1 kuralının (3 kopya, 2 farklı medya, 1 offsite) ransomware-bilinçli güncellenmiş hâlidir:

Rakam	Anlamı	PBS’te nasıl uygulanır
3	Toplam veri kopyası	1 prod + 1 yerel PBS + 1 uzak PBS / S3
2	Farklı medya / depo türü	NVMe (sıcak yedek) + HDD/ZFS (uzak) + Object Storage (soğuk)
1	Offsite kopya	Başka bir lokasyondaki PBS veya S3 bucket
+1	Immutable / air-gapped kopya	S3 Object Lock veya tape (LTO) veya manuel detached storage
0	Verification hatası	Düzenli verify-job ile her chunk SHA-256 ile doğrulanır

Bu kuralın +1 immutable kısmı ransomware’e karşı son savunmanızdır. Sophos State of Ransomware 2024 raporuna göre saldırıların %94’ü yedek sistemleri hedef alıyor; yedekleri tehlikeye atılan kurumların %57’sinde yedekler kullanılamaz hâle geliyor. Immutable katman bu saldırı vektörünü tamamen kapatır.

PBS mimarisi neden işe yarar?

Geleneksel vzdump ile karşılaştırıldığında PBS üç temel avantaj sağlar:

• Block-level deduplication (değişken uzunluklu chunking): Tipik VM yüklerinde 5-10× depolama tasarrufu. Aynı OS imajından türemiş 20 VM, tek bir base set chunk olarak saklanır.
• Append-only mimari: Yeni yedek sadece yeni chunk ekler, mevcut chunk’lara dokunmaz. Tek silme operasyonu prune‘dur (ayrı, kontrollü süreç).
• Client-side AES-256-GCM encryption: Chunk’lar PBS’e ulaşmadan istemci tarafında şifrelenir; PBS’i ele geçiren saldırgan şifre olmadan içeriği okuyamaz.

Adım 1 — Yerel PBS datastore kurulumu (ZFS)

ZFS’in chunk-seviyesi checksum’u sayesinde bit-rot tespit edilir. PBS’in append-only modeli ile birleştiğinde end-to-end integrity sağlar.

# ZFS pool zaten varsa, dataset olusturun
zfs create -o mountpoint=/mnt/datastore/backups rpool/backups
zfs set compression=lz4 rpool/backups
zfs set atime=off rpool/backups
zfs set xattr=sa rpool/backups

# PBS datastore'u olusturun
proxmox-backup-manager datastore create local-backups /mnt/datastore/backups

Not: RAIDZ2 (en az 4 disk) veya mirror (en az 2 disk) önerilir. Tek disk asla kullanmayın; chunk corruption’da tüm backup zinciri etkilenir.

Adım 2 — Retention politikası ve prune job

PBS, beş retention parametresi ile esnek bir politika sağlar. Bir backup, herhangi bir kurala uyduğu sürece korunur (mantıksal OR).

Parametre	Önerilen değer (KOBİ)	Önerilen değer (kurumsal)
keep-last	3	5
keep-daily	7	14
keep-weekly	4	12
keep-monthly	6	24
keep-yearly	1	7 (KVKK uyumluluk için)

# Prune job (her gece 21:30'da calisir)
proxmox-backup-manager prune-job create daily-prune 
  --store local-backups 
  --schedule "21:30" 
  --keep-last 3 
  --keep-daily 7 
  --keep-weekly 4 
  --keep-monthly 6 
  --keep-yearly 1

Önemli: Prune sadece backup snapshot’larını işaretler, gerçek silme garbage collection (GC) ile olur.

Adım 3 — Garbage Collection (GC) scheduling

GC, prune ile işaretlenmiş ama hâlâ chunk store’da duran “yetim” chunk’ları gerçekten siler. Prune’dan hemen sonra çalışmalı (~22:00).

# GC job (her gece 22:00'de)
proxmox-backup-manager garbage-collection-job create daily-gc 
  --store local-backups 
  --schedule "22:00"

GC çalışmazsa disk alanı asla geri kazanılmaz, prune ne kadar agresif olursa olsun.

Adım 4 — PVE tarafında backup job

# Tum VM'ler icin gecelik snapshot mode backup
pvesh create /cluster/backup 
  --id daily-backup 
  --schedule "0 2 * * *" 
  --storage pbs-local 
  --mailnotification always 
  --mailto [email protected] 
  --mode snapshot 
  --all 1 
  --compress zstd

--mode snapshot VM’leri durdurmadan tutarlı yedek alır. zstd sıkıştırma, gzip’ten daha hızlı ve daha iyi oran sağlar (PBS dedup ile birlikte ideal).

Adım 5 — İkinci PBS’e offsite sync

Coğrafi olarak ayrı bir lokasyona (başka şubedeki rack, kolokasyon veya bulut sunucusu) PBS instance’ı kurun. Sync job sadece yeni chunk’ları transfer eder, daily transfer hacmi tipik olarak toplam yedeklerin %1-5’idir.

# Uzak PBS'i kaydet (token-based auth)
proxmox-backup-manager remote add remote-dr 
  --host pbs-dr.tekur.net 
  --port 8007 
  --auth-id backup@pbs!sync-token 
  --password '<TOKEN_SECRET>'

# Sync job (her gece 04:00 - local backup bittikten sonra)
proxmox-backup-manager sync-job create push-to-dr 
  --remote remote-dr 
  --remote-store dr-datastore 
  --store local-backups 
  --schedule "0 4 * * *" 
  --remove-vanished true

İlk full sync uzun sürer (1 TB için ~8 saat @ 300 Mbps). Sonrasında günlük artımlı sync’ler dakikalar içinde tamamlanır.

Adım 6 — S3 Object Storage (PBS 4.2+) + immutable kopya

Proxmox Backup Server 4.2 (Nisan 2026) ile S3 uyumlu object storage backend’i stable hâle geldi. Ancak kritik bir eksiklik var: PBS S3 entegrasyonu henüz Object Lock’u native desteklemiyor. Gerçek immutability için ek yapılandırma gerekir.

Yaklaşım A — PBS datastore olarak S3 (immutable değil)

PBS 4.2+ ile S3 bucket’ını datastore olarak ekleyebilirsiniz. Bu daha çok soğuk arşiv (cold tier) için uygundur:

# PBS Web UI: Configuration -> Datastore -> Add -> S3 Backend
# Veya CLI:
proxmox-backup-manager datastore create cold-archive 
  --backend-type s3 
  --bucket tekur-pbs-cold 
  --endpoint https://s3.wasabisys.com 
  --access-key AKIAIOSFODNN7EXAMPLE 
  --secret-key wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY 
  --region us-east-1

Yaklaşım B — Harici S3 bucket + Object Lock (immutable, önerilen)

Gerçek air-gapped immutability için: yerel PBS’inizden S3 bucket’ına sync edip, bucket düzeyinde Object Lock’u Wasabi/AWS S3/Backblaze tarafında aktif edin. PBS chunk’ları yazıldıktan sonra silinemez veya değiştirilemez — root kullanıcı bile.

# 1. Wasabi/AWS S3'te Object Lock'lu bucket olusturun (CLI ornegi - AWS)
aws s3api create-bucket --bucket tekur-pbs-immutable --region eu-central-1 
  --object-lock-enabled-for-bucket 
  --create-bucket-configuration LocationConstraint=eu-central-1

# 2. Default retention policy (30 gun COMPLIANCE mode)
aws s3api put-object-lock-configuration --bucket tekur-pbs-immutable 
  --object-lock-configuration '{
    "ObjectLockEnabled": "Enabled",
    "Rule": {
      "DefaultRetention": {
        "Mode": "COMPLIANCE",
        "Days": 30
      }
    }
  }'

# 3. PBS sync job ile S3'e tas (S3 backend datastore olarak)
proxmox-backup-manager sync-job create push-to-s3 
  --remote-store cold-archive 
  --store local-backups 
  --schedule "0 5 * * *"

COMPLIANCE mode’da root bile retention süresi dolmadan dosyayı silemez (AWS account root dahil). GOVERNANCE mode’da IAM s3:BypassGovernanceRetention izniyle silinebilir — production için COMPLIANCE önerilir.

Adım 7 — Verify job (0 hata garantisi)

3-2-1-1-0 stratejisinin “0” kısmı verify ile sağlanır. PBS her chunk’ın SHA-256 hash’ini yeniden hesaplayıp manifest ile karşılaştırır.

# Haftalik verify (Pazar sabah 06:00)
proxmox-backup-manager verify-job create weekly-verify 
  --store local-backups 
  --schedule "0 6 * * 0" 
  --ignore-verified true 
  --outdated-after 30

--ignore-verified son 30 gün içinde doğrulanmış backup’ları atlar (CPU/IO tasarrufu). --outdated-after 30 ise 30 günü geçenleri zorla yeniden doğrular.

Adım 8 — Restore testing (RTO’yu ölçün)

Yedeklerin geri yüklenebildiğini 3 ayda bir test etmeden “yedeğim var” demek hatalı bir güvendir. Test prosedürü:

1. Bir test VM’i seçin (örn. VM ID 100)
2. Yeni bir VMID’e restore edin (production’a değil):

qmrestore pbs:backup/vm/100/2026-06-14T02:00:05Z 9100 
  --storage local-zfs 
  --unique true

3. Restore süresini not edin (bu sizin gerçek RTO’nuz)
4. VM’i çalıştırın, içine girin, application data integrity kontrol edin (DB queries, dosya açma)
5. Sonuçları belgelendirin: “VM 100, 50 GB, restore 12 dakika, DB integrity OK”

Adım 9 — Monitoring ve uyarı

PBS web UI’sı tek başına yeterli değildir — özellikle çoklu PBS instance’ında. Üç katmanlı monitoring önerilir:

• Email notifications: Backup job --mailnotification always + verify job email — başarı/başarısızlık
• Pulse veya Checkmk: Datastore doluluk %, son backup yaşı, son verify yaşı için trend ve alert
• Prometheus + Grafana: PBS metrics endpoint (/api2/json/status/metrics) ile uzun dönemli kapasite planlama

Asgari uyarı listesi: backup job başarısız > 1 kez ardarda, datastore > %80 dolu, verify hatası > 0, son backup > 36 saat eski.

Sık karşılaşılan sorunlar

• “Disk dolu ama prune yaptım.” GC çalışmamış olabilir. proxmox-backup-manager garbage-collection list-jobs ile son çalışma zamanını kontrol edin.
• “Sync job ‘connection refused’ veriyor.” Uzak PBS’in 8007 portu firewall’da açık değil veya token süresi dolmuş. PBS web UI → Access Control → API Token kontrol edin.
• “S3 backend yavaş.” PBS chunk’ları küçük dosyalar (4-16 MB), object storage küçük dosyalarda latency yüksek olur. Wasabi/B2 gibi flat-fee provider’lar AWS S3’ten çok daha ekonomik bu workload için.
• “Encryption key kaybettim, backup’ları açamıyorum.” Yedek geri dönüşü yok. Encryption key’i önce ayrı bir kasaya, sonra ayrı bir 1Password/Bitwarden vault’una, sonra fiziksel bir kağıda yedekleyin. Bu üçü farklı lokasyonlarda olmalı.
• “Object Lock’lı bucket’ı yanlışlıkla retention=10 yıl yaptım, bucket silinmiyor.” COMPLIANCE mode’da bu süre dolmadan hiçbir şey silinemez — IAM root bile. Bu, özelliğin doğru çalıştığının kanıtı. Test ortamında 1 gün retention ile deneyin.

Sürüm uyumluluk tablosu

Özellik	PBS 2.x	PBS 3.x	PBS 4.0-4.1	PBS 4.2+
Yerel datastore + dedup	✅	✅	✅	✅
Sync job (PBS to PBS)	✅	✅	✅	✅
Client-side encryption	✅	✅	✅	✅
Prune job, verify job, GC	✅	✅	✅	✅
S3 backend (tech preview)	❌	❌	✅	—
S3 backend (stable)	❌	❌	❌	✅
Native S3 Object Lock	❌	❌	❌	❌ (harici)

Önleyici öneriler

• PBS’in web UI portuna (8007) internet’ten erişimi kapatın; sadece VPN veya bastion host üzerinden erişin.
• PVE node’ları için her node ayrı API token kullansın; tek token tüm cluster’ı yetkilendirmesin.
• Encryption key rotation’ı yıllık planlayın; key compromise olursa eski backup’lara erişim kaybedilmesin diye master key + data keys hiyerarşisi kurun.
• Object Lock’lu bucket’ı ayrı bir cloud account/IAM kullanıcısıyla yönetin; production credentials’la üst üste binmesin.
• Restore testlerini takvime bağlayın; “şu hafta yaparız” diyen ekip 6 ay sonra hala yapmamış olur.

Test edilen sürümler: Proxmox VE 8.2.4 + PBS 3.2.7, PVE 8.3.1 + PBS 4.2.1. Yapılandırma örnekleri AWS S3, Wasabi ve Backblaze B2 üzerinde doğrulanmıştır. Son güncelleme: 2026-06-14.