Penerapan versi blob

Anda dapat mengaktifkan penerapan versi penyimpanan Blob untuk mempertahankan versi objek sebelumnya secara otomatis. Saat Anda mengaktifkan versi blob, Anda dapat mengakses versi lama dari blob untuk memulihkan data Anda jika data tersebut dimodifikasi atau dihapus.

Perhatian

Setelah Anda mengaktifkan penerapan versi blob untuk akun penyimpanan, setiap operasi tulis ke blob di akun tersebut akan menghasilkan pembuatan versi baru. Oleh karena itu, mengaktifkan versi blob dapat menimbulkan biaya tambahan. Untuk meminimalkan biaya, gunakan kebijakan manajemen siklus hidup untuk menghapus versi lama secara otomatis. Untuk informasi selengkapnya tentang manajemen siklus hidup, lihat Optimisasi biaya dengan mengotomatiskan tingkat akses Azure Blob Storage.

Cara kerja penerapan versi blob

Suatu versi merekam keadaan blob pada titik waktu tertentu. Setiap versi diidentifikasi dengan ID versi. Saat penerapan versi blob diaktifkan untuk akun penyimpanan, Azure Storage secara otomatis membuat versi baru dengan ID unik saat blob pertama kali dibuat dan setiap kali blob kemudian dimodifikasi.

ID versi dapat mengidentifikasi versi saat ini atau versi sebelumnya. Blob hanya dapat memiliki satu versi saat ini pada satu waktu.

Saat Anda membuat blob baru, ada satu versi, dan versi tersebut adalah versi saat ini. Saat Anda memodifikasi blob yang ada, versi saat ini menjadi versi sebelumnya. Versi baru dibuat untuk menangkap status yang diperbarui, dan versi baru tersebut adalah versi saat ini. Saat Anda menghapus blob, versi blob saat ini menjadi versi sebelumnya, dan tidak ada lagi versi saat ini. Versi-versi sebelumnya dari blob tetap ada.

Diagram berikut menunjukkan bagaimana versi dibuat pada operasi tulis, dan bagaimana versi sebelumnya dapat dipromosikan menjadi versi saat ini:

Diagram yang menunjukkan bagaimana blob versioning membuat dan mempromosikan versi pada operasi tulis.

Penting

Memiliki sejumlah besar versi per blob dapat meningkatkan latensi untuk operasi daftar blob. Microsoft merekomendasikan untuk mempertahankan kurang dari 1000 versi per blob. Anda dapat menggunakan manajemen siklus hidup untuk menghapus versi lama secara otomatis. Untuk informasi selengkapnya tentang manajemen siklus hidup, lihat Optimisasi biaya dengan mengotomatiskan tingkat akses Azure Blob Storage.

Versi blob tidak dapat diubah. Anda tidak dapat mengubah konten atau metadata versi blob yang ada.

Pembuatan versi blob tersedia untuk v2 tujuan umum standar, blob blok premium, dan akun penyimpanan Blob warisan. Akun penyimpanan dengan namespace hierarkis yang diaktifkan untuk digunakan dengan Azure Data Lake Storage saat ini tidak didukung.

Versi 2019-10-10 dan yang lebih tinggi dari Azure Storage REST API mendukung penerapan versi blob.

Penting

Versi Blob tidak dapat membantu Anda pulih dari penghapusan akun atau kontainer penyimpanan secara tidak sengaja. Untuk mencegah penghapusan akun penyimpanan yang tidak disengaja, konfigurasikan kunci pada sumber daya akun penyimpanan. Untuk informasi selengkapnya tentang mengunci akun penyimpanan, lihat Aplikasikan kunci Azure Resource Manager ke akun penyimpanan.

ID Versi

Setiap versi blob memiliki ID versi yang unik. Nilai ID versi adalah cap waktu saat blob diperbarui. Anda menetapkan ID versi saat membuat versi.

Anda dapat membaca atau menghapus versi tertentu dari sebuah blob dengan menggunakan ID versinya. Jika Anda tidak menyertakan ID versi, operasi akan menargetkan versi saat ini.

Saat Anda memanggil operasi tulis untuk membuat atau memodifikasi blob, Azure Storage mengembalikan header x-ms-version-id dalam respons. Header ini berisi ID versi untuk versi blob saat ini yang dibuat oleh operasi penulisan tersebut.

ID versi tetap sama selama masa pakai versi.

Pengaturan versi pada operasi penulisan

Saat Anda mengaktifkan versi blob, setiap operasi penulisan ke blob akan membuat versi baru. Operasi tulis termasuk Memasukkan Blob, Memasukkan Daftar Blok, Salin Blob, dan Atur Metadata Blob.

Jika operasi penulisan membuat blob baru, blob yang dihasilkan adalah versi blob saat ini. Jika operasi penulisan memodifikasi blob yang sudah ada, versi saat ini menjadi versi sebelumnya, dan versi terbaru akan menangkap blob yang diperbarui.

Diagram berikut menunjukkan bagaimana operasi tulis mempengaruhi versi blob. Untuk kesederhanaan, diagram dalam artikel ini menampilkan ID versi sebagai nilai bilangan bulat sederhana. Pada kenyataannya, ID versi adalah penanda waktu. Versi saat ini ditampilkan dalam warna biru, dan versi sebelumnya ditampilkan dalam warna abu-abu.

Diagram yang menunjukkan bagaimana operasi penulisan mempengaruhi blob yang memiliki versi.

Catatan

Ketika Anda mengaktifkan versi blob untuk akun penyimpanan, semua operasi penulisan pada blob blok memicu pembuatan versi baru, kecuali operasi Put Block .

Untuk page blob dan append blob, hanya sebagian operasi tulis yang memicu pembuatan versi. Operasi ini meliputi:

Operasi berikut tidak memicu pembuatan versi baru. Untuk menangkap perubahan dari operasi tersebut, ambil rekam jepret manual:

Semua versi blob harus memiliki tipe blob yang sama. Jika blob memiliki versi sebelumnya, Anda tidak dapat menimpa blob dari satu jenis dengan jenis lain kecuali Anda terlebih dahulu menghapus blob dan semua versinya.

Pengaturan versi pada operasi penghapusan

Saat Anda memanggil operasi Hapus Blob tanpa menentukan ID versi, versi saat ini menjadi versi sebelumnya, dan tidak ada lagi versi saat ini. Operasi ini tetap menyimpan semua versi sebelumnya dari blob yang sudah ada.

Diagram berikut menunjukkan efek operasi penghapusan pada blob versi:

Diagram yang menunjukkan penghapusan blob versi.

Untuk menghapus versi blob tertentu, berikan ID untuk versi tersebut pada operasi penghapusan. Jika Anda juga mengaktifkan blob soft delete untuk akun penyimpanan, sistem akan mempertahankan versi tersebut sampai masa retensi soft delete berakhir.

Menulis data baru ke blob membuat versi saat ini yang baru dari blob. Tindakan ini tidak memengaruhi versi yang sudah ada, seperti yang ditunjukkan pada diagram berikut.

Diagram yang menunjukkan pembuatan ulang blob versi setelah penghapusan.

Lapisan Akses

Anda dapat memindahkan versi apa pun dari blob blok, termasuk versi saat ini, ke tier akses blob yang berbeda dengan memanggil operasi Set Blob Tier. Dengan memindahkan versi lama blob ke tingkat cool atau arsip, Anda dapat memanfaatkan harga kapasitas yang lebih rendah. Untuk informasi selengkapnya, lihat Tingkat akses Panas, Dingin, Sejuk, dan Arsip untuk data blob.

Untuk mengotomatisasi proses pemindahan blob blok ke tier yang sesuai, gunakan manajemen siklus hidup blob. Untuk informasi lebih lanjut tentang manajemen siklus hidup, lihat Kelola siklus hidup penyimpanan Azure Blob.

Mengaktifkan atau menonaktifkan penerapan versi blob

Untuk mempelajari cara mengaktifkan atau menonaktifkan penerapan versi blob, lihat Mengaktifkan dan mengelola penerapan versi blob.

Menonaktifkan versi blob tidak menghapus blob, versi, atau cuplikan yang ada. Saat Anda menonaktifkan penerapan versi blob, versi apa pun yang ada tetap dapat diakses di akun penyimpanan Anda. Tidak ada versi baru yang kemudian dibuat.

Setelah penerapan versi dinonaktifkan, memodifikasi versi saat ini membuat blob yang bukan versi. Semua pembaruan berikutnya pada blob akan menimpa datanya tanpa menyimpan keadaan sebelumnya. Semua versi yang sudah ada akan tetap tersedia seperti versi sebelumnya.

Anda dapat melihat atau menghapus versi dengan menggunakan ID versi setelah pembuatan versi dinonaktifkan. Anda juga dapat mencantumkan versi blob setelah penerapan versi dinonaktifkan.

Replikasi objek bergantung pada penerapan versi blob. Sebelum dapat menonaktifkan penerapan versi blob, Anda harus menghapus kebijakan replikasi objek apa pun di akun tersebut. Untuk informasi selengkapnya tentang replikasi objek, lihat Replikasi objek untuk blob blok.

Diagram berikut menunjukkan cara memodifikasi blob setelah versi dinonaktifkan membuat blob yang tidak memiliki versi. Setiap versi yang ada yang terkait dengan blob bertahan.

Diagram yang menunjukkan bahwa modifikasi versi saat ini setelah versi dinonaktifkan menghasilkan blob yang bukan merupakan sebuah versi.

Pembuatan versi blob dan penghapusan sementara

Penerapan versi blob dan penghapusan sementara blob adalah bagian dari konfigurasi perlindungan data yang direkomendasikan untuk akun penyimpanan. Untuk informasi selengkapnya tentang rekomendasi Microsoft untuk perlindungan data, lihat Gambaran umum perlindungan data.

Menimpa blob

Jika pengaturan versi blob dan penghapusan sementara blob keduanya diaktifkan untuk akun penyimpanan, maka menimpa blob akan secara otomatis membuat versi baru. Versi baru tidak dihapus sementara dan tidak dihapus saat periode retensi penghapusan sementara berakhir. Tidak ada rekam jepret yang dihapus sementara yang dibuat.

Menghapus blob atau versi

Jika Anda mengaktifkan pembuatan versi dan penghapusan sementara untuk akun penyimpanan, saat Anda menghapus blob, versi blob saat ini menjadi versi sebelumnya. Operasi ini tidak membuat versi baru atau snapshot yang dihapus secara lembut. Periode retensi soft delete tidak berlaku untuk blob yang dihapus.

Soft delete memberikan perlindungan ekstra saat menghapus versi blob. Ketika Anda menghapus versi blob sebelumnya, versi tersebut akan dihapus secara lembut. Versi yang di-soft-delete tetap disimpan hingga masa retensi soft-delete berakhir, lalu dihapus secara permanen.

Untuk menghapus versi blob sebelumnya, hubungi operasi Hapus Blob dan tentukan ID versi.

Diagram berikut menunjukkan apa yang terjadi ketika Anda menghapus sebuah blob atau versinya.

Diagram yang menunjukkan penghapusan versi dengan penghapusan lunak diaktifkan.

Memulihkan versi yang dihapus lunak

Anda dapat menggunakan operasi Undelete Blob untuk memulihkan versi yang dihapus sementara selama periode retensi penghapusan sementara. Operasi Batal Hapus Blob selalu mengembalikan seluruh versi blob yang terhapus sementara. Anda tidak bisa memulihkan hanya satu versi yang dihapus secara lembut.

Memulihkan versi yang dihapus secara lunak menggunakan operasi Undelete Blob tidak mempromosikan versi apapun menjadi versi saat ini. Untuk memulihkan versi saat ini, pertama-tama pulihkan semua versi yang dihapus lunak, lalu gunakan operasi Salin Blob untuk menyalin versi sebelumnya ke versi baru saat ini.

Diagram berikut menunjukkan cara mengembalikan versi blob yang dihapus secara lunak dengan menggunakan operasi Undelete Blob , dan cara mengembalikan versi blob saat ini dengan menggunakan operasi Copy Blob .

Diagram yang menunjukkan cara memulihkan versi yang dihapus sementara.

Setelah periode retensi hapus sementara berakhir, setiap versi blob yang dihapus sementara akan dihapus secara permanen.

Pembuatan versi blob dan rekam jepret blob

Snapshot blob adalah salinan baca-saja dari blob yang diambil pada waktu tertentu. Snapshot blob dan versi blob mirip, tetapi Anda atau aplikasi Anda membuat snapshot secara manual, sedangkan versi blob dibuat secara otomatis selama operasi tulis atau hapus saat Anda mengaktifkan pembuatan versi blob untuk akun penyimpanan Anda.

Penting

Microsoft merekomendasikan bahwa setelah mengaktifkan penerapan versi blob, Anda juga memperbarui aplikasi untuk berhenti mengambil rekam jepret blob blok. Jika Anda mengaktifkan pembuatan versi untuk akun penyimpanan, sistem akan merekam dan menyimpan semua pembaruan serta penghapusan blob blok dalam bentuk versi. Membuat snapshot tidak memberikan perlindungan tambahan apa pun untuk data block blob Anda jika pembuatan versi blob diaktifkan, dan hal ini dapat meningkatkan biaya serta kompleksitas aplikasi.

Ambil cuplikan blob ketika pengelolaan versi diaktifkan

Meskipun tidak disarankan, Anda dapat membuat snapshot dari blob yang juga memiliki versi. Jika Anda tidak dapat memperbarui aplikasi untuk berhenti mengambil cuplikan blob saat mengaktifkan versi, aplikasi Anda dapat mendukung cuplikan dan versi.

Saat Anda mengambil snapshot dari blob berversi, Anda membuat versi baru bersamaan dengan pembuatan snapshot tersebut. Anda juga membuat versi terbaru saat mengambil snapshot.

Diagram berikut menunjukkan apa yang terjadi saat Anda mengambil rekam jepret dari blob versi. Dalam diagram, versi blob dan rekam jepret dengan ID versi 2 dan 3 berisi data yang identik.

Diagram yang menunjukkan salinan bayangan dari blob versi.

Mengotorisasi operasi pada versi blob

Anda dapat mengotorisasi akses ke versi blob dengan menggunakan salah satu pendekatan berikut:

  • Gunakan kontrol akses berbasis peran Azure (Azure RBAC) untuk memberikan izin kepada prinsipal keamanan Microsoft Entra. Microsoft merekomendasikan penggunaan Microsoft Entra ID untuk keamanan yang unggul dan kemudahan penggunaan. Untuk informasi selengkapnya tentang menggunakan Microsoft Entra ID dengan operasi blob, lihat Otorisasi akses ke data di Azure Storage.
  • Gunakan tanda tangan akses bersama (SAS) untuk mendelegasikan akses ke versi blob. Tentukan ID versi untuk tipe bvsumber daya bertanda, yang mewakili versi blob, untuk membuat token SAS guna operasi pada versi tertentu. Untuk informasi selengkapnya tentang Shared Access Signatures (SAS), lihat bagian Grant limited access to Azure Storage resources using shared access signatures (SAS).
  • Gunakan kunci akses akun untuk mengotorisasi operasi terhadap versi blob dengan menggunakan Shared Key. Untuk informasi selengkapnya, lihat Mengotorisasi dengan Kunci Bersama.

Penerapan versi blob dirancang untuk melindungi data Anda dari penghapusan yang tidak disengaja atau berbahaya. Untuk meningkatkan perlindungan, menghapus versi blob memerlukan izin khusus. Bagian berikut ini menjelaskan izin yang diperlukan untuk menghapus versi blob.

Tindakan Azure RBAC untuk menghapus versi blob

Tabel berikut menunjukkan tindakan Azure RBAC yang mendukung penghapusan blob atau versi blob.

Deskripsi Operasi Blob service Diperlukan tindakan pada data RBAC Azure Azure dukungan peran bawaan
Menghapus versi saat ini Menghapus blob Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete Kontributor Data Blob Penyimpanan
Menghapus versi sebelumnya Menghapus blob Microsoft.Storage/storageAccounts/blobServices/containers/blobs/deleteBlobVersion/action Pemilik Data Blob Penyimpanan

Tanda tangan akses bersama (SAS) parameter

Sumber daya yang ditandatangani untuk versi blob adalah bv. Untuk informasi selengkapnya, lihat Membuat layanan SAS atau Membuat delegasi pengguna SAS.

Tabel berikut ini memperlihatkan izin yang diperlukan pada SAS untuk menghapus versi blob.

Izin Simbol URI Operasi yang diperbolehkan
Hapus x Hapus sebuah versi blob.

Penetapan harga dan penagihan

Mengaktifkan versi blob dapat mengakibatkan biaya penyimpanan data tambahan ke akun Anda. Saat merancang aplikasi Anda, ketahuilah bagaimana biaya tersebut dapat timbul agar Anda dapat meminimalkan biaya.

Versi blob, seperti snapshot blob, dikenakan biaya pada tarif yang sama dengan data aktif. Cara Anda membayar versi-versi tersebut bergantung pada apakah Anda secara eksplisit menetapkan tier untuk versi blob (atau snapshot) saat ini maupun sebelumnya. Untuk informasi selengkapnya tentang tingkat blob, lihat tingkat akses Panas, Sejuk, Dingin, dan Arsip untuk data blob.

Jika Anda tidak mengubah tier blob atau versinya, Anda akan dikenai biaya untuk blok data unik pada blob tersebut, versinya, serta rekam jepret apa pun yang mungkin dimilikinya. Untuk informasi lebih lanjut, lihat Penagihan ketika tingkat blob tidak secara eksplisit diatur.

Jika Anda mengubah blob atau tier versi, Anda membayar untuk seluruh objek, terlepas dari apakah blob dan versi akhirnya berada di tier yang sama lagi. Untuk informasi lebih lanjut, lihat Penagihan ketika tingkat blob secara eksplisit diatur.

Catatan

Mengaktifkan pembuatan versi untuk data yang sering ditimpa ulang dapat menambah biaya kapasitas penyimpanan dan meningkatkan latensi selama operasi pencantuman. Untuk mengurangi kekhawatiran ini, simpan data yang sering ditimpa di akun penyimpanan terpisah dengan versi dinonaktifkan.

Mengaktifkan versi pada akun penyimpanan yang sering dicadangkan dapat memicu biaya pengambilan data saat versi disimpan pada tingkat akses dingin atau dingin.

Untuk informasi selengkapnya tentang detail penagihan untuk rekam jepret blob, lihat rekam jepret Blob.

Untuk akun penyimpanan yang menggunakan smart tier, Anda membayar versi dan snapshot dengan durasi konten penuh. Untuk informasi selengkapnya, lihat Mengoptimalkan biaya dengan tingkat pintar.

Penagihan saat Anda tidak menetapkan tingkat blob secara eksplisit

Jika Anda tidak secara eksplisit menetapkan tier blob untuk versi blob apa pun, Anda akan dikenai biaya untuk blok atau halaman unik di semua versi, serta snapshot apa pun yang mungkin dimilikinya. Anda hanya membayar satu kali saja untuk data yang sama di seluruh versi blob. Saat Anda memperbarui blob, data dalam versi terbaru berbeda dari data yang disimpan di versi sebelumnya, dan Anda membayar untuk data unik per blok atau halaman.

Ketika Anda mengganti blok dalam blob blok, Anda membayar blok tersebut sebagai blok unik. Aturan ini berlaku meskipun blok memiliki ID blok dan data yang sama seperti versi sebelumnya. Setelah Anda melakukan commit lagi, blok tersebut akan berbeda dari versi sebelumnya, dan Anda membayar untuk datanya. Aturan yang sama berlaku untuk halaman dalam blob halaman yang Anda perbarui dengan data identik.

Penyimpanan blob tidak memiliki cara untuk menentukan apakah dua blok berisi data yang identik. Setiap blok yang Anda unggah dan commit diperlakukan sebagai unik, meskipun memiliki data dan ID blok yang sama. Karena Anda membayar untuk blok unik, ingatlah bahwa memperbarui blob saat pembuatan versi diaktifkan akan menghasilkan lebih banyak blok unik dan biaya tambahan.

Saat Anda mengaktifkan pembuatan versi blob, jalankan operasi pembaruan pada blob blok agar hanya memperbarui blok sesedikit mungkin. Operasi tulis yang memungkinkan kontrol halus atas blok adalah Put Blok dan Put Block List. Operasi Put Blob , di sisi lain, menggantikan seluruh isi blob sehingga bisa menyebabkan biaya tambahan.

Skenario berikut menunjukkan bagaimana biaya dapat diperoleh untuk blob blok dan versinya ketika Anda tidak secara eksplisit mengatur tier blob tersebut.

Skenario 1

Dalam skenario 1, blob memiliki versi sebelumnya. Blob tidak diperbarui sejak versi dibuat, jadi Anda hanya dikenakan biaya untuk blok unik 1, 2, dan 3.

Diagram 1 menunjukkan penagihan untuk blok unik di base blob dan versi sebelumnya.

Skenario 2

Dalam skenario 2, Anda memperbarui satu blok (blok 3 dalam diagram) dalam blob. Meskipun blok yang diperbarui berisi data yang sama dan ID yang sama, blok 3 tidak sama dengan blok 3 di versi sebelumnya. Akibatnya, Anda membayar untuk empat blok.

Diagram 2 menunjukkan penagihan untuk blok unik di blob dasar dan versi sebelumnya.

Skenario 3

Di skenario 3, Anda memperbarui blob, tapi tidak memperbarui versinya. Anda mengganti blok 3 dengan blok 4 di blob saat ini, tetapi versi sebelumnya masih mencerminkan blok 3. Akibatnya, Anda membayar untuk empat blok.

Diagram 3 menunjukkan penagihan untuk blok unik di base blob dan versi sebelumnya.

Skenario 4

Dalam skenario 4, Anda memperbarui versi saat ini sepenuhnya dan tidak mengandung blok aslinya. Akibatnya, Anda membayar untuk kedelapan blok unik tersebut - empat pada versi saat ini, dan empat gabungan dari dua versi sebelumnya. Skenario ini dapat terjadi jika Anda menulis ke blob menggunakan operasi Put Blob , karena operasi tersebut menggantikan seluruh isi blob.

Diagram 4 menunjukkan penagihan untuk blok unik di base blob dan versi sebelumnya.

Penagihan ketika tingkat blob secara eksplisit diatur

Jika Anda secara eksplisit menetapkan tier blob untuk blob, versi, atau snapshot, Anda membayar seluruh panjang konten objek pada tier baru, meskipun objek tersebut berbagi blok dengan objek di tier asal. Anda juga membayar untuk durasi penuh konten versi tertua di tingkat asli. Untuk versi atau snapshot sebelumnya lainnya yang tetap berada di tier asli, Anda membayar blok unik yang dimiliki oleh versi atau snapshot tersebut, seperti yang dijelaskan di Penagihan saat tier blob tidak ditetapkan secara eksplisit.

Memindahkan blob ke level baru

Tabel berikut menjelaskan perilaku penagihan untuk blob atau versi saat Anda memindahkannya ke tier baru.

Saat Anda mengatur tingkat blob... Kemudian Anda ditagih untuk ...
Secara eksplisit untuk versi, baik itu versi saat ini maupun versi sebelumnya Panjang konten lengkap dari versi tersebut. Versi yang tidak menetapkan tingkat secara eksplisit hanya akan dikenai biaya untuk blok unik.1
Untuk mengarsipkan Panjang keseluruhan konten dari semua versi dan snapshot.1.

1Jika ada versi atau snapshot sebelumnya yang tidak Anda pindahkan dari tier aslinya, versi atau snapshot tersebut dikenakan biaya berdasarkan jumlah blok unik yang terkandung, seperti yang dijelaskan dalam Billing ketika tier blob tidak secara eksplisit diatur.

Diagram berikut menggambarkan bagaimana objek ditagih ketika blob dengan versi dipindah ke lapisan yang berbeda.

Diagram yang menunjukkan bagaimana objek ditagihkan ketika versi blob diberi tingkat secara eksplisit.

Anda tidak dapat membatalkan penetapan tier secara eksplisit untuk blob, versi, atau snapshot. Jika Anda memindahkan blob ke tier baru lalu mengembalikannya ke tier aslinya, Anda membayar untuk panjang konten penuh objek meskipun objek tersebut berbagi blok dengan objek lain di tier asli.

Operasi yang secara eksplisit mengatur tingkatan blob, versi, atau cuplikan meliputi:

Menghapus blob ketika penghapusan lunak diaktifkan

Saat Anda mengaktifkan blob soft delete, Anda membayar semua entitas yang dihapus secara lunak dengan tarif yang sama seperti data live. Jika Anda menghapus atau menimpa versi saat ini yang tier-nya ditetapkan secara eksplisit, Anda akan dikenai biaya untuk setiap versi sebelumnya dari blob yang dihapus sementara berdasarkan ukuran konten penuhnya. Untuk informasi selengkapnya tentang cara penerapan versi blob dan penghapusan sementara, lihat Penerapan versi Blob dan penghapusan sementara.

Dukungan fitur

Dukungan untuk fitur ini mungkin terpengaruh dengan mengaktifkan Data Lake Storage Gen2, protokol Network File System (NFS) 3.0, atau Protokol Transfer File SSH (SFTP). Jika Anda telah mengaktifkan salah satu kemampuan ini, lihat dukungan fitur Blob Storage di akun Azure Storage untuk menilai dukungan untuk fitur ini.

Versioning tidak didukung untuk blob yang Anda unggah menggunakan Data Lake Storage API.

Lihat juga

  • Last updated on