Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
Azure Blob Depolama için sabit depolama özelliği kullanıcıların iş açısından kritik verileri WORM (Bir Kez Yazma Çok Kez Okuma) durumunda depolamasını sağlar. WORM durumundayken, kullanıcı tarafından belirtilen bir aralık için veriler değiştirilemez veya silinemez. Blob verileri için değişmezlik ilkelerini yapılandırarak verilerinizi üzerine yazma ve silme işlemlerine karşı koruyabilirsiniz.
Azure Blob Depolama için değişmez depolama, iki tür değişmezlik ilkesini destekler:
Zamana dayalı saklama ilkeleri: Kullanıcılar zamana bağlı saklama ilkesiyle, belirli bir aralıkta verileri depolamak için ilkeler ayarlayabilir. Zamana bağlı saklama ilkesi ayarlandığında, nesneler oluşturulabilir ve okunabilir, ancak değiştirilemez veya silinemez. Bekletme süresi dolduktan sonra nesneler silinebilir ancak üzerine yazılamaz.
Hukuki bekletme politikaları: Hukuki bekletme, hukuki bekletme kaldırılana kadar değiştirilemez verileri saklar. Yasal tutma ayarlandığında, nesneler oluşturulabilir ve okunabilir, ancak değiştirilemez veya silinemez.
Bu ilkeler birbiriyle aynı anda ayarlanabilir. Örneğin, bir kullanıcının hem zamana dayalı saklama ilkesi hem de aynı düzeyde ve aynı anda ayarlanmış bir yasal saklama ilkesi olabilir. Bir yazma işleminin başarılı olması için ya sürüm oluşturma özelliği etkin olmalı ya da veriler üzerinde ne bir yasal saklama ne de zamana bağlı bir saklama politikası bulunmalıdır. Silme işleminin başarılı olması için veriler üzerinde yasal saklama veya zamana bağlı saklama ilkesi de bulunmamalıdır.
Aşağıdaki diyagramda, zamana bağlı saklama ilkelerinin ve yasal tutmaların etkin oldukları sırada yazma ve silme işlemlerini nasıl önlediği gösterilmektedir.
Sabit depolama şemsiyesinin altında iki özellik vardır: kapsayıcı düzeyinde WORM ve sürüm düzeyinde WORM. Kapsayıcı düzeyinde WORM ilkelerin yalnızca kapsayıcı düzeyinde ayarlanmasına izin verirken, sürüm düzeyi WORM ilkelerin hesap, kapsayıcı veya sürüm düzeyinde ayarlanmasına izin verir.
Bloblar için sabit depolama hakkında
Sabit depolama, sağlık kuruluşlarının, finans kurumlarının ve ilgili sektörlerin (özellikle aracı bayi kuruluşları) verileri güvenli bir şekilde depolamasına yardımcı olur. Sabit depolama, kritik verileri değişiklik veya silmeye karşı korumak için herhangi bir senaryoda kullanılabilir.
Tipik kullanım alanları şunlardır:
Mevzuat uyumluluğu: Azure Blob Depolama için sabit depolama, kuruluşların SEC 17a-4(f), CFTC 1.31(d), FINRA ve diğer düzenlemeleri ele alınmasına yardımcı olur.
Güvenli belge saklama: Bloblar için sabit depolama alanı, hesap yönetim ayrıcalıklarına sahip kullanıcılar tarafından bile verilerin herhangi bir kullanıcı tarafından değiştirilmemesini veya silinemediğini güvence altına alır.
Yasal tutma: Bloblar için değişmez depolama, kullanıcıların dava veya iş kullanımı açısından önemli hassas bilgileri, yasal tutma kaldırılana kadar istenen süre boyunca kurcalamaya karşı dayanıklı bir durumda depolamasına olanak tanır. Bu özellik yalnızca yasal kullanım örnekleriyle sınırlı değildir, aynı zamanda olay tetikleyicilerine veya şirket ilkesine göre verileri koruma gereksiniminin gerekli olduğu olay tabanlı ayrı tutma veya kurumsal kilit olarak da düşünülebilir.
Mevzuata uyumluluk
Microsoft, bloblar için sabit depolamayı değerlendirmek ve finansal hizmetler sektörüne özgü gereksinimlerle uyumluluğunu değerlendirmek için kayıt yönetimi ve bilgi idaresi konusunda uzmanlaşmış önde gelen bir bağımsız değerlendirme firması olan Cohasset Associates'i elinde tutmaktadır. Cohasset, blobları WORM durumunda tutmak için kullanıldığında sabit depolamanın CFTC Kuralı 1.31(c)-(d), FINRA Kuralı 4511 ve SEC Kuralı 17a-4(f) ile ilgili depolama gereksinimlerini karşıladığını doğrulamıştır. Microsoft, finansal kurumlar için kayıt saklama konusunda küresel olarak en açıklayıcı kılavuzu temsil ettiğinden bu kurallar kümesini hedeflemektedir.
Cohasset raporu Microsoft Hizmet Güven Merkezi'nde kullanılabilir. Azure Güven Merkezi, Microsoft'un uyumluluk sertifikaları hakkında ayrıntılı bilgiler içerir. MICROSOFT'tan WORM değişmezliği uyumluluğuyla ilgili bir kanıtlama mektubu istemek için lütfen Azure Desteği'ne başvurun.
Zamana bağlı saklama ilkeleri
Zamana bağlı saklama ilkesi blob verilerini belirtilen bir aralık için WORM biçiminde depolar. Zamana bağlı saklama ilkesi ayarlandığında, istemciler blob oluşturabilir ve okuyabilir, ancak bunları değiştiremez veya silemez. Bekletme aralığının süresi dolduktan sonra bloblar silinebilir ancak üzerine yazılamaz.
Kapsam
Zamana bağlı saklama ilkesi aşağıdaki kapsamlarda yapılandırılabilir:
- Sürüm düzeyinde WORM ilkesi: Hesap, kapsayıcı veya sürüm düzeyinde zamana bağlı saklama ilkesi yapılandırılabilir. Hesap veya kapsayıcı düzeyinde yapılandırılmışsa ilgili hesap veya kapsayıcıdaki tüm bloblar tarafından devralınır. Bir kapsayıcıda yasal bir saklama varsa, aynı kapsayıcı için Sürüm düzeyinde WORM oluşturulamaz. Bunun nedeni sürümlerin yasal bekletme kararı nedeniyle oluşturulamamasıdır.
- Kapsayıcı düzeyinde WORM ilkesi: Kapsayıcı düzeyinde yapılandırılan zamana bağlı saklama ilkesi, bu kapsayıcıdaki tüm bloblar için geçerlidir. Tek tek bloblar kendi değiştirilemezlik ilkeleriyle yapılandırılamaz.
Zamana bağlı bir ilke için bekletme aralığı
Zamana bağlı saklama ilkesi için en düşük saklama aralığı bir gündür ve en fazla 146.000 gündür (400 yıl). Zamana bağlı saklama ilkesi yapılandırdığınızda, etkilenen nesneler etkin saklama süresi boyunca sabit durumda kalır. Nesneler için geçerli saklama süresi, blob oluşturma süresi ile kullanıcı tarafından belirtilen bekletme aralığı arasındaki farka eşittir. İlkenin bekletme aralığı uzatılabildiğinden sabit depolama, etkin saklama süresini hesaplamak için kullanıcı tarafından belirtilen saklama aralığının en son değerini kullanır.
Örneğin, bir kullanıcının beş yıllık saklama aralığına sahip zamana dayalı bir bekletme ilkesi oluşturduğunu varsayalım. Testblob1 kapsayıcısında mevcut bir blob bir yıl önce oluşturulduğundan testblob1 için geçerli saklama süresi dört yıldır. Kapsayıcıya testblob2 adlı yeni bir blob yüklendiğinde, testblob2 için etkin saklama süresi oluşturulduğu zamandan beş yıl sonra olur.
Kilitli ve açık politikalar
Zamana bağlı saklama ilkesini ilk kez yapılandırdığınızda, ilkenin kilidi test amacıyla açılır. Testi tamamladığınızda, ilkeyi kilitleyerek SEC 17a-4(f) ve diğer düzenlemelerle tam uyumluluk sağlayabilirsiniz.
Hem kilitli hem de kilitsiz ilkeler silme ve üzerine yazma işlemlerine karşı koruma sağlar. Ancak, bekletme süresini kısaltarak veya genişleterek kilitli olmayan bir politikayı değiştirebilirsiniz. Kilidi açılmış bir ilkeyi de silebilirsiniz. Kilitli zamana bağlı saklama ilkesini silemezsiniz. Saklama süresini uzatabilirsiniz, ancak azaltamazsınız. Konteyner düzeyinde tanımlanan kilitli bir politikanın ömrü boyunca etkin saklama süresine en fazla beş artış yapılmasına izin verilir. Blob sürümü için yapılandırılmış bir ilke için geçerlilik süresine yapılan artışların sayısıyla ilgili bir sınır yoktur.
Önemli
Blob'un SEC 17a-4(f) ve diğer mevzuat uyumluluğu için değiştirilemez (yazma ve silme korumalı) durumda olması için zamana bağlı saklama ilkesi kilitlenmelidir. Microsoft, politikayı makul bir süre içinde, genellikle 24 saatten kısa bir sürede kilitlemenizi önerir. Kilidi açılmış durum değişmezlik koruması sağlarken, kilidi açılmış durumun kısa süreli test dışında herhangi bir amaçla kullanılması önerilmez.
Saklama politikası denetim kaydı
Zaman bazlı saklama ilkesi için etkinleştirilmiş her kap bir ilke denetim günlüğü sağlar. Denetim günlüğü, kilitli zamana dayalı saklama ilkeleri için yedi adede kadar zaman tabanlı saklama komutu içerir. Günlük kaydı genellikle politikayı kilitledikten sonra başlar. Günlük girişleri kullanıcı kimliğini, komut türünü, zaman damgalarını ve bekletme aralığını içerir. Denetim günlüğü, SEC 17a-4(f) mevzuat yönergelerine uygun olarak ilkenin kullanım ömrü boyunca saklanır.
Azure Etkinlik günlüğü, tüm yönetim hizmeti etkinliklerinin daha kapsamlı bir günlüğünü sağlar. Azure kaynak günlükleri veri işlemleri hakkındaki bilgileri korur. Yasal düzenlemeler veya başka amaçlar için gerekli olabileceğinden, bu günlükleri kalıcı olarak depolamak kullanıcının sorumluluğundadır.
Sürüm düzeyinde zamana bağlı saklama ilkelerinde yapılan değişiklikler denetlenmiyor.
Yasal saklama emirleri
Yasal tutma, yasal araştırma amaçları veya genel koruma ilkeleri için uygulanabilen geçici bir değişmezlik ilkesidir. Yasal kısıtlama, kısıtlama açıkça kaldırılana kadar blob verilerini Bir Kez Yazma, Çok Okuma (WORM) formatında saklar. Yasal tutma etkin olduğunda bloblar oluşturulabilir ve okunabilir, ancak değiştirilemez veya silinemez. Verilerin WORM durumunda ne kadar süreyle tutulması gerektiği bilinmediğinde yasal bekletme kullanın.
Kapsam
Yasal tutma ilkesi aşağıdaki kapsamlardan birinde yapılandırılabilir:
Sürüm düzeyinde WORM ilkesi: Hassas verilerin ayrıntılı yönetimi için tek bir blob sürümü düzeyinde yasal tutma yapılandırılabilir.
Kapsayıcı düzeyinde WORM ilkesi: Kapsayıcı düzeyinde yapılandırılan hukuki bekletme, bu kapsayıcıdaki tüm bloblar için geçerlidir. Tek tek bloblar kendi değiştirilemezlik ilkeleriyle yapılandırılamaz.
Etiketler
Kapsayıcı düzeyinde bir yasal tutma, kimlik dizeleri işlevi gören bir veya daha fazla kullanıcı tanımlı alfasayısal etiketle ilişkilendirilmelidir. Örneğin, bir etiket bir vaka kimliği veya olay adı içerebilir.
Denetim günlüğü
Yasal tutma altında olan her kapsayıcı, bir politika denetim günlüğü sağlar. Günlük, kullanıcı kimliğini, komut türünü, zaman belirteçlerini ve yasal etiketleri içerir. Denetim günlüğü, SEC 17a-4(f) mevzuat yönergelerine uygun olarak ilkenin kullanım ömrü boyunca saklanır.
Azure Etkinlik günlüğü, tüm yönetim hizmeti etkinliklerinin daha kapsamlı bir günlüğünü sağlar. Azure kaynak günlükleri veri işlemleri hakkındaki bilgileri korur. Yasal düzenlemeler veya başka amaçlar için gerekli olabileceğinden, bu günlükleri kalıcı olarak depolamak kullanıcının sorumluluğundadır.
Sürüm düzeyinde yasal saklamalarda yapılan değişiklikler denetlenmiyor.
Sabit depolama özelliği seçenekleri
Aşağıdaki tabloda kapsayıcı düzeyi WORM ile sürüm düzeyi WORM arasındaki farkların dökümü gösterilmektedir:
| Kategori | Kapsayıcı düzeyinde WORM | Sürüm düzeyi WORM |
|---|---|---|
| İlke ayrıntı düzeyi | Politikalar yalnızca kapsayıcı düzeyinde yapılandırılabilir. Kapsayıcıya yüklenen her nesne sabit ilke kümesini devralır. | İlkeler hesap, kapsayıcı veya blob düzeyinde yapılandırılabilir. Bir ilke hesap düzeyinde ayarlanırsa, bu hesaba yüklenen tüm bloblar ilkeyi devralır. Kapsayıcılarla aynı mantık izlenir. İlke birden çok düzeyde ayarlanırsa öncelik sırası her zaman Blob -> Kapsayıcı -> Hesap'tır. |
| Kullanılabilir ilke türleri | Kapsayıcı düzeyinde iki farklı tür ilke ayarlanabilir: Zamana bağlı saklama ilkeleri ve yasal tutmalar. | Hesap ve kapsayıcı düzeyinde yalnızca zamana bağlı saklama ilkeleri ayarlanabilir. Blob düzeyinde hem zamana bağlı saklama ilkeleri hem de yasal tutmalar ayarlanabilir. |
| Özellik bağımlılıkları | Bu özelliğin çalışması için başka hiçbir özellik önkoşul veya gereksinim değildir. | Sürüm oluşturma, bu özelliğin kullanılması için bir önkoşuldur. |
| Mevcut hesaplar ve kapsayıcılar için aktivasyon. | Bu özellik mevcut kapsayıcılar için istediğiniz zaman etkinleştirilebilir. | Ayrıntı düzeyine bağlı olarak, bu özellik tüm mevcut hesaplar/kapsayıcılar için etkinleştirilmemiş olabilir. |
| Hesap/kapsayıcı silme | Zaman tabanlı saklama ilkesi bir kapsayıcıda kilitlendiğinde kapsayıcılar yalnızca boşsa silinebilir. | Hesap veya kapsayıcı düzeyinde WORM sürüm düzeyi aktif hale getirildikten sonra, yalnızca boş olduklarında silinebilirler. |
| Azure Data Lake Storage desteği (hiyerarşik ad alanı etkinleştirilmiş depolama hesapları) | Kapsayıcı düzeyinde WORM ilkeleri, hiyerarşik ad alanına sahip hesaplarda desteklenir. | Sürüm düzeyi WORM ilkeleri henüz hiyerarşik ad alanına sahip hesaplarda desteklenmemektedir. |
Kapsayıcı düzeyinde WORM hakkında daha fazla bilgi edinmek için bkz . Kapsayıcı Düzeyinde WORM ilkeleri. Sürüm düzeyi WORM hakkında daha fazla bilgi edinmek için lütfen sürüm Düzeyi WORM ilkeleri'ne gidin.
Kapsayıcı düzeyi ile sürüm düzeyi WORM karşılaştırması
Aşağıdaki tablo, hangi tür WORM politikasını kullanmanız gerektiğine karar vermenize yardımcı olur.
| Ölçütler | Kapsayıcı düzeyinde WORM Kullanımı | Sürüm düzeyinde WORM Kullanımı |
|---|---|---|
| Veri düzenleme | Kapsayıcıya göre kategorilere ayırabileceğiniz belirli veri kümeleri için ilkeler ayarlamak istiyorsunuz. Bu kapsayıcıdaki tüm verilerin aynı süre boyunca WORM durumunda tutulması gerekir. | Nesneleri bekletme sürelerine göre gruplandıramazsınız. Tüm blobların, ilgili blobun senaryolarına dayalı olarak bireysel bir saklama süresiyle depolanması gerekir veya kullanıcı karışık bir iş yüküne sahiptir; böylece bazı veri grupları kapsayıcılar halinde kümelenebilirken, diğer bloblar bunu yapamaz. Aynı hesap içinde kapsayıcı düzeyi ilkeleri ve blob düzeyi ilkeleri de ayarlamak isteyebilirsiniz. |
| Sabit ilke gerektiren veri miktarı | Hesap başına 10.000'den fazla kapsayıcıda politika belirlemeniz gerekmez. | Tüm verilerde veya hesap bazında ayrılabilen büyük miktarda veri üzerinde politikalar belirlemek istiyorsunuz. Biliyorsunuz ki, kapsayıcı düzeyinde WORM kullanıyorsanız 10.000 kapsayıcı sınırını aşmanız gerekecektir. |
| Sürüm oluşturmayı etkinleştirmeye ilgi | Ya maliyet nedeniyle ya da iş yükü çok sayıda ekstra sürüm yaratacağı için bunlarla uğraşmamak adına sürüm oluşturmayı etkinleştirmek istemezsiniz. | Ya sürüm oluşturmayı kullanmak istersiniz ya da kullanmayı umursamazsınız. Biliyorsunuz ki sürüm oluşturma etkinleştirilmezse, değişmez blobların düzenlemelerini veya üzerine yazılanları ayrı sürümler olarak tutamazsınız. |
| Depolama konumu (Blob Depolama ile Data Lake Storage karşılaştırması) | İş yükünüz tamamen Azure Data Lake Storage'a odaklanmıştır. Hiyerarşik ad alanı özelliği etkin olmayan bir hesabı kullanmaya hemen ilginiz veya planınız yok. | İş yükünüz, hiyerarşik ad alanı özelliği etkinleştirilmiş olmayan bir hesaptaki Blob Depolama'da bulunuyorsa şu anda sürüm düzeyinde WORM kullanabilir, veya hiyerarşik ad alanının etkin olduğu (Azure Data Lake Storage) hesaplar için sürümlemenin kullanılabilir olmasını beklemek isteyebilirsiniz. |
Erişim katmanları
Tüm blob erişim katmanları değişmez depolamayı destekler. Blob KatmanıNı Ayarla işlemiyle blobun erişim katmanını değiştirebilirsiniz. Daha fazla bilgi için bkz Blob verileri için erişim katmanları.
Yedeklilik yapılandırmaları
Tüm yedeklilik yapılandırmaları sabit depolamayı destekler. Yedeklilik yapılandırmaları hakkında daha fazla bilgi için bkz . Azure Depolama yedekliliği.
Önerilen blob türleri
Microsoft, çoğunlukla blok blobları ve ekleme blobları için değişmezlik ilkeleri yapılandırmanızı önerir. Etkin bir sanal makine için VHD diski depolayan bir sayfa blobu için değiştirilemezlik ilkesinin yapılandırılması, diske yazma engellendiği veya sürüm oluşturma etkinleştirildiğinde her yazma işleminin yeni bir sürüm olarak depolandığı için önerilmez. Microsoft, zaman tabanlı ilkeleri kilitlemeden önce belgeleri ayrıntılı bir şekilde incelemenizi ve senaryolarınızı test etmenizi önerir.
Değiştirilemez depolama ve blob yumuşak silme
Depolama hesabı için blob geçici silme yapılandırıldığında, yasal saklama veya zamana bağlı saklama ilkesinin geçerli olup olmadığına bakılmaksızın hesaptaki tüm bloblar için geçerlidir. Microsoft, herhangi bir değişmezlik ilkesi uygulanmadan önce ek koruma için geçici silmenin etkinleştirilmesini önerir.
Blob geçici silmeyi etkinleştirir ve sonra bir değişmezlik ilkesi yapılandırırsanız, geçici silme bekletme ilkesi sona erdikten sonra geçici silme işlemi yapılmış olan tüm bloblar kalıcı olarak silinir. Geçici olarak silinen bloblar geçici silme saklama süresi boyunca geri yüklenebilir. Geçici olarak silinmemiş bir blob veya sürüm değiştirilemezlik ilkesi tarafından korunur ve zamana bağlı saklama ilkesinin süresi dolana veya yasal saklama kaldırılana kadar geçici olarak silinemez.
Değişmezlik ilkelerini izlemek için blob envanteri kullanma
Azure Depolama blob envanteri, depolama hesaplarınızdaki kapsayıcılara ve bunların içindeki bloblara, anlık görüntülere ve blob sürümlerine genel bir bakış sağlar. Bir kaynağın bir değişmezlik ilkesi yapılandırılmış olup olmadığı dahil olmak üzere blobların ve kapsayıcıların özniteliklerini anlamak için blob envanter raporunu kullanabilirsiniz.
Blob envanteri etkinleştirdiğinizde Azure Depolama günlük olarak bir envanter raporu oluşturur. Rapor, iş ve uyumluluk gereksinimleri için verilerinize genel bir bakış sağlar.
Blob envanteri hakkında daha fazla bilgi için Azure Depolama blob envanteri'ne bakınız.
Not almak
Bu hesapta sürüm düzeyi değişmezlik desteği etkinleştirildiyse veya stok ilkesinde tanımlanan hedef kapsayıcıda sürüm düzeyi değişmezlik desteği etkinleştirildiyse hesapta bir stok ilkesi yapılandıramazsınız.
İlkeleri büyük ölçekte yapılandırma
Bir depolama görevini, tanımladığınız bir dizi koşula göre birden çok depolama hesabında uygun ölçekte bir değişmezlik ilkesi yapılandırmak için kullanabilirsiniz. Depolama görevi, Azure Depolama Eylemleri'nde kullanılabilen bir kaynaktır; birden çok depolama hesabında milyonlarca nesne üzerinde ortak veri işlemleri gerçekleştirmek için kullanabileceğiniz sunucusuz bir çerçevedir. Daha fazla bilgi edinmek için bkz . Azure Depolama Eylemleri nedir?.
Fiyatlandırma
Sabit depolama alanı kullanmak için ek kapasite ücreti yoktur. Sabit veriler, değişebilir verilerde olduğu gibi fiyatlanır. Sürüm düzeyinde WORM kullanıyorsanız, sürüm oluşturmayı etkinleştirdiğiniz ve ek sürümlerin depolanmasıyla ilişkili bir maliyet olduğundan fatura daha yüksek olabilir. Daha fazla bilgi için sürüm oluşturma fiyatlandırma ilkesini gözden geçirin. Azure Blob Depolama fiyatlandırma ayrıntıları için Azure Depolama fiyatlandırma sayfasına bakın.
Blob sürümünde zamana bağlı saklama ilkesi veya yasal saklama oluşturma veya silme işlemi, yazma işlemi ücretine neden olur. Zamana bağlı saklama ilkesini değiştirmek (kilitlemek veya genişletmek) başka bir işlem ücretine neden olur. İşlem ücretleri hakkında daha fazla bilgi edinmek istiyorsanız lütfen burada İşlemler ve Veri Aktarımı bölümüne bakın.
Faturanızı ödemezseniz ve hesabınızda etkin bir zamana bağlı saklama ilkesi varsa, normal veri saklama ilkeleri Microsoft ile yaptığınız sözleşmenin hüküm ve koşullarında belirtildiği şekilde uygulanır. Genel bilgi için bkz . Microsoft'ta veri yönetimi.
Özellik desteği
Önemli
Bu özellik anlık geri yükleme ve son erişim takibi ile uyumlu değildir.
Bu özellik müşteri tarafından yönetilen plansız yük devretme işlemi ile uyumludur, ancak son eşitleme zamanından sonra değiştirilemez ilkeye yapılan değişiklikler (zamana dayalı bekletme ilkesini kilitleme, genişletme vb.) ikincil bölgeyle eşitlenmez. Yük devretme tamamlandıktan sonra, değişmezlik gereksinimlerinize uygun şekilde güncel olduğundan emin olmak için ikincil bölgedeki değişiklikleri yeniden uygulayabilirsiniz. Ağ Dosya Sistemi (NFS) 3.0 protokolü veya SSH Dosya Aktarım Protokolü (SFTP) etkinleştirilmiş hesaplarda değişmezlik ilkeleri desteklenmez.
URL'ye SQL Yedekleme gibi bazı iş yükleri bir blob oluşturur ve sonra buna ekler. Kapsayıcıda etkin bir zamana bağlı saklama ilkesi veya yasal saklama varsa, bu yöntem başarılı olamaz. Daha fazla bilgi için bkz Korumalı ekleme blob yazmalarına izin ver.
Daha fazla bilgi için bkz. Azure Depolama hesaplarında Blob Depolama özelliği desteği.