Immutable Backup Nedir, Nasıl Test Edilir? WORM ve S3 Object Lock Karşılaştırması

01

Immutable Backup Nedir ve Neden Kritiktir?

Değiştirilemez yedekleme (immutable backup), bir kez yazıldıktan sonra belirli bir süre boyunca hiç kimse tarafından değiştirilemeyen, silinemez ve üzerine yazılamaz hale getirilen yedekleme verisidir. Bu "kimse" kavramının içine sistem yöneticileri, root kullanıcısı ve hatta bazı implementasyonlarda bulut sağlayıcısı bile girer.

Geleneksel yedekleme anlayışında bir saldırgan veya kötü niyetli içeriden biri backup dosyalarına erişerek onları silebilir ya da şifreleyebilir. Immutability bu saldırı vektörünü ortadan kaldırır: yedekleme verisi bir kez yazıldıktan sonra, retention period sona erene kadar değiştirilemez hale gelir.

Immutable Backup — Saldırı Vektörü Kırılması

Ransomware / Saldırgan Silme / Şifreleme Girişimi

→ENGELLENDI

          Immutable Storage
          WORM / Object Lock
        

→

Temiz Backup Restore Edilebilir

3-2-1-1-0 kuralı: En az 1 kopya immutable olmalı · 0 hata toleransı

🔒

Ransomware Koruması

Şifreleme ve silme saldırılarına karşı birincil kalkan

Retention period boyunca veri değiştirilemez

🏛️

Yasal Uyum

KVKK, BDDK, SEC, FINRA, HIPAA gereksinimleri

Denetim izi ve veri bütünlüğü kanıtı

🛡️

İçeriden Tehdit

Root dahil kimse silemez

Kötü niyetli yönetici senaryolarına karşı

✅

Veri Bütünlüğü

Bit rot, donanım hatası, yanlışlıkla silme

Kaza sonucu değiştirmelere karşı da koruma

ℹ️

3-2-1-1-0 kuralının "1 immutable" katmanı: Modern yedekleme standartları artık en az bir kopyanın immutable bir medyada saklanmasını zorunlu kılmaktadır. Bu kopya donanımsal WORM, S3 Object Lock veya hardened Linux repository üzerinde olabilir.

02

WORM Teknolojisi: Donanım Düzeyinde Koruma

WORM (Write Once Read Many), verinin yalnızca bir kez yazılabildiği, sonrasında yalnızca okunabildiği bir depolama paradigmasıdır. İlk olarak optik disk teknolojisiyle (CD-R, DVD-R) hayatımıza girmiştir; bugün hem donanım hem yazılım düzeyinde uygulanmaktadır.

Donanım WORM

Donanımsal WORM implementasyonlarında koruma, depolama denetleyicisi ya da ortamın fiziksel özellikleri tarafından uygulanır. Bunun en saf formu manyeto-optik (MO) diskler veya son nesil WORM-enabled tape (LTO Ultrium WORM kartuşları) olabilir. Kurumsal disk sistemlerinde ise WORM politikaları denetleyici firmware'i seviyesinde uygulanır: örneğin Dell EMC DataDomain veya HPE StoreOnce appliance'larında WORM mode aktive edildiğinde, hiçbir yönetim arayüzü veriyi silemez.

Yazılım WORM

Yazılım tabanlı WORM, işletim sistemi veya dosya sistemi düzeyinde uygulanır. Linux'ta chattr +i komutu bu mekanizmanın en yaygın örneğidir. chattr +i ile işaretlenen bir dosya, root kullanıcısı tarafından bile silinemez veya değiştirilemez; ancak bu kilidin kaldırılması da root yetkisi gerektirir. Gerçek immutability için bu kilidi kaldırmaya yetkili kullanıcı sayısı minimize edilmelidir.

# chattr ile immutability uygulama (Linux)
sudo chattr +i /backup/veeam/VMs/FullBackup-2026-06-04.vbk

# Immutability durumunu kontrol etme
lsattr /backup/veeam/VMs/FullBackup-2026-06-04.vbk
# Çıktı: ----i--------e-- /backup/veeam/VMs/FullBackup-2026-06-04.vbk

# Silme girişimi (başarısız olmalı)
rm /backup/veeam/VMs/FullBackup-2026-06-04.vbk
# Çıktı: rm: cannot remove '...': Operation not permitted

# Kilidi kaldırmak için (YALNIZCA retention süresi dolduğunda)
sudo chattr -i /backup/veeam/VMs/FullBackup-2026-06-04.vbk
    

⚠️

chattr +i root'u durdurur ama fiziksel erişimi durdurmaz. Bir saldırgan disk üzerinde doğrudan I/O yapabilirse (örneğin donanıma fiziksel erişim) chattr koruması devre dışı kalabilir. Gerçek kurumsal WORM için donanım düzeyinde korumanın veya immutability-aware bir platform (Veeam hardened repo, NetApp SnapLock) kullanılması önerilir.

XFS Dosya Sistemi ve WORM

Veeam'in Hardened Linux Repository'si XFS dosya sistemi kullanır. XFS, chattr +i flag'ini tam destekler ve ayrıca reflink (copy-on-write) teknolojisi sayesinde deduplication destekli depolama sağlar. Bu ikili XFS + chattr kombinasyonu, Veeam'in Linux hardened repository'sinin temel mekanizmasıdır.

03

S3 Object Lock: Governance vs Compliance Modu

AWS S3 Object Lock, Amazon S3'ün WORM implementasyonudur. Nesne (object) düzeyinde veya bucket düzeyinde uygulanabilir. İki farklı mod sunar ve bu modlar arasındaki fark, kurumsal uyum açısından kritik öneme sahiptir.

Governance Mode

Yönetilebilir immutability — esneklik sunar

✅ Çoğu kullanıcı veriyi silemez/değiştiremez
⚠️ s3:BypassGovernanceRetention iznine sahip kullanıcılar lock'ı kaldırabilir
✅ Test, geliştirme ve yönetim senaryoları için uygun
✅ Retention süresini uzatmak mümkün
⚠️ Compliance sertifikaları için genellikle yeterli değil

Compliance Mode

Katı immutability — hiçbir istisna yok

🔒 Retention süresi dolmadan HİÇ KİMSE silemez
🔒 AWS root hesabı dahil, kimse lock'ı kaldıramaz
✅ FINRA, SEC, KVKK, BDDK gibi düzenleyici uyum için ideal
⚠️ Retention süresi yalnızca uzatılabilir, kısaltılamaz
⚠️ Yanlış ayar geri alınamaz — dikkatli yapılandırın

Retention Period Yapılandırması

S3 Object Lock, retention süresini gün veya yıl cinsinden belirler. Süre RetainUntilDate alanıyla ISO 8601 formatında tanımlanır.

# S3 Object Lock etkin bucket oluşturma (CLI)
aws s3api create-bucket \
  --bucket immutable-backup-bucket \
  --region eu-west-1 \
  --create-bucket-configuration LocationConstraint=eu-west-1

aws s3api put-object-lock-configuration \
  --bucket immutable-backup-bucket \
  --object-lock-configuration '
{
  "ObjectLockEnabled": "Enabled",
  "Rule": {
    "DefaultRetention": {
      "Mode": "COMPLIANCE",
      "Days": 30
    }
  }
}'

# Belirli bir nesneye Governance mode ile 60 günlük retention
aws s3api put-object-retention \
  --bucket immutable-backup-bucket \
  --key backups/full-2026-06-04.vbk \
  --retention '{"Mode":"GOVERNANCE","RetainUntilDate":"2026-08-04T00:00:00Z"}'
    

Legal Hold

Legal Hold, belirli bir süreyle sınırlı olmaksızın nesneyi kilitler. Genellikle hukuki süreçler, denetimler veya soruşturmalar sırasında kullanılır. Retention period bağımsız çalışır; Legal Hold aktifken retention süresi dolsa bile nesne silinemez.

# Legal Hold uygulama
aws s3api put-object-legal-hold \
  --bucket immutable-backup-bucket \
  --key backups/full-2026-06-04.vbk \
  --legal-hold '{"Status":"ON"}'

# Legal Hold kaldırma (yetkili kullanıcı)
aws s3api put-object-legal-hold \
  --bucket immutable-backup-bucket \
  --key backups/full-2026-06-04.vbk \
  --legal-hold '{"Status":"OFF"}'

# Nesnenin lock durumunu sorgulama
aws s3api get-object-retention \
  --bucket immutable-backup-bucket \
  --key backups/full-2026-06-04.vbk
    

🚨

Compliance mode geri alınamaz: Bir nesneyi Compliance mode ile kilitlediğinizde, retention süresi dolmadan o nesneyi silmek mümkün değildir. AWS destek ekibi dahil hiçbir yol yoktur. Production ortamında Compliance mode uygulamadan önce test ortamında mutlaka deneme yapın.

04

Veeam Hardened Linux Repository ile Immutability

Veeam'in Hardened Linux Repository'si, on-premises ortamlarda immutable backup elde etmenin en yaygın yollarından biridir. Cloud tabanlı çözümlere ihtiyaç duymadan, lokal bir Linux sunucusu üzerinde yazılım tabanlı WORM sağlar.

Temel Mekanizma: XFS + chattr +i

Veeam Backup & Replication, backup job'u tamamladıktan sonra oluşan .vbk ve .vib dosyalarını otomatik olarak chattr +i ile değiştirilemez hale getirir. Bu süre backup job'da tanımlanan immutability period boyunca geçerlidir.

# Hardened Linux Repository için XFS hazırlığı
mkfs.xfs /dev/sdb
mkdir -p /backup/veeam
mount /dev/sdb /backup/veeam

# /etc/fstab'a kalıcı mount ekleme
echo "/dev/sdb /backup/veeam xfs defaults,noatime 0 0" >> /etc/fstab

# Veeam için özel kullanıcı oluşturma (single-use credentials)
useradd veeambackup --no-create-home
chown veeambackup:veeambackup /backup/veeam
chmod 700 /backup/veeam

# SSH key-based auth aktive et, password auth kapat
sed -i 's/PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
    

Single-Use Credentials

Hardened Linux Repository'nin en önemli güvenlik özelliği single-use credentials desteğidir. Veeam, VBR konsolunda bu repository'ye erişmek için kullanılan SSH credential'larını yalnızca bir kez kullanır: repository ekleme sırasında. Sonrasında bu credential'lar saklanmaz. VBR sunucusu ele geçirilse bile saldırgan bu bilgilerle repository'ye erişemez.

✅

VBR yapılandırması: Backup Infrastructure → Add Repository → Linux-based repository → Make recent backups immutable for [N] days seçeneğini aktive edin. Önerilen minimum süre 30 gündür. Bu ayar job düzeyinde değil repository düzeyinde tanımlanır.

Immutability Doğrulama Komutu

# Backup dosyalarının immutability durumunu toplu kontrol
find /backup/veeam -name "*.vbk" -o -name "*.vib" | \
  xargs lsattr 2>/dev/null | grep "\-i\-"

# Immutable olmayan backup dosyası var mı? (boş çıktı = sorun var)
find /backup/veeam -name "*.vbk" | \
  xargs lsattr | grep -v "\-i\-"
    

⚠️

Root erişimini kısıtlayın: Hardened repository sunucusunda root SSH girişi kapatılmalıdır. Yönetim işlemleri için ayrı bir yönetici hesabı ve sudo kullanın. Root erişimi olan bir hesap chattr -i ile kilidi kaldırabilir, bu da immutability'yi anlamsız kılar.

05

Diğer Platform Implementasyonları: NetApp SnapLock, ExaGrid, IBM

Immutable backup yalnızca AWS S3 veya Veeam'e özgü değildir. Kurumsal depolama platformlarının büyük çoğunluğu WORM implementasyonları sunar.

NetApp SnapLock

NetApp ONTAP'ın WORM çözümüdür. WORM volume oluşturulur ve bu volume üzerindeki dosyalar commit edildikten sonra değiştirilemez. İki modu vardır:

SnapLock Enterprise

Yönetilebilir — belirli koşullarda silme mümkün

✅ Privileged delete ile sona erdirilebilir
✅ Saklama süresi değiştirilebilir (yalnızca uzatma)
✅ İç politikalar ve esneklik için uygun

SnapLock Compliance

Katı — NetApp dahil kimse silemez

🔒 Volume başlatıldıktan sonra mod değiştirilemez
🔒 NetApp destek dahil kimse silemez
✅ SEC 17a-4, FINRA gibi sıkı uyum için

# NetApp ONTAP CLI — SnapLock Compliance volume oluşturma
volume create -vserver svm1 -volume worm_backup \
  -aggregate aggr1 -size 10TB \
  -snaplock-type compliance

# Default retention süresi belirleme
volume snaplock modify -vserver svm1 -volume worm_backup \
  -default-retention-period 30days \
  -minimum-retention-period 7days \
  -maximum-retention-period 365days

# SnapLock durumunu kontrol
volume snaplock show -vserver svm1 -volume worm_backup
    

ExaGrid: Deduplication + WORM

ExaGrid'in yaklaşımı diğerlerinden farklıdır: backup'lar önce landing zone adı verilen değiştirilebilir bir alana yazılır (hız için), ardından retention lock süresince WORM alanına taşınır. Bu şekilde hem hızlı backup/restore hem de uzun vadeli immutability bir arada elde edilir. Veeam, Veritas ve Commvault ile native entegrasyon sunar.

IBM Object Storage (IBM COS)

IBM Cloud Object Storage, WORM policy'lerini bucket veya nesne düzeyinde destekler. IBM Aspera ile büyük veri transferlerini immutable olarak gerçekleştirebilirsiniz. IBM Spectrum Protect (eski TSM) ile entegre çalışarak on-premises ve hybrid senaryoları kapsar.

Platform	WORM Mekanizması	Esneklik	Uyum
NetApp SnapLock Enterprise	ONTAP volume WORM	Yüksek	Kurumsal iç politika
NetApp SnapLock Compliance	ONTAP volume WORM	Düşük	SEC, FINRA, KVKK
ExaGrid Retention Lock	Landing zone + WORM tier	Orta	Kurumsal uyum
IBM COS WORM	Object policy	Orta	Sektörel düzenleme

06

Ransomware Korumasında Immutable Backup'ın Rolü

Ransomware saldırıları artık yalnızca production verilerini şifrelemekle kalmıyor; tespit edilmeden önce backup'ları da hedef alıyor. Ortalama tespit süresi 21 gün olan ransomware operasyonlarında, saldırganlar genellikle önce backup sistemlerini devre dışı bırakıyor, ardından production'ı şifreler.

Ransomware Saldırı Zinciri ve Immutability Engellemesi

Gün 1-7 Keşif, lateral movement

→

Gün 8-14 Backup hedefleme, silme girişimi

→

Gün 15-21 Production şifreleme

          Immutable Backup
          Silme girişimi engellenir
        

→RESTORE

          Temiz Restore Noktası
          Gün 1 öncesi veri
        

Neden Geleneksel Backup Yetmez?

✗ Değiştirilebilir backup dosyaları: saldırgan yönetici yetkisi aldığında backup'ları şifreleyebilir
✗ Ağ paylaşımları (SMB/NFS): ransomware ağdaki tüm paylaşımlara erişir
✗ Aynı kimlik bilgileri: VBR ve backup storage aynı AD hesaplarıyla yönetiliyorsa tek bir ihlal yeterli
✗ Şifrelenmemiş backup: saldırgan verileri exfiltrate edebilir

Immutable Backup ile Korunan Senaryo

✓ Saldırgan backup dosyalarını silmeye çalışır — WORM/Object Lock reddeder
✓ Backup retention policy'si kısaltılmaya çalışılır — immutability period koruyor
✓ VBR sunucusu şifrelenir — cloud backup'a VBR dışından da erişilebilir
✓ 30 günlük immutable pencere saldırıyı kapsıyor — temiz restore noktası mevcut

🏆

Best practice — immutability süresi: Minimum 30 gün immutability period uygulayın. Bu süre, ortalama ransomware tespit penceresi (21 gün) üzerinde bir güvenlik tamponu sağlar. Kritik sistemler için 60-90 gün önerilebilir.

07

KVKK ve Kurumsal Uyum Açısından Önemi

Türkiye'de KVKK (Kişisel Verilerin Korunması Kanunu) kapsamında kişisel veri işleyen tüm kuruluşlar, bu verilerin güvenliğini teknik ve idari tedbirlerle sağlamakla yükümlüdür. Yedekleme verilerinin immutable tutulması bu yükümlülüğün kritik bir parçasını oluşturur.

KVKK Uyumu Açısından Immutability

📋

Denetim İzi

Verinin değiştirilmediğini ispatlama

KVKK denetimleri için değişmez kayıt

🔏

Veri Bütünlüğü

Kişisel verinin yedek kopyada sağlamlığı

KVKK Madde 12 teknik tedbir gereksinimi

🏦

BDDK

Bankacılık sektörü veri saklama

5-10 yıllık veri saklama zorunluluğu

🏥

Sağlık Verileri

Hasta kayıtlarının immutable saklanması

Sağlık Bakanlığı yönetmelikleri kapsamında

Veri Saklama Süresi ve Object Lock

BDDK, kamu kurumları ve finans sektörü için yasal veri saklama süreleri genellikle 5-10 yıl arasında değişmektedir. S3 Object Lock Compliance mode, bu gereksinimleri karşılamak için uygundur: retention period boyunca verinin değiştirilemeyeceğine dair kriptografik garanti sağlar.

# BDDK uyumlu 10 yıllık retention policy (JSON)
{
  "ObjectLockEnabled": "Enabled",
  "Rule": {
    "DefaultRetention": {
      "Mode": "COMPLIANCE",
      "Years": 10
    }
  }
}
    

ℹ️

Dikkat: KVKK aynı zamanda kişisel verilerin belirli bir süre sonunda silinmesini zorunlu kılabilir. Retention period ve silme politikalarını hukuk departmanınızla koordineli belirleyin. Compliance mode retention süresini kısaltamayacağınızı unutmayın.

08

3 Adımlı Test Prosedürü: Immutability Nasıl Doğrulanır?

Immutability yapılandırdınız, ama gerçekten çalışıyor mu? "Çalışıyor" demek yetmez; belgeli, tekrarlanabilir bir test prosedürü oluşturmalısınız. Aşağıdaki 3 katmanlı test prosedürü hem teknik doğruluk hem de uyum belgelendirmesi için kullanılabilir.

1

Restore Testi: Backup Gerçekten Restore Edilebiliyor mu?

Immutability'nin doğrulanan verinin doğru ve geri yüklenebilir olduğunu garantilemez; bu ayrı bir testtir. İlk adımda backup'ın gerçekten restore edilebilir olduğunu doğrulayın.

# S3'ten test restore — dosya indir ve hash doğrula
aws s3 cp s3://immutable-backup-bucket/backups/full-2026-06-04.vbk \
  /tmp/test-restore.vbk

# SHA-256 hash karşılaştır (orijinal hash ile eşleşmeli)
sha256sum /tmp/test-restore.vbk
sha256sum /backup/veeam/full-2026-06-04.vbk
          

Veeam ortamında: Home → Backups → [Repository] → [Job] → sağ tık → Verify. SureBackup ile otomatik restore doğrulama yapılandırabilirsiniz.

2

Silme Girişimi Testi: Backup Silinebiliyor mu?

Bu testte immutability period aktifken backup dosyasını silmeye çalışın. İşlemin başarısız olması beklenir. Başarılı olursa immutability düzgün yapılandırılmamış demektir.

# Linux hardened repository — silme girişimi (başarısız olmalı)
rm -f /backup/veeam/VMs/FullBackup-2026-06-04.vbk
# Beklenen çıktı: rm: cannot remove '...': Operation not permitted

# Immutability flag'ini doğrula
lsattr /backup/veeam/VMs/FullBackup-2026-06-04.vbk
# Beklenen: ----i--------e-- (i flag aktif)

# S3 Object Lock — silme girişimi (başarısız olmalı)
aws s3 rm s3://immutable-backup-bucket/backups/full-2026-06-04.vbk
# Beklenen: An error occurred (AccessDenied) ... Object is WORM protected

# S3 versioned delete marker ile silme girişimi
aws s3api delete-object \
  --bucket immutable-backup-bucket \
  --key backups/full-2026-06-04.vbk
# Beklenen: AccessDeniedException
          

✅

Sonuç belgelendirmesi: Bu test sonuçlarını tarih damgası, komut çıktısı ve error mesajlarıyla birlikte ekran görüntüsü veya log dosyası olarak kaydedin. KVKK/BDDK denetimlerinde bu belgeler kanıt olarak kullanılabilir.

3

Retention Doğrulama: Lock Süresi Doğru mu?

Retention period'un doğru ayarlandığını ve beklenen tarihe kadar lock'ın aktif olduğunu doğrulayın.

# S3 Object Lock retention bilgisini sorgula
aws s3api get-object-retention \
  --bucket immutable-backup-bucket \
  --key backups/full-2026-06-04.vbk

# Beklenen çıktı:
{
    "Retention": {
        "Mode": "COMPLIANCE",
        "RetainUntilDate": "2026-07-04T00:00:00+00:00"
    }
}

# Linux — immutability kaldırma girişimi (root ile, başarısız olmalı)
sudo chattr -i /backup/veeam/VMs/FullBackup-2026-06-04.vbk
# Veeam hardened repo'da bu komut izin vermez
# (Veeam, immutability period boyunca chattr -i'yi engeller)
          

Testi tamamladıktan sonra sonuçları kaydedin. Önerilen test sıklığı: yılda en az 2 kez, büyük değişiklikler sonrası (versiyon yükseltme, yeni repository ekleme vb.) ve DR tatbikatı öncesinde.

09

Yaygın Hatalar ve Yanlış Anlamalar

Yanlış Anlama	Gerçek Durum
"Şifreleme = immutability"	Hayır. Şifreleme veriye erişimi zorlaştırır, ama imha veya silmeyi engellemez. İkisi birbirini tamamlar, ikame değil.
"Offsite backup = immutable backup"	Hayır. Bir kopyanın farklı bir lokasyonda olması onu değiştirilemez yapmaz. Offsite + immutability birlikte uygulanmalıdır.
"S3 Governance mode yeterli"	Compliance gereksinimleri için genellikle değil. Governance mode, yetkili kullanıcı tarafından aşılabilir. Yasal uyum için Compliance mode gerekir.
"chattr +i root'u tamamen engeller"	Kısmen. OS seviyesinde engeller, ama donanıma doğrudan erişim (örn. rescue disk) bu korumayı atlayabilir. Fiziksel güvenlik şarttır.
"Immutability = silinmez veri (sonsuza kadar)"	Hayır. Retention period dolduğunda veri silinebilir. Immutability belirli bir süre için geçerlidir.
"Test etmek zorunda değilim, sistem yapılandırıldı"	Yanlış. Konfigürasyon hataları, versiyon farklılıkları ve donanım sorunları testi zorunlu kılar. Test edilmemiş immutability, hiç yoktan farkı yoktur.
"Veeam Hardened Repo = tam air-gap"	Kısmen. Hardened repo, ağ üzerinden erişimi kısıtlar ama tam air-gap değildir. Gerçek air-gap için tape veya fiziksel izolasyon gerekir.

🚨

En kritik hata: S3 bucket oluştururken Object Lock'ı etkinleştirmeyi unutmak. Object Lock, bucket oluşturulurken aktive edilmelidir; sonradan açılamaz. Mevcut bucket'a Object Lock eklemek için AWS Support müdahalesi gerekir ve her zaman mümkün değildir.

10

Karşılaştırma Tablosu: WORM vs Object Lock vs Hardened Repo

Özellik	WORM (Donanım)	S3 Object Lock Governance	S3 Object Lock Compliance	Veeam Hardened Linux Repo	NetApp SnapLock Compliance
Silme engeli	✓ Donanım	Yetkili bypass	✓ Mutlak	✓ Yazılım	✓ Mutlak
Root/Admin bypass	✗ Mümkün değil	Mümkün (izinle)	✗ Mümkün değil	Kısmi (fiziksel)	✗ Mümkün değil
Retention yönetimi	Sabit/değiştirilemez	Uzatılabilir/kısaltılabilir	Yalnızca uzatılabilir	Job bazlı, değiştirilebilir	Yalnızca uzatılabilir
Kurulum maliyeti	Yüksek	Düşük (bulut)	Düşük (bulut)	Düşük (Linux sunucu)	Yüksek (NetApp)
Operasyonel esneklik	Düşük	Yüksek	Düşük	Orta	Düşük
KVKK/BDDK uyumu	✓	Kısmi	✓	✓	✓
Ransomware koruması	Güçlü	Orta	Güçlü	Güçlü	Güçlü
Air-gap	Fiziksel	Mantıksal	Mantıksal	Kısmi	Mantıksal
Desteklenen backup yazılımı	Çoğu	Çoğu	Çoğu	Yalnızca Veeam	Çoğu
Test kolaylığı	Orta	Kolay	Orta	Kolay	Orta

Hangi Senaryoda Ne Kullanılmalı?

🏢

Veeam + On-Prem

Hardened Linux Repository

Düşük maliyet, hızlı kurulum, Veeam native

☁️

AWS/Bulut Yedekleme

S3 Object Lock Compliance

Yasal uyum gereksinimleri için

🏦

Finans/Bankacılık

NetApp SnapLock Compliance

BDDK, uzun vadeli saklama zorunluluğu

🔬

Test/Geliştirme

S3 Object Lock Governance

Esneklik, hata durumunda geri alabilme

11

Kaynaklar ve Referanslar

→ AWS S3 Object Lock Kullanım Kılavuzu: docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html
→ Veeam Hardened Linux Repository: helpcenter.veeam.com/docs/backup/vsphere/hardened_repository.html
→ NetApp SnapLock Overview: docs.netapp.com/us-en/ontap/snaplock/index.html
→ KVKK Kişisel Veri Güvenliği Rehberi: kvkk.gov.tr/Icerik/6649/Kisisel-Veri-Guvenliği-Rehberi
→ Veeam 3-2-1-1-0 Backup Rule: veeam.com/blog/how-implement-3-2-1-1-0-data-protection-rule.html
→ ExaGrid Retention Time-Lock: exagrid.com/products/tiered-backup-storage/retention-time-lock
→ IBM Cloud Object Storage WORM: cloud.ibm.com/docs/cloud-object-storage/immutable.html
→ Veeam SureBackup (Otomatik Restore Doğrulama): helpcenter.veeam.com/docs/backup/vsphere/surebackup_job.html

diabolikss.com

Immutable Backup Stratejisi Danışmanlığı

Kurumunuz için doğru immutability çözümünü seçmek, yapılandırmak ve test etmek konusunda destek almak ister misiniz? WORM implementasyonu, Veeam Hardened Repository kurulumu ve KVKK uyumu konularında danışmanlık için iletişime geçin.

✉ İletişim 📚 Tüm Rehberler

immutable-backup WORM S3 Object Lock Veeam ransomware KVKK NetApp SnapLock backup güvenliği

↑ Başa Dön