Veeam Immutability için S3 Uyumlu Depolama: Sağlayıcı Matrisi

Her S3-compatible sağlayıcı Veeam backup'larını immutable yapabilir mi?

S3 uyumluluğu tek başına Veeam immutability desteği anlamına gelmez. Gereken API işlemlerini, veri tutarlılığı modelini, bucket ayarlarını ve test edilen ürün/build birleşimini kontrol edin. Amazon S3, Backblaze B2, Wasabi ve MinIO AIStor Object Lock'u belgeliyor. Cloudflare R2'nin bucket lock özelliği S3 Object Lock API'sini sağlamıyor. API kontrolü geçse bile backup ve restore ayrıca test edilmeli.

Veeam bir "S3-compatible" endpoint'ten gerçekte ne ister

Aşağıdaki Veeam davranışı Veeam Backup & Replication 13 build 13.1.1.18 için sabitlenmiştir. Sağlayıcı qualification kayıtlarının kendi test build'leri vardır; matriste ayrı gösterilir. v13 etiketi, tam olarak bu build'in test edildiğinin kanıtı değildir.

Temel gereksinim. Veeam uyumlu AWS S3 işlemleri ve Signature Version 4 ister; eventual-consistency depolamayı desteklemez. Veeam aynı sayfada S3UseMd5ContentHash ayarını, SHA-256 gereksinimini karşılayamayan endpoint'ler için MD5 uyumluluk seçeneği olarak anlatıyor. Linux'ta /etc/VeeamAgentConfig, Windows'ta registry değeri kullanılır; ayar o backup server'daki tüm S3-compatible hedefleri etkiler. Signature Version 4 yine HMAC-SHA256 kullanır; bu ayarı kimlik doğrulama algoritmasını MD5'e çeviriyormuş gibi anlatmayın. Değiştirmeden önce sunucu genelindeki etkisini inceleyin.

Immutability sözleşmesi. Veeam'in Enabling Immutability sayfası bir S3 bucket'ı için dört şart sayıyor ve dördünün aynı anda sağlanması gerekiyor:

1. Bucket'ta Object Lock açık olmalı. Veeam burada asıl işe yarayan uyarıyı da ekliyor: "çoğu sağlayıcı Object Lock'u yalnızca bucket'ın oluşturulduğu anda açmaya izin verir."
2. Default retention kapalı olmalı. Bu bir tercih değil, şart. Nedenini aşağıdaki hata biçimlerinde göreceksiniz.
3. Bucket'ta versioning açık olmalı.
4. New Object Storage Repository sihirbazının Bucket adımında immutability kutusu işaretlenmeli.

Amazon S3 için Veeam Compliance modunu açıkça belgeler. Bu cümleyi her S3-compatible entegrasyona genellemeyin: qualification kayıtlarında Governance desteği ayrıca bulunabilir; uygulanan davranışı sağlayıcı ve build için kontrol etmek gerekir. AWS Governance, sıradan kimliklere karşı korur; gereken yetki ve başlıkla yetkili bypass'a izin verir. Compliance korunan sürüm için bu bypass yolunu kaldırır.

Veeam izin sayfası, S3 API işlem adlarının bire bir listesini değil, gereken IAM action'larını verir. Tek bucket kullanan immutable S3-compatible senaryoda nesne okuma/yazma/silme, sürüm listeleme ve okuma, retention ve legal hold okuma/yazma, sürüm silme bulunur. Gerçek senaryonun güncel politikasını kullanın; S3-compatible multiple-bucket modu ayrıca bucket oluşturma ve silme yetkisi ister.

Veeam desteklenen temizlik için s3:DeleteObjectVersion ister; tüm silmeyi yasaklamak Object Lock'un yerini tutmaz. s3:GetBucketObjectLockConfiguration, immutable olmayan politikada da bulunur. Eksik yetki keşfi engelleyebilir, fakat hatanın desteklenmeyen API hatasıyla aynı olacağı garanti değildir. Yetkileri sağlayıcı rehberine göre onaylı kaynaklarla sınırlandırın; hata kaybolacak mı diye üretime wildcard politika yapıştırmayın. Backblaze, S3 işlemlerini application key capabilities ile eşliyor; retention okuma/yazma ve bypassGovernance ayrı izinler. Bucket ile sınırlı B2 anahtarında bunları kontrol edin. AWS IAM action listesi, B2 anahtarının bire bir ayarı değildir.

Block Generation ve seçilen retention modu için bütçe ayırın. Varsayılanlar çoğu türde 10 gün; Amazon S3, IBM Cloud, Google Cloud ve 11:11'de 30 gündür. Minimum 30 gün ve generation 10 gün, Veeam örneğinde generation başlangıcındaki 40 günlük kilidi açıklar; her nesne için evrensel 40 günlük fatura penceresi değildir.

Sağlayıcı matrisi: 24 Eylül 2026 kontrolü

Tabloda seçilmiş altı seçenek var. Sağlayıcı dokümanı Object Lock davranışını, Veeam Ready kaydı ise Veeam'in test ettiği build, region ve yapılandırmayı gösterir. Karar vermeden önce ikisini de kendi kurulumunuzla karşılaştırın.

Bulut sağlayıcısı API'sini Veeam Ready kaydı değişmeden güncelleyebilir. Kendi işlettiğiniz yazılımda Veeam build'iyle birlikte kurulu release'i ve donanımı da listedeki testle karşılaştırın.

Qualification kapsamını topolojiyle birlikte okuyun. Capacity Target kategorisi ikincil object storage hedefini tanımlar. VBR 13, object repository'leri doğrudan job hedefi ve performance tier extent'i olarak da kullanabilir. Capacity Target kaydı, planladığınız direct-to-object veya performance tier akışının test edildiğini tek başına göstermez. Kuracağınız topolojiyi ayrıca doğrulayın.

Wasabi'de iki farklı Compliance var. Wasabi'nin bucket düzeyindeki Compliance özelliği ile S3 Object Lock birbirini dışlar. Object Lock içindeki Compliance mode ayrı bir ayardır. Veeam Object Lock entegrasyonu için Object Lock açık bucket oluşturun ve Veeam'in istediği gibi bucket default retention'ı kapalı bırakın.

Açılan kayıtta v13 bulunmaması, o kaydın v13 qualification'ını kanıtlamadığı anlamına gelir. Üreticinin başka hiçbir kaydı olmadığının kanıtı değildir. Seçimi belgelerken qualification kategorisini, özellikleri, test build'ini, bölgeyi ve donanımı birlikte kaydedin.

Cloudflare R2: bucket lock, S3 Object Lock değildir

R2, S3-compatible endpoint sunduğu için depolama karşılaştırmalarında sık görünür. Veeam immutability için ayrıca versioning ve tek tek object version'larında retention ister; normal nesne okuma/yazma işlemleri bunların yerini tutmaz.

Cloudflare'in S3 uyumluluk tablosu, ilgili versioning ve Object Lock API'lerini desteklenmiyor olarak gösterir. Bucket lock'lar Cloudflare'in kendi yönetim arayüzünden uygulanan retention kurallarıdır. Veeam'in yönettiği sürüm bazlı S3 Object Lock değildir. Bu fark, burada ele alınan immutable Veeam hedefi için R2'yi elemek için yeterlidir; immutable olmayan her akışın desteklendiğini göstermez.

Yedekleme uygulamasının altına dışarıdan retention kuralı koymak, uygulamanın temizliğini de engelleyebilir. Veeam, repository verisini kendisinin yönetmesini ister. Buluta özel lock kurallarını eksik Object Lock API'sinin çözümü değil, ayrı entegrasyon konusu olarak değerlendirin.

Kontrollü kabul testinden önce endpoint'i inceleyin

Bash ve AWS CLI v2 ile salt okunur incelemeyle başlayın. İnceleme profilini, tam bölgeyi, HTTPS endpoint'i, bucket'ı ve bilinen Veeam veri prefix'ini ayarlayın. Bu komutlar bucket oluşturmaz, retention değiştirmez ve veri silmez. Mevcut sürümleri örnekler; sağlayıcıyı sertifikalandırmaz.

# Bash + AWS CLI v2. Set these to the approved read-only target first.
(
  set -eu
  : "${S3_PROFILE:?Set the inspection profile}"
  : "${S3_REGION:?Set the provider region}"
  : "${S3_ENDPOINT:?Set the HTTPS S3 endpoint}"
  : "${S3_BUCKET:?Set the bucket}"
  : "${S3_PREFIX:?Set a known Veeam data prefix}"
  case "$S3_ENDPOINT" in https://*) ;; *) exit 1 ;; esac
  aws --profile "$S3_PROFILE" --region "$S3_REGION" \
    --endpoint-url "$S3_ENDPOINT" s3api get-bucket-versioning --bucket "$S3_BUCKET"
  aws --profile "$S3_PROFILE" --region "$S3_REGION" \
    --endpoint-url "$S3_ENDPOINT" s3api get-object-lock-configuration --bucket "$S3_BUCKET"
  aws --profile "$S3_PROFILE" --region "$S3_REGION" \
    --endpoint-url "$S3_ENDPOINT" s3api list-object-versions \
    --bucket "$S3_BUCKET" --prefix "$S3_PREFIX" --max-items 20 --page-size 20
)

Status: Enabled, ObjectLockEnabled: Enabled ve Rule.DefaultRetention bulunmamasını kontrol edin. Sürüm listesi sınırlı örnektir; en yeni nesneyi otomatik seçmez. Versions altından bilinen yedek veri nesnesini seçin; DeleteMarkers kaydını veya değişebilir metadata'yı değil. Eşleşen veri sürümü yoksa prefix'i ve backup durumunu netleştirin; doğrudan immutability bozuk sonucuna varmayın.

# Select Key and VersionId from the same Versions entry, not DeleteMarkers.
(
  set -u
  : "${S3_PROFILE:?}" "${S3_REGION:?}" "${S3_ENDPOINT:?}" "${S3_BUCKET:?}"
  : "${S3_KEY:?Set the exact data-object key}"
  : "${S3_VERSION_ID:?Set its exact VersionId}"
  case "$S3_ENDPOINT" in https://*) ;; *) exit 1 ;; esac
  case "$S3_VERSION_ID" in None|null|NULL|\<*) exit 1 ;; esac
  # İkisini ayrı sorgula: retention cevabı gelmese de legal hold kontrolü atlanmamalı.
  for op in get-object-retention get-object-legal-hold; do
    aws --profile "$S3_PROFILE" --region "$S3_REGION" \
      --endpoint-url "$S3_ENDPOINT" s3api "$op" \
      --bucket "$S3_BUCKET" --key "$S3_KEY" --version-id "$S3_VERSION_ID" \
      || echo "$op: no answer; record it as unresolved"
  done
)

Komut referansları: get-bucket-versioning, get-object-lock-configuration, list-object-versions, get-object-retention ve get-object-legal-hold. Retention ile legal hold bağımsızdır: aynı version için mode, RetainUntilDate ve hold durumunu kaydedin. Retention yanıtı boş diye legal hold olmadığını varsaymayın. Eksik yetki, yanlış version veya desteklenmeyen API incelemeyi başarısız kılabilir; sonucu başarılı kilit testi değil, çözümlenmemiş durum sayın.

Silme içeren kabul testi için ayrı üretim dışı bucket ve production'a erişemeyen özel kimlik bilgileri kullanın. Yalnızca testin oluşturduğu sürümleri hedefleyin, hedef manifesti tutun, boş/None/null sürüm kimliklerini reddedin. Yetki için pozitif kontrol kurun: kilitli silme veya kısaltma reddini yorumlamadan önce aynı kimlik kilitsiz bir sürümü silebilmeli ve ayrı kontrol sürümünün retention'ını uzatabilmeli. Ret sebebi olabilecek explicit policy ve legal hold'ları da inceleyin. AWS'te version ID olmadan basit delete, delete marker ekler; korunan sürümün silinmesini test etmez. Compliance test nesneleri süre dolana kadar silinemeyebilir ve ücret doğurabilir; legal hold bu süreyi daha da uzatabilir. Tek ret yanıtı kanıt değildir; kurulumun başarısız olması da sağlayıcının desteği olmadığını tek başına göstermez.

Hedef build ve topolojide gerçek Veeam backup, retention temizliği ve restore testiyle tamamlayın. API davranışı tek başına seçilen build ve topolojide tüm Veeam akışının başarılı olduğunu göstermez. Veeam, tek object storage repository'sinin birden fazla VBR sunucusunda kullanılmasını da yasaklıyor; öngörülemeyen davranış ve veri kaybı uyarısı veriyor. Çok sunuculu tasarımın testinden önce her repository'yi tek bir backup sunucusuna atayın.

Object Lock destek hatasını teşhis edin

Sağlayıcıyı değiştirmeden önce yapılandırmayı, yetkilendirmeyi ve API uyumluluğunu ayırın. Aşağıdakiler kontrol listesidir; görülme sıklığı sıralaması değildir:

1. Bucket kurulumu: Object Lock ve versioning, bucket Veeam'e eklenmeden hazırlanmalı. AWS ve Backblaze mevcut bucket'ta Object Lock açabilir. Veeam ise altyapıdaki bir bucket'ta Object Lock veya versioning'i açıp kapatmanın öngörülemeyen davranışa ve veri kaybına yol açabileceği konusunda uyarıyor. Sağlayıcının izin verdiği işlem, Veeam repository'si için güvenli bir retrofit prosedürü sayılmaz.
2. Default retention/lifecycle: Veeam default retention'ın kapalı olmasını ister; yedek verisini S3 lifecycle kurallarıyla yönetmeyi desteklemez.
3. Yetkiler: gerçek senaryoyu Veeam'in yayımladığı izinlerle karşılaştırın. İstek/hata kanıtını alın; access-denied yanıtı, uygulanmamış API yanıtı değildir.
4. Endpoint/API: bölgeyi, imza uyumunu, gereken işlemleri ve consistency'yi doğrulayın. Eski yedekler için versioning ve Object Lock'u aynı anda açma talimatı özellikle 9.5 Update 4 bucket'ları içindir; genel retrofit prosedürü değildir.

Bu matris size neyi söylemez

Bu tablo 24 Eylül 2026'da kontrol edildi. Üretime almadan önce kullanacağınız region ve release için Veeam Ready kaydını ve sağlayıcı dokümanını yeniden okuyun.

Salt okunur retention metadata'sı yalnızca o endpoint'in örneklenen sürümler için bildirdiğini gösterir. Kontrollü API reddi bir kimliği ve işlemi sınar. İkisi de sağlayıcı yöneticilerinin API altında müdahale edemediğini, her yedek nesnesinin korunduğunu veya şifreleme anahtarlarıyla hesap erişiminin kalacağını kanıtlamaz. Sağlayıcının belgelenmiş güven sınırını alın, kurtarmayı bağımsız test edin.

Veeam Ready, listelenen test kapsamına dair yararlı kanıttır. Desteklenen yapılandırmanın, güncel üretici desteğinin veya kendi restore ve temizlik testlerinizin yerini tutmaz. Qualification ile API kabulü farklı soruları cevaplar.

BackupSec bu işe nasıl bakıyor

ZeroVault, Veeam Backup & Replication için S3-compatible, Object Lock destekli yönetilen depolama hizmetimizdir. BackupSec adına bir Veeam Ready kaydı yok; bizim sözümüz de onun yerini tutmaz. Region'ınızda hangi Object Lock modunun ve retention süresinin uygulandığını bize sorun, sonra yukarıdaki salt okunur kontrolleri gerçek bir nesne sürümü üzerinde, başka herhangi bir sağlayıcıda yapacağınız gibi çalıştırın.

ZeroMON, repository'nin immutability ayarını Veeam'den okur ve değişiklikte uyarır. Depolanan her nesnenin retention'ını sorgulamaz. Bu uyarıları yukarıdaki nesne seviyesi kontrollerle birlikte değerlendirin.