Mimari ve çalışma modeli
Object Lock veya WORM politikası, belirli bir nesne sürümünün saklama süresi dolmadan silinmesini ya da değiştirilmesini engeller. Bu özellik yedekleme işinin başarılı çalıştığını, verinin uygulama açısından tutarlı olduğunu veya hesabın ele geçirilmediğini tek başına kanıtlamaz. Değiştirilemez hedef; bağımsız kimlik, sürümleme, geri yükleme testi ve katalog korumasıyla birlikte değerlendirilmelidir.
AWS S3 Object Lock sürümlü nesnelerde governance ve compliance saklama kipleri ile legal hold sunar. Google Cloud Bucket Lock, bucket retention policy kilitlendiğinde süreyi geri alınamaz biçimde uygular. Azure immutable blob storage zaman bazlı retention ve legal hold politikaları sağlar. İsimler benzer olsa da kapsam, kilitleme anı, uzatma/kısaltma, hesap silme sınırı ve desteklenen nesne türleri aynı değildir.
Governance benzeri kipler yetkili bypass işlemine izin verebilir; compliance/kilitli politikalar daha güçlü fakat yanlış süre seçiminde maliyet ve mevzuat riski yaratır. Politika açmadan önce kısa pilot bucket/container, test verisi ve kontrollü silme denemesi kullanın. Üretim retention süresini yedek yazılımının sentetik full, merge, prune ve katalog davranışıyla uyumlu doğrulayın.
- 1Yedek işi
- 2Sürümlü nesne
- 3Retention veya legal hold
- 4Bağımsız restore doğrulaması
Tasarım parametreleri
- Saklama birimi
- Politikanın bucket/container mı yoksa nesne sürümü mü üzerinde uygulandığını ve yeni sürüm oluşturma davranışını doğrulayın.
- Yetki ayrımı
- Yedek yazan kimlik ile retention değiştiren ve hesabı yöneten kimlikleri ayırın.
- Yaşam döngüsü
- Tier geçişi ve otomatik silme kuralının kilitli nesnelerde nasıl ertelendiğini maliyet hesabına ekleyin.
- Kurtarma yolu
- Katalog, şifreleme anahtarı ve restore hesabının aynı yönetim alanına bağımlı olmadığını test edin.
Hesap ve uygulama örneği
Günlük 2 TB değişim ve 30 gün kilit için sıkıştırma öncesi 60 TB yeni veri oluşur. %40 ölçülmüş azaltma varsayımıyla yaklaşık 36 TB tutulur; ancak tam kopyalar, sürüm ek yükü, API çağrıları ve erken silinemeyen hatalı işler ayrıca hesaplanmalıdır. Oranı laboratuvar sonucu olmadan bütçeye sabitlemeyin.
Pilot verisini 7 gün retention ile yazın. Normal silme kimliği, yüksek yetkili yönetici ve yaşam döngüsü kuralıyla silmeyi deneyin; sonra izole hesaba gerçek restore yapın. Sadece konsolda kilit simgesi görmek kabul testi değildir.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
# AWS örneği; hesap, bucket ve tarih değerlerini pilotta değiştirin.
aws s3api get-object-lock-configuration --bucket doz-backup-pilot
aws s3api head-object --bucket doz-backup-pilot --key sample.bin
# GCS/Azure için eşdeğer retention durumunu kendi resmi CLI çıktısıyla kaydedin.Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Prune işi sürekli hata veriyor | Yedek yazılımı kilitli sürümleri süre dolmadan silmeye çalışıyor olabilir. | İş logundaki object version ve retain-until değerini karşılaştırın; retention'ı geriye çekmeye çalışmayın. |
| Maliyet beklenenden hızlı büyüyor | Kilitli eski sürümler ve başarısız iş kalıntıları yaşam döngüsüyle silinemiyor olabilir. | Yaş, sürüm ve retention durumuna göre byte envanteri çıkarın. |
| Kilit var ama hesap kaybında restore yapılamıyor | Anahtar, katalog veya erişim rolü aynı hesapta kalmış olabilir. | Üretim yönetim kimliği olmadan restore tatbikatı yapın. |
Kabul ve doğrulama kontrolleri
- Sürümlendirme ve retention'ın yeni nesnelerde gerçekten uygulandığını gösterin.
- Yetkisiz ve yetkili silme denemelerinin sonucunu kaydedin.
- Saklama süresini uzatma ve yanlışlıkla kısaltma davranışını test edin.
- Yedek yazılımının prune/merge işlemlerini pilotta çalıştırın.
- Bağımsız hesap ve anahtarla örnek restore yapın.
- Kilitli byte miktarı ve tahmini maliyet için alarm kurun.
İlgili kavramlar
Değiştirilemezlik ve silme yetkisi
Immutable saklama, belirlenen süre içinde verinin değiştirilmesini veya silinmesini sınırlayan bir kontrol mekanizmasıdır. Uygulamanın verdiği söz, depolama katmanındaki zorunlu koruma ve fiziksel izolasyon aynı şey değildir. Kilit süresi, saat yönetimi, yönetici yetkileri ve veri silme yolu birlikte incelenmelidir. Süre dolunca verinin otomatik silinip silinmediği de ürün politikasına bağlıdır. Kontrollü bir test kopyası üzerinde normal ve ayrıcalıklı hesapla silme denemesi yapın; ardından korunan kopyadan geri dönüşü doğrulayın. Koruma, okunabilirlik testinin yerine geçmez.
Saklama politikası ve kapasite
Retention, hangi kurtarma noktalarının ne kadar süre tutulacağını tanımlar. Günlük, haftalık ve aylık noktalar aynı veri değişim oranını temsil etmez; tam kopya üretme şekli ve zincir bağımlılığı fiziksel kapasiteyi değiştirir. Saklama kararı, iş gereksinimi ve geçerli yükümlülükler ile teknik kapasitenin birlikte değerlendirilmesini gerektirir. Daha uzun saklama, otomatik olarak daha iyi kurtarma anlamına gelmez: doğru noktanın bulunması ve okunabilmesi gerekir. Politika değiştirildiğinde mevcut noktaların hemen silinip silinmediğini ürün davranışı üzerinden sınayın.
Kalıcılaştırma ve güç kaybı
Commit edilmiş verinin güç kaybından sonra korunması veritabanı, işletim sistemi, dosya sistemi, kontrolcü ve diskin yazma garantilerinin birleşimine bağlıdır. Yazma önbelleği ve flush davranışını bilmeden performans için güvenlik ayarlarını kapatmayın. Güç kaybı korumalı depolama faydalıdır fakat bütün zincirin doğru yapılandırıldığını tek başına kanıtlamaz. Üretim yerine kontrollü laboratuvarda arıza ve recovery testi yapın. Veri bütünlüğünü örnek dosya açılmasıyla değil, uygulama kayıtları ve desteklenen tutarlılık kontrolleriyle doğrulayın.
Dosya izinleri ve servis kimliği
Dosya erişimi kullanıcı/grup, izin bitleri, ACL ve güvenlik politikalarının birleşimine bağlıdır. Bir uygulamanın root olarak çalışması izin sorununu gizleyebilir; üretim için gerekçeli ve sınırlı servis kimliği tercih edilir. Dizin üzerinde arama/geçiş izni ile dosya okuma izni farklıdır. Paylaşım katmanında verilen izin, dosya sistemindeki kısıtı her zaman aşmaz. Hata araştırmasında uygulamanın gerçekten hangi kullanıcıyla çalıştığını, dizin zincirini ve ACLleri inceleyin. İzinleri topluca açmak yerine gereken erişimi dar kapsamda test edin.
Maliyet ölçümünün sınırı
Maliyeti yalnız satın alma veya aylık kaynak bedeli olarak görmeyin. Lisans kapsamı, depolama, veri çıkışı, yedekleme, destek, işletim emeği ve arıza etkisi farklı kalemlerdir. Hesap için aynı hizmet seviyesi, kapasite ve süreyi kullanın; ucuz görünen seçenek başka bir yükümlülüğü dışarıda bırakıyor olabilir. Tahmin ile gerçekleşeni kaynak veya iş birimi bazında karşılaştırın. Taahhütlü modelde kullanım azalması, esnek modelde ise kontrolsüz büyüme riskini değerlendirin. Fiyat ve lisans koşullarını karar günündeki resmî belgelerden doğrulayın.
RPO ve gerçek veri kaybı penceresi
RPO, olay sonrasında kabul edilebilecek veri kaybı süresidir. Yedek zamanlaması tek başına RPO kanıtı değildir; işin başarısız olması veya kopyanın karşı merkeze geç ulaşması pencereyi büyütebilir. Olay anı ile kullanılabilir son tutarlı kurtarma noktasının zamanını karşılaştırın. Örneğin olay 14.00'te, doğrulanmış kopya 13.20'deyse o testteki veri kaybı penceresi 40 dakikadır. Hedefi uygulama bazında belirleyin: dosya arşivi ile sürekli sipariş alan veritabanının gereksinimleri aynı olmayabilir.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.