Rehidrasi blob dari tingkat arsip

Blob arsip sedang offline dan tidak bisa dibaca atau dimodifikasi. Untuk mengakses datanya, pertama-tama rehidrasi blob ke tingkat online: panas, dingin, atau dingin. Gunakan salah satu metode rehidrasi berikut:

Penting

Anda tidak dapat secara langsung memulihkan snapshot yang diarsipkan atau versi sebelumnya. Untuk mengakses data dari snapshot yang diarsipkan atau versi sebelumnya, Anda harus menyalinnya ke blob baru di tingkat online (panas, dingin, atau dingin) menggunakan operasi Copy Blob .

Merehidrasi blob dari tingkat arsip dapat memakan waktu beberapa jam. Arsipkan gumpalan besar untuk performa rehidrasi yang optimal. Melakukan rehidrasi pada sejumlah besar blob kecil mungkin memerlukan waktu tambahan karena adanya overhead pemrosesan pada setiap blob. Maksimal 10 GiB per akun penyimpanan dapat direhidrasi per jam dengan pengambilan prioritas.

Untuk mempelajari cara merehidrasi blob yang diarsipkan ke tingkat online, lihat Merehidrasi blob yang diarsipkan ke tingkat online.

Prioritas rehidrasi

Saat Anda merehidrasi sebuah blob, Anda dapat mengatur prioritas operasi dengan menggunakan header opsional x-ms-rehydrate-priority pada operasi Set Blob Tier atau Copy Blob . Pilihan prioritas rehidrasi meliputi:

  • Prioritas standar: Permintaan rehidrasi diproses dalam urutan diterimanya dan mungkin memerlukan waktu hingga 15 jam untuk menyelesaikan objek dengan ukuran di bawah 10 GB.
  • Prioritas tinggi: Permintaan rehidrasi diprioritaskan daripada permintaan prioritas standar dan mungkin selesai dalam waktu kurang dari satu jam untuk objek dengan ukuran di bawah 10 GB.

Untuk memeriksa prioritas rehidrasi saat operasi rehidrasi sedang berlangsung, panggil Dapatkan Properti Blob untuk menampilkan nilai header x-ms-rehydrate-priority. Properti prioritas rehidrasi mengembalikan Standar atau Tinggi.

Prioritas standar adalah opsi rehidrasi default. Rehidrasi prioritas tinggi lebih cepat tetapi biayanya lebih mahal dibandingkan rehidrasi prioritas standar. Rehidrasi berprioritas tinggi mungkin memerlukan waktu lebih dari satu jam, bergantung pada ukuran blob dan permintaan saat ini. Simpan rehidrasi prioritas tinggi untuk pemulihan data darurat.

Sementara operasi rehidrasi dengan prioritas standar masih tertunda, Anda dapat memperbarui pengaturan prioritas rehidrasi untuk blob menjadi Tinggi agar blob tersebut direhidrasi lebih cepat. Misalnya, jika Anda merehidrasi banyak blob sekaligus, Anda dapat menentukan prioritas Standard untuk semua blob pada operasi awal, lalu meningkatkan prioritas menjadi High untuk blob tertentu yang perlu dibuat online lebih cepat, hingga batas 10 GiB per jam.

Penting

Batas 10 GiB/jam berlaku di tingkat akun penyimpanan, bukan per blob. Meskipun garis waktu seperti "hingga 15 jam" untuk prioritas standar mungkin berlaku untuk blob individual dalam kondisi ideal, mereka tidak dapat diskalakan secara linear untuk operasi massal. Jika Anda merehidrasi data dalam jumlah besar, harapkan durasi yang lebih lama dan rencanakan sesuai kebutuhan. Throughput dibagi bersama di antara semua blob yang sedang direhidrasi dalam akun yang sama, dan jika melebihi batas per jam, hal ini dapat menyebabkan pembatasan laju atau penundaan yang lebih lama. Untuk performa optimal, pertimbangkan pengelompokan permintaan rehidrasi dan memantau aktivitas pada tingkat akun.

Anda tidak bisa menurunkan pengaturan prioritas rehidrasi dari Tinggi ke Standar untuk operasi yang sedang diproses. Memperbarui prioritas dapat memengaruhi penagihan.

Untuk mempelajari cara mengatur dan memperbarui pengaturan prioritas rehidrasi, lihat Merehidrasi blob yang diarsipkan ke tingkat online.

Untuk informasi selengkapnya tentang perbedaan harga antara permintaan rehidrasi prioritas standar dan prioritas tinggi, lihat Harga untuk Azure Blob Storage.

Salin blob yang diarsipkan ke tingkat daring

Untuk merehidrasi blob yang diarsipkan dengan menyalinnya, gunakan operasi Copy Blob untuk membuat blob tujuan baru di tingkat panas, dingin, atau dingin. Blob sumber tetap tidak dimodifikasi di tingkat arsip.

Anda harus menyalin blob yang diarsipkan ke blob baru dengan nama yang berbeda atau ke wadah yang berbeda. Anda tidak dapat menimpa blob sumber dengan menyalin ke blob yang sama.

Dengan menyalin blob dari tingkat arsip ke tingkat online, Anda dapat menghindari biaya penghapusan awal yang dinilai jika Anda mengubah tingkat blob dari tingkat arsip sebelum periode 180 hari yang diperlukan berlalu. Untuk informasi selengkapnya, buka Tingkat akses arsip.

Hindari pengarsipan ulang kebijakan siklus hidup

Menyalin juga dapat mencegah kebijakan manajemen siklus hidup memindahkan blob yang sudah terhidrasi kembali ke tingkat arsip. Risiko ini terjadi ketika tindakan pada kebijakan tierToArchive tidak menyertakan kondisi daysAfterLastTierChangeGreaterThan dan waktu terakhir blob dimodifikasi melebihi ambang batas kebijakan. Operasi salinan meninggalkan blob sumber di tingkat arsip dan membuat blob baru dengan nama berbeda serta waktu terakhir yang dimodifikasi.

Pantau penyelesaian salinan

Menyalin blob dari tingkat arsip dapat memerlukan waktu berjam-jam, tergantung pada prioritas rehidrasi yang dipilih. Operasi salin membaca blob sumber yang diarsipkan dan membuat blob baru di tingkat online yang dipilih. Blob baru mungkin muncul di kontainer induk sebelum rehidrasi selesai, tetapi tiernya tetap archive. Datanya menjadi tersedia setelah layanan membaca blob sumber dan menulis isinya ke blob tujuan. Blob baru adalah salinan independen, jadi memodifikasi atau menghapusnya tidak memengaruhi blob sumber yang diarsipkan.

Untuk mempelajari cara merehidrasi blob dengan menyalinnya ke tingkat online, lihat Merehidrasi blob dengan operasi penyalinan.

Penting

Jangan hapus blob sumber sampai rehidrasi selesai dengan sukses. Jika Anda menghapus blob sumber, blob tujuan mungkin belum selesai disalin. Pantau event penyelesaian untuk menentukan kapan Anda dapat menghapus blob sumber dengan aman. Untuk informasi lebih lanjut, lihat Menangani peristiwa rehidrasi blob.

Salin antar akun penyimpanan

Versi layanan 2021-02-12 dan versi setelahnya mendukung rehidrasi dengan menyalin blob arsip ke akun penyimpanan lain di wilayah yang sama. Versi layanan sebelumnya hanya mendukung rehidrasi dalam akun penyimpanan yang sama. Rehidrasi di seluruh akun penyimpanan memungkinkan Anda memisahkan data produksi dari data cadangan dengan menyimpannya di akun terpisah. Mengisolasi data arsip dalam akun terpisah juga dapat membantu mengurangi biaya akibat rehidrasi yang tidak disengaja.

Blob target untuk operasi penyalinan harus berada pada tingkat daring (panas, sejuk, atau dingin). Anda tidak dapat menyalin blob yang diarsipkan ke blob tujuan yang juga berada di tingkat arsip.

Tabel berikut menunjukkan perilaku operasi salinan blob, tergantung pada tingkatan sumber dan blob tujuan.

Sumber tingkat hot Sumber tingkat tidak aktif Sumber tingkat dingin Sumber tingkat arsip
Tujuan tingkat panas Didukung Didukung Didukung Didukung untuk semua akun di wilayah yang sama dengan versi 2021-02-12 atau yang lebih baru. Hanya didukung dalam akun penyimpanan yang sama untuk versi sebelumnya. Memerlukan pemulihan blob.
Tujuan tingkat cool Didukung Didukung Didukung Didukung untuk semua akun di wilayah yang sama dengan versi 2021-02-12 dan versi yang lebih baru. Didukung hanya dalam akun penyimpanan yang sama untuk versi terdahulu. Memerlukan rehidrasi blob.
Destinasi tingkat dingin Didukung Didukung Didukung Didukung di semua akun dalam wilayah yang sama dengan versi 2021-02-12 dan yang lebih baru. Hanya didukung dalam akun penyimpanan yang sama untuk versi yang lebih lama. Memerlukan rehidrasi blob.
Tujuan tingkat arsip Didukung Didukung Didukung Tidak didukung

Rehidrasi dari wilayah sekunder

Jika akun penyimpanan Anda menggunakan penyimpanan geo-redundan dengan akses baca (RA-GRS), gunakan operasi Copy Blob untuk merehidrasi blob dari wilayah sekunder ke akun penyimpanan lain di wilayah tersebut. Lihat Rehidrasi dari wilayah sekunder.

Untuk mempelajari selengkapnya tentang mendapatkan akses baca ke wilayah sekunder, lihat Membaca akses ke data di wilayah sekunder.

Ubah tingkatan akses blob menjadi tingkatan online

Opsi kedua untuk merehidrasi blob dari tingkat arsip ke tingkat online adalah mengubah tingkat blob dengan memanggil Atur Tingkatan Blob. Dengan operasi ini, Anda dapat mengubah tier blob yang diarsipkan menjadi Hot, Cool, atau Cold.

Anda tidak dapat membatalkan permintaan Set Blob Tier setelah dimulai. Selama rehidrasi, tingkat akses blob tetap berada pada arsip. Ketika rehidrasi selesai, properti tier akses akan menampilkan tier baru.

Untuk mempelajari cara merehidrasi blob dengan mengubah tingkatannya ke tingkat online, lihat Rehidrasi blob dengan mengubah tingkatannya.

Perhatian

Mengubah tingkat blob tidak mempengaruhi waktu modifikasi terakhirnya. Jika akun penyimpanan memiliki kebijakan manajemen siklus hidup , kebijakan mungkin memindahkan blob kembali ke tingkat arsip setelah rehidrasi ketika waktu terakhir yang dimodifikasi melebihi ambang kebijakan.

Untuk menghindari skenario ini, tambahkan ketentuan daysAfterLastTierChangeGreaterThan ke tindakan tierToArchive dari kebijakan. Sebagai alternatif, Anda dapat merehidrasi blob yang diarsipkan dengan menyalinnya, seperti yang dijelaskan di bagian Menyalin blob yang diarsipkan ke tier online. Melakukan operasi salinan membuat instance baru dari blob dengan waktu terakhir yang diperbarui, sehingga tidak memicu kebijakan manajemen siklus hidup.

Periksa status operasi rehidrasi blob

Selama operasi rehidrasi blob, Anda dapat menjalankan operasi Get Blob Properties untuk memeriksa statusnya. Untuk mempelajari cara memeriksa status operasi rehidrasi, lihat Memeriksa status operasi rehidrasi.

Menangani peristiwa rehidrasi blob

Merehidrasi blob yang diarsipkan dapat memakan waktu hingga 15 jam, dan berulang kali melakukan polling Get Blob Properties tidak efisien. Gunakan Azure Event Grid untuk menangkap event penyelesaian demi kinerja yang lebih baik dan biaya yang lebih rendah.

Azure Event Grid akan menampilkan Microsoft.Storage.BlobTierChanged event saat rehidrasi blob selesai:

  • Event ini Microsoft.Storage.BlobTierChanged aktif saat tingkat blob berubah. Untuk rehidrasi blob, event akan aktif ketika blob tujuan berhasil berubah dari tingkat arsip ke tier online (panas, dingin, atau dingin).

Saat Anda menggunakan operasi Salin Blob untuk menyalin blob dari lapisan Arsip ke blob tujuan baru di lapisan online (lapisan panas, sejuk, atau dingin) untuk rehidrasi:

  1. Azure Event Grid memicu peristiwa Microsoft.Storage.BlobCreated saat operasi penyalinan dimulai. Tier blob tersebut adalah Archive.

  2. Setelah blob disalin dan dihidrasi ulang, Azure Event Grid menjalankan Microsoft.Storage.BlobTierChanged event yang menunjukkan perubahan dari Archive ke tier online yang ditentukan.

Untuk mempelajari cara mengambil peristiwa pada rehidrasi dan mengirimkannya ke pengendali peristiwa Fungsi Azure, lihat Menjalankan Fungsi Azure sebagai respons terhadap peristiwa rehidrasi blob.

Untuk informasi lebih lanjut tentang penanganan event di Blob Storage, lihat Reacting to Azure Blob storage events dan Azure Blob Storage as Event Grid source.

Penetapan harga dan penagihan

Untuk Set Blob Tier, Azure Storage mengenakan biaya untuk transaksi pembacaan data dan jumlah data yang diambil. Rehidrasi prioritas tinggi lebih mahal daripada prioritas standar dan muncul sebagai item tersendiri di tagihan Anda. Jika permintaan prioritas tinggi untuk blob arsip yang kurang dari 10 GB memakan waktu lebih dari lima jam, Azure Storage tidak mengenakan tarif pengambilan prioritas tinggi. Tarif pengambilan standar masih berlaku. Untuk perkiraan biaya sampel, lihat Perkiraan biaya: Memindahkan data dari penyimpanan arsip.

Untuk Copy Blob, Azure Storage mengenakan biaya untuk transaksi baca data, jumlah data yang diambil, dan transaksi penulisan data untuk blob tujuan. Biaya penghapusan awal tidak berlaku karena blob sumber tetap tidak diubah di tingkat arsip. Biaya pengambilan dengan prioritas tinggi berlaku jika dipilih. Untuk perkiraan sampel, lihat Perkiraan biaya: Mengambil data dari penyimpanan arsip untuk analisis.

Blob dalam tingkat arsip harus disimpan selama minimal 180 hari. Menghapus atau mengubah tingkat blob yang diarsipkan sebelum periode 180 hari berlalu menimbulkan biaya penghapusan awal. Misalnya, jika sebuah blob dipindahkan ke tingkat arsip lalu dihapus atau dipindahkan ke tingkat panas setelah 45 hari, Anda dikenakan biaya penghapusan awal yang setara dengan 135 (180 minus 45) hari penyimpanan blob tersebut di tingkat arsip. Untuk informasi selengkapnya, buka Tingkat akses arsip.

Untuk informasi lebih lanjut tentang harga block blob dan rehidrasi data, lihat harga Azure Storage. Untuk informasi lebih lanjut tentang biaya transfer data keluar, lihat detail harga transfer data.

Lihat juga

  • Last updated on