Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Azure Storage selalu menyimpan beberapa salinan data Anda untuk melindunginya dari peristiwa yang direncanakan dan tidak direncanakan. Contoh peristiwa ini termasuk kegagalan perangkat keras sementara, pemadaman jaringan atau listrik, dan bencana alam besar-besaran. Redundansi memastikan bahwa akun penyimpanan Anda memenuhi target ketersediaan dan daya tahannya bahkan dalam menghadapi kegagalan.
Saat memutuskan opsi redundansi yang terbaik untuk skenario Anda, pertimbangkan kompensasi antara biaya yang lebih rendah dan ketersediaan yang lebih tinggi. Faktor-faktor yang memudahkan penentuan opsi redundansi yang harus Anda pilih meliputi:
- Cara data Anda direplikasi dalam wilayah utama.
- Apakah data Anda direplikasi dari wilayah utama ke wilayah kedua yang jauh secara geografis, untuk melindungi dari bencana regional (replikasi geografis).
- Apakah aplikasi Anda memerlukan akses baca ke data yang direplikasi di wilayah sekunder selama pemadaman di wilayah utama (replikasi geografis dengan akses baca).
Catatan
Fitur dan ketersediaan regional yang dijelaskan dalam artikel ini juga tersedia untuk akun yang memiliki ruang nama hierarkis (penyimpanan Blob Azure).
Layanan yang terdiri dari Azure Storage dikelola melalui sumber daya Azure umum yang disebut akun penyimpanan. Akun penyimpanan mewakili kumpulan penyimpanan bersama yang dapat digunakan untuk menyebarkan sumber daya penyimpanan seperti kontainer blob (Penyimpanan Blob), berbagi file (Azure Files), tabel (Table Storage), atau antrian (Queue Storage). Untuk infomasi selengkapnya tentang akun Azure Storage, lihat Ringkasan akun penyimpanan.
Pengaturan redundansi untuk akun penyimpanan dibagikan untuk semua layanan penyimpanan yang diekspos oleh akun tersebut. Semua sumber daya penyimpanan yang disebarkan di akun penyimpanan yang sama memiliki pengaturan redundansi yang sama. Pertimbangkan untuk mengisolasi berbagai jenis sumber daya di akun penyimpanan terpisah jika memiliki persyaratan redundansi yang berbeda.
Redundansi di wilayah utama
Azure Storage menawarkan dua opsi cara data Anda direplikasi di wilayah utama:
Penyimpanan redundan lokal (LRS) mereplikasi data dalam akun penyimpanan Anda ke satu pusat data fisik yang terletak di wilayah utama pilihan Anda.
Penyimpanan zona redundan (ZRS) menyalin data Anda secara sinkron di tiga atau beberapa zona ketersediaan Azure di wilayah utama. Untuk aplikasi yang membutuhkan ketersediaan tinggi, Microsoft merekomendasikan penggunaan ZRS di wilayah utama, dan juga mereplikasi ke wilayah sekunder.
Catatan
Microsoft merekomendasikan penggunaan ZRS di wilayah utama untuk beban kerja Azure Data Lake Storage.
Penyimpanan Lokal yang Redundan
Penyimpanan redundan lokal (LRS) mereplikasi data dalam akun penyimpanan Anda ke satu pusat data fisik di wilayah utama pilihan Anda. Meskipun memilih zona ketersediaan tidak didukung, Azure mungkin memindahkan atau memperluas akun LRS di seluruh zona untuk meningkatkan penyeimbangan beban. LRS menyediakan setidaknya 99,999999999% (11 sembilan) ketahanan objek selama satu tahun tertentu. Kunjungi artikel Apa itu zona ketersediaan Azure untuk mempelajari selengkapnya tentang keandalan zona ketersediaan.
LRS adalah opsi redundansi berbiaya terendah dan menawarkan durabilitas paling rendah dibandingkan dengan opsi lain. LRS melindungi data Anda dari kegagalan drive, server, dan rak. Namun, jika bencana seperti kebakaran atau banjir terjadi di dalam pusat data, semua replika akun penyimpanan yang menggunakan LRS mungkin hilang atau tidak dapat dipulihkan. Jika peristiwa sementara, seperti peristiwa termal, terjadi dalam pusat data, semua replika mungkin sementara tidak tersedia sampai peristiwa diselesaikan. Untuk mengurangi risiko ini, Microsoft merekomendasikan penggunaan penyimpanan redundan zona (ZRS), penyimpanan geo-redundan (GRS), atau penyimpanan geo-zona-redundan (GZRS).
Permintaan tulis ke akun penyimpanan yang menggunakan LRS terjadi secara sinkron. Operasi penulisan berhasil dilakukan hanya setelah data ditulis ke ketiga replika.
Diagram berikut menunjukkan bagaimana data Anda direplikasi dalam satu pusat data dengan LRS:
LRS adalah pilihan tepat untuk skenario berikut:
- Jika aplikasi Anda menyimpan data yang dapat dengan mudah direkonstruksi jika kehilangan data terjadi, pertimbangkan untuk memilih LRS.
- Jika aplikasi Anda dibatasi untuk mereplikasi data hanya dalam suatu wilayah karena persyaratan tata kelola data, pertimbangkan untuk memilih LRS. Dalam beberapa kasus, wilayah yang dipasangkan di mana data direplikasi secara geografis mungkin berada di wilayah lain. Untuk informasi selengkapnya tentang wilayah yang dipasangkan, lihat Wilayah Azure.
- Jika skenario Anda menggunakan disk tidak terkelola Azure, pertimbangkan untuk menggunakan LRS (Locally Redundant Storage). Meskipun dimungkinkan untuk membuat akun penyimpanan untuk disk tidak dikelola Azure yang menggunakan GRS, hal ini tidak disarankan karena potensi masalah konsistensi selama replikasi geo asinkron.
Penyimpanan redundan zona
Penyimpanan zona redundan (ZRS) mereplikasi data dalam akun penyimpanan Anda ke tiga atau beberapa zona ketersediaan Azure yang terletak di wilayah utama pilihan Anda. Setiap zona ketersediaan merupakan lokasi fisik terpisah dengan daya independen, pendinginan, dan jaringan. ZRS menawarkan durabilitas untuk sumber daya penyimpanan setidaknya 99,99999999999% (12 9) selama tahun tertentu. Kunjungi artikel Apa itu zona ketersediaan Azure untuk mempelajari selengkapnya tentang keandalan zona ketersediaan.
Saat Anda menggunakan ZRS, data Anda tetap dapat diakses untuk operasi baca dan tulis meskipun zona menjadi tidak tersedia. Jika sebuah zona menjadi tidak tersedia, Azure melakukan pembaruan jaringan seperti mengarahkan ulang Sistem Penamaan Domain (DNS). Pembaruan ini dapat memengaruhi aplikasi Anda jika Anda mengakses data sebelum pembaruan selesai. Saat merancang aplikasi untuk ZRS, ikuti praktik-praktik untuk penanganan kesalahan transien, termasuk menerapkan kebijakan coba kembali dengan back-off eksponensial.
Permintaan tulis ke akun penyimpanan yang menggunakan ZRS terjadi secara sinkron. Operasi tulis akan berhasil dikembalikan hanya setelah data ditulis ke semua replika di tiga zona ketersediaan. Jika zona ketersediaan sementara tidak tersedia, operasi dinyatakan berhasil setelah data ditulis ke semua zona yang tersedia.
Microsoft merekomendasikan penggunaan ZRS di wilayah utama untuk skenario yang memerlukan ketersediaan tinggi. ZRS juga direkomendasikan untuk membatasi replikasi data ke wilayah tertentu untuk memenuhi persyaratan tata kelola data.
Microsoft merekomendasikan penggunaan ZRS untuk beban kerja Azure Files. Jika suatu zona menjadi tidak tersedia, klien yang terhubung tidak perlu memasang ulang berbagi file Azure.
Diagram berikut menunjukkan bagaimana data Anda direplikasi di seluruh zona ketersediaan di wilayah utama dengan ZRS:
ZRS memberikan performa luar biasa, latensi rendah, dan ketahanan untuk data Anda jika sementara tidak tersedia. Namun, ZRS dengan sendirinya mungkin tidak sepenuhnya melindungi data Anda dari bencana regional di mana beberapa zona terpengaruh secara permanen. Geo-zone-redundant storage (GZRS) menggunakan ZRS di wilayah utama dan juga mereplikasi data Anda secara geo ke wilayah sekunder. GZRS tersedia di banyak wilayah, dan direkomendasikan untuk perlindungan terhadap bencana regional.
Tingkat arsip untuk Blob Storage saat ini tidak didukung untuk akun ZRS, GZRS, atau RA-GZRS. Disk yang tidak dikelola tidak mendukung ZRS atau GZRS.
Untuk informasi selengkapnya tentang wilayah mana yang mendukung ZRS, lihat Wilayah Azure dengan zona ketersediaan.
Redundansi di wilayah sekunder
Opsi redundansi dapat membantu memberikan durabilitas tinggi untuk aplikasi Anda. Di banyak wilayah, Anda dapat menyalin data dalam akun penyimpanan Anda ke wilayah sekunder yang terletak ratusan mil jauhnya dari wilayah utama. Menyalin akun penyimpanan Anda ke wilayah sekunder memastikan bahwa data Anda tetap tahan lama selama pemadaman regional lengkap atau bencana di mana wilayah utama tidak dapat dipulihkan.
Saat membuat akun penyimpanan, Anda memilih wilayah utama untuk akun tersebut. Wilayah sekunder yang dipasangkan ditentukan berdasarkan wilayah utama, dan tidak dapat diubah. Untuk informasi selengkapnya tentang wilayah yang didukung oleh Azure, lihat daftar wilayah Azure.
Azure Storage menawarkan dua opsi untuk menyalin data Anda ke wilayah sekunder:
Penyimpanan geo-redundan (GRS) menyalin data Anda secara sinkron dalam satu atau beberapa zona ketersediaan Azure di wilayah utama menggunakan LRS. Kemudian menyalin data Anda secara asinkron ke wilayah sekunder. Dalam wilayah sekunder, data Anda disalin secara sinkron menggunakan LRS.
Penyimpanan geo-zona-redundan (GZRS) menyalin data Anda secara sinkron di tiga atau beberapa zona ketersediaan Azure di wilayah utama menggunakan ZRS. Kemudian menyalin data Anda secara asinkron ke wilayah sekunder. Dalam wilayah sekunder, data Anda disalin secara sinkron menggunakan LRS.
Catatan
Satu-satunya perbedaan antara GRS dan GZRS adalah bagaimana data direplikasi di wilayah primer. Dalam wilayah sekunder, data selalu direplikasi secara sinkron menggunakan LRS. LRS di wilayah sekunder melindungi data Anda dari kegagalan perangkat keras.
Saat Anda menggunakan GRS atau GZRS, data di wilayah sekunder tidak tersedia untuk akses baca atau tulis kecuali ada failover ke wilayah sekunder. Untuk akses baca ke wilayah sekunder, konfigurasikan akun penyimpanan untuk menggunakan penyimpanan geo-redundan akses-baca (RA-GRS) atau penyimpanan geo-zona-redundan akses-baca (RA-GZRS). Untuk informasi selengkapnya, lihat Akses baca ke data di wilayah sekunder.
Jika wilayah utama menjadi tidak tersedia, Anda dapat memilih untuk beralih ke wilayah sekunder. Setelah operasi failover selesai, wilayah sekunder menjadi wilayah utama dan Anda dapat membaca dan menulis data. Untuk informasi selengkapnya tentang pemulihan bencana dan untuk mempelajari cara beralih ke wilayah sekunder, lihat Pemulihan bencana dan failover akun penyimpanan.
Penting
Karena data direplikasi ke wilayah sekunder secara asinkron, kegagalan yang memengaruhi wilayah utama dapat mengakibatkan kehilangan data jika wilayah utama tidak dapat dipulihkan. Interval antara penulisan terbaru ke wilayah utama dan penulisan terakhir ke wilayah sekunder disebut tujuan titik pemulihan (RPO). RPO menunjukkan titik waktu sampai mana data dapat dipulihkan. Azure Storage sekarang menawarkan replikasi prioritas geografis, yang memastikan RPO untuk blob blok kurang dari atau sama dengan 15 menit. Untuk informasi selengkapnya, lihat artikel Replikasi Azure Storage Geo Priority .
Penyimpanan redundansi geografis
Penyimpanan geo-redundan (GRS) menyalin data Anda secara sinkron ke satu atau beberapa zona ketersediaan di wilayah utama menggunakan LRS. Kemudian menyalin data Anda secara asinkron ke wilayah sekunder yang berjarak ratusan mil dari wilayah utama. GRS menawarkan durabilitas untuk sumber daya penyimpanan setidaknya 99,999999999999999% (16 9) selama tahun tertentu.
Operasi tulis pertama-tama dilakukan pada lokasi utama dan direplikasi menggunakan LRS. Pembaruan kemudian direplikasi secara asinkron ke wilayah sekunder. Ketika data ditulis ke lokasi sekunder, data juga direplikasi dalam lokasi tersebut menggunakan LRS.
Diagram berikut menunjukkan bagaimana data Anda direplikasi dengan GRS atau RA-GRS:
Penyimpanan redundan zona geografis
Penyimpanan redundan geo-zona (GZRS) menggabungkan ketersediaan tinggi yang disediakan oleh keredundansian yang tersebar di berbagai zona ketersediaan dengan perlindungan dari pemadaman regional melalui geo-replikasi. Data dalam akun GZRS disalin di tiga atau beberapa zona ketersediaan Azure di wilayah utama. Selain itu, ia juga mereplikasi ke wilayah geografis sekunder untuk perlindungan dari bencana regional. Microsoft merekomendasikan penggunaan GZRS untuk aplikasi yang membutuhkan konsistensi, durabilitas, dan ketersediaan maksimum, performa yang sangat baik, dan ketahanan untuk pemulihan bencana.
Dengan akun GZRS, Anda dapat terus membaca dan menulis data jika zona ketersediaan menjadi tidak tersedia atau tidak dapat dipulihkan. Selain itu, data Anda juga tetap tahan lama selama pemadaman regional lengkap atau bencana di mana wilayah utama tidak dapat dipulihkan. GZRS dirancang untuk menyediakan setidaknya 99,999999999999999% (16 9s) durabilitas objek selama tahun tertentu.
Diagram berikut menunjukkan bagaimana data Anda direplikasi dengan GRS atau RA-GRS:
Untuk menentukan apakah wilayah mendukung GZRS, lihat daftar wilayah Azure. Untuk mendukung GZRS, suatu wilayah harus mendukung zona availabilitas dan memiliki wilayah yang dipasangkan.
Akses baca ke data di wilayah sekunder
Penyimpanan geo redundan (dengan GRS atau GZRS) mereplikasi data Anda ke lokasi fisik lain di wilayah sekunder untuk melindungi dari pemadaman regional. Dengan akun yang dikonfigurasi untuk GRS atau GZRS, data di wilayah sekunder tidak dapat diakses langsung oleh pengguna atau aplikasi ketika pemadaman terjadi di wilayah utama, kecuali terjadi failover. Proses failover memperbarui entri DNS yang disediakan oleh Azure Storage sehingga titik akhir layanan penyimpanan di wilayah sekunder menjadi titik akhir utama baru untuk akun penyimpanan Anda. Selama proses failover, data Anda tidak dapat diakses. Setelah failover selesai, Anda dapat membaca dan menulis data ke region utama yang baru. Untuk informasi selengkapnya, lihat Cara kerja failover akun penyimpanan yang dikelola pelanggan untuk memulihkan dari pemadaman.
Jika aplikasi Anda memerlukan ketersediaan tinggi, maka Anda dapat mengonfigurasi akun penyimpanan Anda untuk akses baca ke wilayah sekunder. Saat Anda mengaktifkan akses baca ke wilayah sekunder, maka data Anda selalu tersedia untuk dibaca dari wilayah sekunder, termasuk dalam situasi di mana wilayah utama menjadi tidak tersedia. Penyimpanan geo-redundan akses baca (RA-GRS) atau penyimpanan geo-zona-redundan akses baca (RA-GZRS) mengizinkan akses baca ke wilayah sekunder.
Catatan
Azure Files tidak mendukung penyimpanan geo-redundan dengan akses baca (RA-GRS) atau penyimpanan geo-zona-redundan dengan akses baca (RA-GZRS).
Rancang aplikasi Anda untuk akses baca pada sumber sekunder
Jika akun penyimpanan Anda dikonfigurasi untuk akses baca ke wilayah sekunder, maka Anda dapat merancang aplikasi Anda untuk beralih dengan mulus ke membaca data dari wilayah sekunder jika wilayah utama menjadi tidak tersedia karena alasan apa pun.
Wilayah sekunder tersedia untuk akses baca setelah Anda mengaktifkan RA-GRS atau RA-GZRS. Ketersediaan ini memungkinkan Anda menguji aplikasi terlebih dahulu untuk memastikan bahwa aplikasi membaca dengan benar dari wilayah sekunder selama pemadaman. Untuk informasi selengkapnya tentang cara merancang aplikasi Anda untuk memanfaatkan geo redundansi, lihat Menggunakan geo redundansi untuk merancang aplikasi yang sangat tersedia.
Saat akses baca ke sekunder diaktifkan, aplikasi Anda dapat dibaca dari titik akhir sekunder dan utama. Titik akhir sekunder menambahkan akhiran -sekunder ke nama akun. Misalnya, jika titik akhir utama untuk penyimpanan Blob adalah myaccount.blob.core.windows.net, maka titik akhir sekunder adalah myaccount-secondary.blob.core.windows.net. Kunci akses akun untuk akun penyimpanan Anda sama untuk titik akhir utama dan sekunder.
Merencanakan kehilangan data
Karena data direplikasi secara asinkron dari wilayah primer ke sekunder, wilayah sekunder biasanya berada di belakang wilayah utama dalam hal operasi tulis. Jika bencana menyerang wilayah utama, kemungkinan beberapa data akan hilang dan file tersebut dalam direktori atau kontainer tidak akan konsisten. Untuk informasi selengkapnya tentang cara merencanakan potensi kehilangan data, lihat Kehilangan data dan inkonsistensi.
Ringkasan opsi redundansi
Tabel di bagian berikut ini merangkum opsi redundansi yang tersedia untuk Azure Storage.
Parameter durabilitas dan ketersediaan
Tabel berikut ini menjelaskan parameter utama untuk setiap opsi redundansi:
| Pengaturan | LRS | ZRS | GRS/RA-GRS | GZRS/RA-GZRS |
|---|---|---|---|---|
| Persen durabilitas objek selama setahun tertentu | setidaknya 99,9999999999% (11 9 detik) | setidaknya 99,99999999999% (12 angka 9) | setidaknya 99,999999999999999% (16 angka 9) | setidaknya 99,999999999999999% (16 angka 9) |
| Ketersediaan untuk permintaan baca | Setidaknya 99,9%; 99% untuk tingkat akses dingin/dingin/arsip | Setidaknya 99,9%; 99% untuk tingkat akses dingin/dingin | Setidaknya 99,9% untuk GRS; 99% untuk tingkat akses dingin/dingin/arsip Setidaknya 99,99% untuk RA-GRS; 99.9% untuk tingkat akses dingin/dingin/arsip |
Setidaknya 99,9% untuk GZRS; 99% untuk tingkat akses dingin/dingin Setidaknya 99,99% untuk RA-GZRS; 99,9% untuk tingkat akses dingin/dingin |
| Ketersediaan untuk permintaan penulisan | Setidaknya 99,9%; 99% untuk tingkat akses dingin/dingin/arsip | Setidaknya 99,9%; 99% untuk tingkat akses dingin/dingin | Setidaknya 99,9%; 99% untuk tingkat akses dingin/dingin/arsip | Setidaknya 99,9%; 99% untuk tingkat akses dingin/dingin |
Catatan: GRS menyediakan replikasi geografis tetapi tidak mengizinkan akses baca dari wilayah sekunder. Untuk mempertahankan ketersediaan baca selama pemadaman wilayah utama, RA-GRS atau RA-ZRS harus digunakan.
Untuk informasi selengkapnya, lihat Perjanjian Tingkat Layanan untuk Akun Penyimpanan.
Durabilitas dan ketersediaan berdasarkan skenario pemadaman
Tabel berikut menunjukkan apakah data Anda tahan lama dan tersedia dalam skenario tertentu, bergantung pada jenis redundansi mana yang berlaku untuk akun penyimpanan Anda:
| Skenario gangguan | LRS | ZRS | GRS/RA-GRS | GZRS/RA-GZRS |
|---|---|---|---|---|
| Sebuah simpul dalam pusat data menjadi tidak tersedia | Ya | Ya | Ya | Ya |
| Seluruh pusat data (zonal atau nonzonal) menjadi tidak tersedia | Tidak | Ya | Ya1 | Ya |
| Gangguan besar terjadi di wilayah utama. | Tidak | Tidak | Ya1 | Ya1 |
| Akses baca ke wilayah sekunder tersedia jika wilayah utama menjadi tidak tersedia | Tidak | Tidak | Ya (dengan RA-GRS) | Ya (dengan RA-GZRS) |
1 Failover akun diperlukan untuk memulihkan kemampuan menulis jika wilayah utama menjadi tidak tersedia. Untuk informasi selengkapnya, lihat Pemulihan bencana dan kegagalan akun penyimpanan.
Layanan Azure Storage yang Didukung
Tabel berikut ini memperlihatkan opsi redundansi yang didukung oleh setiap layanan Azure Storage.
| Layanan | LRS | ZRS | GRS | RA-GRS | GZRS | RA-GZRS |
|---|---|---|---|---|---|---|
| Penyimpanan Blob (termasuk Data Lake Storage) |
✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| Antrean Penyimpanan | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| Penyimpanan Berbasis Tabel | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| Azure Files | ✅ 1 | ✅ 1 | ✅ | ✅ | ||
| Disk Terkelola Azure | ✅ | ✅ 2 | ||||
| Azure Elastic SAN | ✅ | ✅ |
1 berbagi file SSD didukung di LRS dan ZRS.
2 disk terkelola ZRS memiliki batasan tertentu. Lihat bagian Batasan pada artikel opsi redundansi untuk disk terkelola untuk detailnya.
Catatan
Untuk akun penyimpanan yang menggunakan pratinjau publik tingkat pintar, konversi redundansi, dan skenario failover akun memiliki dependensi. Untuk informasi selengkapnya, lihat Mengoptimalkan biaya dengan tingkat pintar
Jenis akun penyimpanan yang didukung
Tabel berikut menunjukkan opsi redundansi mana yang didukung untuk setiap jenis akun penyimpanan. Untuk informasi jenis akun penyimpanan, lihat Gambaran umum akun penyimpanan.
| Jenis akun penyimpanan | LRS | ZRS | GRS/RA-GRS | GZRS/RA-GZRS |
|---|---|---|---|---|
| Direkomendasikan | Standar tujuan umum v2 (StorageV2)1Blok blob premium ( BlockBlobStorage)1Berbagi file dari SSD ( FileStorage) Blob halaman premium ( StorageV2) |
Standar tujuan umum v2 (StorageV2)1Blok blob premium ( BlockBlobStorage)1Berbagi file SSD ( FileStorage) |
Standar tujuan umum v2 (StorageV2)1 |
Standar tujuan umum v2 (StorageV2)1 |
| Warisan | Standar tujuan umum v1 (Storage)Blob warisan ( BlobStorage) |
Tidak Berlaku | Standar tujuan umum v1 (Storage)Blob warisan ( BlobStorage) |
Tidak Berlaku |
1 Akun jenis ini yang mengaktifkan namespace hierarkis juga mendukung opsi redundansi yang ditentukan.
Semua data untuk semua akun penyimpanan disalin dari primer ke sekunder sesuai dengan opsi redundansi akun penyimpanan. Objek yang disalin mencakup blob blok, blob penambahan, blob halaman, antrian, tabel, dan file.
Data di semua tingkatan, termasuk tingkat arsip, selalu disalin dari primer ke sekunder selama replikasi geografis. Tingkat arsip untuk Blob Storage saat ini didukung untuk akun LRS, GRS, dan RA-GRS, tetapi tidak untuk akun ZRS, GZRS, atau RA-GZRS. Untuk informasi selengkapnya tentang lapisan blob, lihat Tingkat akses untuk data blob.
Disk yang tidak dikelola tidak mendukung ZRS atau GZRS.
Untuk informasi harga untuk setiap opsi redundansi, lihat Harga Azure Storage.
Catatan
Akun penyimpanan blob blok mendukung penyimpanan redundan lokal (LRS) dan penyimpanan redundan zona (ZRS) di wilayah tertentu.
Integritas data
Azure Storage secara teratur memverifikasi integritas data yang disimpan menggunakan pemeriksaan redundansi siklik (CRC). Dan kerusakan data yang terdeteksi diperbaiki menggunakan data redundan. Azure Storage juga menghitung checksum pada semua lalu lintas jaringan untuk mendeteksi kerusakan paket data saat menyimpan atau mengambil data.