Keandalan dalam Azure Backup

Azure Backup adalah layanan Azure bawaan yang melindungi beban kerja cloud dan lokal dengan aman. Backup dapat menskalakan perlindungannya di berbagai beban kerja dan menyediakan integrasi asli dengan beban kerja Azure, termasuk mesin virtual (VM), SAP Hana di VM Azure, SQL di VM Azure, Azure Files, Azure Blob Storage, Azure Data Lake Storage, Azure Managed Disks, volume Azure Elastic SAN, dan Azure Kubernetes Service (AKS). Anda tidak perlu mengelola otomatisasi atau infrastruktur, menulis skrip, atau menyediakan penyimpanan.

Saat Anda menggunakan Azure, keandalan adalah tanggung jawab bersama. Microsoft menyediakan berbagai kemampuan untuk mendukung ketahanan dan pemulihan. Anda bertanggung jawab untuk memahami cara kerja kemampuan tersebut dalam semua layanan yang Anda gunakan, dan memilih kemampuan yang Anda butuhkan untuk memenuhi tujuan bisnis dan tujuan waktu aktif Anda.

Artikel ini menjelaskan bagaimana Pencadangan dapat tahan terhadap berbagai potensi pemadaman dan masalah, termasuk kesalahan sementara, pemadaman zona ketersediaan, dan pemadaman wilayah. Ini juga menyoroti beberapa informasi utama tentang perjanjian tingkat layanan Cadangan (SLA).

Nota

Artikel ini menjelaskan bagaimana layanan Backup itu sendiri tahan terhadap berbagai masalah dan bagaimana Anda dapat membuatnya lebih tangguh. Ini tidak menjelaskan cara menggunakan Backup untuk melindungi VM, data, atau aset lainnya. Untuk mempelajari tentang cara menggunakan Pencadangan, lihat Gambaran Umum Pencadangan.

Rekomendasi implementasi produksi untuk keandalan

Untuk mencadangkan beban kerja produksi, kami sarankan Anda mengonfigurasi vault dengan cara berikut:

  • Gunakan penyimpanan zona redundan (ZRS) sebagai tingkat redundansi minimum untuk cadangan Anda. ZRS mereplikasi cadangan Anda di beberapa zona ketersediaan sehingga Anda dapat memulihkan cadangan selama pemadaman zona ketersediaan.

  • Jika Anda menggunakan penyimpanan geo-redundan (GRS) untuk mereplikasi cadangan Anda ke wilayah Azure yang dipasangkan, aktifkan pemulihan lintas wilayah (CRR) untuk sumber data yang didukung. CRR memungkinkan Anda memulihkan cadangan ke wilayah yang dipasangkan setiap saat.

Bagian berikut dari artikel ini memberikan detail selengkapnya tentang konfigurasi ini.

Nota

Rekomendasi redundansi penyimpanan ini berlaku untuk lokasi di mana salinan cadangan direplikasi, bukan ke layanan Backup atau sumber daya yang Anda cadangkan. Perlindungan cadangan dan redundansi penyimpanan saling melengkapi. Pencadangan melindungi dari kehilangan data, dan redundansi melindungi dari kegagalan infrastruktur.

Untuk daftar rekomendasi lain untuk Pencadangan, termasuk rekomendasi yang berfokus pada keandalan, lihat Pencadangan beban kerja cloud dan lokal ke cloud.

Gambaran umum arsitektur keandalan

Bagian ini menjelaskan beberapa aspek penting tentang cara kerja layanan yang paling relevan dari perspektif keandalan. Bagian ini memperkenalkan arsitektur logis, yang mencakup beberapa sumber daya dan fitur yang Anda sebarkan dan gunakan. Ini juga membahas arsitektur fisik, yang memberikan detail tentang cara kerja layanan di bawah sampul.

Arsitektur logika

Pencadangan dapat mencadangkan dan memulihkan berbagai sumber data. Anda mengonfigurasi cadangan secara berbeda tergantung pada sumber data yang Anda kerjakan. Sumber data berikut ini umum:

  • Azure VM
  • Berbagai database
  • akun Blob Storage
  • Kluster AKS
  • Server lokal melalui agen Microsoft Azure Recovery Services (MARS)

Cadangan menyimpan data yang dicadangkan di vault. Vault adalah entitas penyimpanan online di Azure yang menyimpan data, seperti salinan cadangan, titik pemulihan, dan kebijakan pencadangan. Brankas Layanan Pemulihan dan Brankas Cadangan adalah dua jenis brankas. Anda mungkin menggunakan satu atau kedua jenis tergantung pada apa yang perlu Anda lindungi. Untuk daftar sumber data yang didukung setiap jenis vault, lihat FAQ tentang vault yang didukung untuk pencadangan dan pemulihan.

Pekerjaan mewakili aktivitas pencadangan atau pemulihan data Anda. Pekerjaan pencadangan mencakup operasi terjadwal atau sesuai permintaan yang menyalin data Anda dari sumber ke vault. Pekerjaan pemulihan mencakup operasi yang memulihkan data Anda dari penyimpanan cadangan ke lokasi target. Setiap pekerjaan memiliki pengidentifikasi unik dan pelacakan status sehingga Anda dapat memantau kemajuan dan memecahkan masalah yang terjadi selama operasi pencadangan dan pemulihan. Anda juga membuat kebijakan pencadangan yang terkait dengan tugas. Kebijakan menentukan konfigurasi seperti jadwal pencadangan dan berapa lama Anda ingin menyimpan data.

Vault menyimpan kebijakan dan konfigurasi cadangan Anda bersama dengan metadata tentang pekerjaan, yang memungkinkan Anda melacak pekerjaan dan memecahkan masalah.

Arsitektur fisik

Microsoft mengelola infrastruktur layanan Backup inti. Infrastruktur ini bertanggung jawab atas manajemen dan pengoperasian layanan, termasuk memicu dan memantau pekerjaan.

Backup menyimpan cadangannya di brankas. Vault dibangun di atas Azure Storage. Vault secara otomatis mereplikasi data cadangan Anda, dan durabilitas dan ketahanan cadangan bergantung pada redundansi penyimpanan vault.

  • Simpan redundan secara otomatis (LRS) mereplikasi data dalam vault Anda ke satu atau beberapa zona ketersediaan Azure yang terletak di wilayah utama pilihan Anda. Anda tidak dapat memilih zona ketersediaan pilihan Anda, tetapi Azure dapat memindahkan atau memperluas akun LRS di seluruh zona untuk meningkatkan penyeimbangan beban. Data Anda tidak dijamin tersebar di seluruh zona. Untuk informasi selengkapnya, lihat Gambaran umum zona ketersediaan.

  • ZRS dan GRS memberikan perlindungan ekstra. Artikel ini menjelaskan opsi ini secara rinci.

Nota

Beberapa sumber data mendukung pencadangan lapisan operasional, yang menyimpan data di lokasi lain daripada di vault. Misalnya, cadangan disk terkelola Azure dan AKS mendukung cadangan tingkat operasional, yang disimpan dalam rekam jepret disk. Artikel ini tidak membahas penyimpanan cadangan tingkat operasional, tetapi Anda dapat menerapkan panduan ketahanan dalam artikel ini untuk operasi Pencadangan dan alur kerja untuk jenis cadangan ini.

Ketahanan terhadap kesalahan sementara

Kesalahan sementara adalah kegagalan yang bersifat sementara dan intermiten dalam komponen. Mereka sering terjadi di lingkungan terdistribusi seperti cloud, dan mereka adalah bagian normal dari operasi. Kesalahan sementara memperbaiki diri setelah waktu yang singkat. Penting bahwa aplikasi Anda dapat menangani kesalahan sementara, biasanya dengan mencoba kembali permintaan yang terpengaruh.

Semua aplikasi yang dihosting cloud harus mengikuti panduan penanganan kesalahan sementara Azure saat berkomunikasi dengan API, database, dan komponen lain yang dihosting cloud. Untuk informasi selengkapnya, lihat Rekomendasi untuk menangani kesalahan sementara.

Saat Anda menggunakan Pencadangan, alur kerja pencadangan dan pemulihan tahan terhadap kegagalan terputus-putus. Layanan secara otomatis mencoba kembali ketika mengalami kesalahan jaringan sementara atau gangguan layanan sementara. Anda tidak mengonfigurasi logika pengulangan apa pun. Jika Anda mengalami kesalahan berulang, lihat Memecahkan masalah operasi manajemen brankas Cadangan.

Ketahanan terhadap kegagalan zona ketersediaan

Zona ketersediaan adalah grup pusat data yang terpisah secara fisik dalam wilayah Azure. Ketika satu zona gagal, layanan dapat melakukan failover ke salah satu zona yang tersisa.

Pencadangan secara terpisah mengelola konfigurasi zona ketersediaan layanan dan untuk data Anda.

  • Layanan: Layanan Pencadangan secara otomatis tahan zona di wilayah yang didukung. Namun, ketahanan zona yang telah terintegrasi ini tidak berlaku untuk data cadangan Anda.

  • Redundansi penyimpanan cadangan: Pilih tingkat redundansi yang Anda inginkan untuk data cadangan Anda dengan mengonfigurasi vault Layanan Pemulihan atau brankas Cadangan Anda. Jika Anda memilih ZRS, salinan data cadangan Anda secara otomatis disimpan di beberapa zona ketersediaan di wilayah Azure yang Anda gunakan.

    Jika Anda tidak menggunakan ZRS, data cadangan Anda dianggap nonzonal dan mungkin disimpan di zona mana pun. Jika ada zona di wilayah tersebut yang bermasalah, data cadangan nonzonal mungkin tidak tersedia.

Diagram yang memperlihatkan layanan inti Cadangan, yang secara otomatis tahan zona, dan penyimpanan cadangan redundan zona.

Persyaratan

  • Dukungan wilayah: Layanan ini secara otomatis tahan zona di semua wilayah yang memiliki zona ketersediaan. Vault ZRS didukung di kawasan yang sama.

  • Hanya untuk vault baru: Konfigurasikan ZRS di vault Anda sebelum pencadangan pertama.

Biaya

Saat mengaktifkan ZRS untuk cadangan, Anda dikenakan biaya dengan tarif yang berbeda dari LRS karena replikasi tambahan dan overhead penyimpanan. Untuk informasi selengkapnya, lihat Harga cadangan.

Mengonfigurasi dukungan zona ketersediaan

  • Buat vault baru yang menggunakan ZRS: Konfigurasikan redundansi penyimpanan saat Anda membuat vault. Anda mengikuti langkah-langkah yang berbeda tergantung pada jenis vault. Untuk informasi lebih lanjut, baca artikel berikut:

  • Konfigurasikan ZRS pada vault yang ada: Untuk Brankas Cadangan, konfigurasikan redundansi penyimpanan saat Anda membuat vault. Setelah Anda membuat vault Backup, pengaturan dikunci dan Anda tidak dapat mengubahnya.

    Untuk brankas Layanan Pemulihan, Anda harus mengonfigurasi redundansi penyimpanan sebelum melindungi beban kerja. Setelah Anda melindungi beban kerja, pengaturan dikunci dan Anda tidak dapat mengubahnya.

    Anda dapat membuat vault baru yang dikonfigurasi untuk menggunakan ZRS dan menetapkan ulang beban kerja Anda ke vault baru. Namun, pendekatan ini membutuhkan waktu henti. Untuk informasi selengkapnya, lihat Mengubah pengaturan default. Anda juga bertanggung jawab untuk menghapus secara manual poin pemulihan yang ada dan data lainnya karena kebijakan retensi dari vault lama sudah tidak berlaku lagi. Untuk informasi selengkapnya, lihat Menghapus vault Cadangan atau Menghapus vault Layanan Pemulihan.

Perilaku ketika semua zona sehat

Bagian ini menjelaskan apa yang diharapkan ketika Anda mengonfigurasi vault untuk ZRS, dan semua zona beroperasi.

  • Operasi lintas zona: Pekerjaan pencadangan berjalan pada infrastruktur yang direplikasi di seluruh zona. Azure mengelola pekerjaan dari infrastruktur di zona mana pun.

  • Replikasi data lintas zona: ZRS mereplikasi data yang dicadangkan di seluruh zona. Replikasi terjadi secara sinkron, yang berarti bahwa beberapa zona mengakui setiap operasi tulis sebelum selesai.

Perilaku selama kegagalan zona

Bagian ini menjelaskan apa yang diharapkan ketika Anda mengonfigurasi vault untuk ZRS, dan terjadi gangguan di salah satu zona.

  • Detection and response: Untuk layanan Backup itu sendiri, Microsoft bertanggung jawab untuk mendeteksi kegagalan di zona ketersediaan dan merespons. Anda tidak perlu melakukan apa pun untuk memulai failover zona.

    Penting

    Untuk data atau sumber daya apa pun yang tidak tersedia karena pemadaman zona, Anda bertanggung jawab untuk mendeteksi pemadaman dan mengambil tindakan pemulihan, termasuk memulihkan cadangan ke zona yang sehat.

  • Notification: Microsoft tidak secara otomatis memberi tahu Anda saat zona tidak berfungsi. Namun, Anda dapat menggunakan Azure Resource Health untuk memantau kesehatan sumber daya individual, dan Anda dapat menyiapkan pemberitahuan Resource Health untuk memberi tahu Anda tentang masalah. Anda juga dapat menggunakan Azure Service Health untuk memahami kesehatan keseluruhan layanan, termasuk kegagalan zona apa pun, dan Anda dapat menyiapkan pemberitahuan Service Health untuk memberi tahu Anda tentang masalah.

  • Permintaan aktif: Perilaku pekerjaan aktif bergantung pada zona yang mengalami kegagalan.

    • Untuk sumber data apa pun di zona ketersediaan yang gagal, kegagalan zona membuat sumber data tidak tersedia. Pekerjaan aktif mungkin menjeda atau gagal.

    • Untuk sumber data apa pun di zona ketersediaan sehat yang menjalankan pekerjaan aktif, sejumlah kecil waktu henti, biasanya beberapa detik, mungkin terjadi saat platform beralih ke zona ketersediaan sehat untuk layanan Backup.

  • Kehilangan data yang diharapkan: Jumlah kehilangan data yang diharapkan juga dikenal sebagai tujuan titik pemulihan (RPO). RPO untuk data cadangan Anda bergantung pada beberapa faktor, termasuk jadwal pencadangan Anda. Secara umum, untuk pemadaman zona, tidak diharapkan ada kehilangan data yang dicadangkan karena semua data direplikasi secara sinkron di seluruh zona.

  • Waktu henti yang diharapkan: Jumlah waktu henti yang diharapkan juga dikenal sebagai tujuan waktu pemulihan (RTO). RTO berbeda untuk setiap skenario berikut:

    • Untuk sumber data apa pun di zona ketersediaan yang gagal, sumber data mungkin tidak tersedia sampai zona pulih. Pekerjaan pencadangan mungkin gagal dijalankan hingga sumber data tersedia lagi. RTO tidak ditentukan.

    • Untuk sumber data apa pun di zona ketersediaan sehat, sejumlah kecil waktu henti, biasanya beberapa detik, mungkin terjadi saat platform beralih ke zona ketersediaan sehat untuk layanan Backup.

  • Redistribusi: Pekerjaan berikutnya berjalan secara otomatis menggunakan infrastruktur di zona sehat selama sumber data tersedia.

    Anda bertanggung jawab untuk memulihkan cadangan Anda ke infrastruktur di zona yang sehat dan untuk mengonfigurasi ulang load balancer, klien, dan sistem lainnya untuk mengalihkan lalu lintas ke infrastruktur yang sehat di zona baru.

Pemulihan Zona

Saat zona ketersediaan pulih, Backup secara otomatis memulihkan operasi di zona ketersediaan dan mengalihkan lalu lintas antara zona seperti biasa. Pekerjaan terus berjalan dan data tetap tersedia.

Uji kegagalan zona

Platform Backup mengelola perutean lalu lintas, replikasi data, failover, dan failback. Fitur ini dikelola sepenuhnya, sehingga Anda tidak perlu memulai atau memvalidasi proses kegagalan zona ketersediaan.

Ketahanan terhadap kegagalan di seluruh wilayah

Backup mendukung geo-redundansi dan failover melalui GRS dan CRR.

Penting

GRS untuk Backup hanya berfungsi dalam wilayah Azure berpasangan.

Penyimpanan geo-redundan dan pemulihan lintas wilayah

Untuk mencapai redundansi regional untuk data cadangan Anda, gunakan Backup untuk mereplikasi cadangan Anda ke wilayah Azure dipasangkan dengan menggunakan GRS. GRS melindungi cadangan Anda dari pemadaman regional.

Wilayah tempat Anda menyebarkan vault disebut wilayah utama. Sumber data Anda harus berada di wilayah utama. Anda tidak dapat mengonfigurasi cadangan ke vault di wilayah lain.

Wilayah berpasangan juga dikenal sebagai wilayah sekunder.

Diagram yang memperlihatkan bagaimana data direplikasi dengan menggunakan GRS.

Jika Anda tidak mengonfigurasi GRS dan pemadaman terjadi di wilayah vault, Anda mungkin dapat mengakses vault dan melihat item cadangan. Namun, tanpa redundansi regional, data cadangan yang mendasar tetap tidak tersedia untuk operasi pemulihan.

Pemulihan Lintas Wilayah

Saat Anda mengonfigurasi GRS pada vault, Microsoft menyediakan cadangan di wilayah berpasangan setelah pemadaman di wilayah utama terjadi. Jika sumber data Anda mendukung CRR, Anda dapat memulihkan dari titik pemulihan wilayah sekunder bahkan ketika tidak ada pemadaman yang terjadi di wilayah utama. CRR juga memungkinkan Anda menjalankan latihan untuk menilai ketahanan terhadap pemadaman regional. Saat Anda mengaktifkan CRR, Microsoft meningkatkan penyimpanan cadangan Anda dari GRS ke penyimpanan geo-redundan akses baca (RA-GRS).

Persyaratan

  • dukungan Region: GRS for Backup hanya berfungsi dalam wilayah Azure pair.

  • Hanya vault baru: Anda harus mengonfigurasi GRS pada vault Anda sebelum pencadangan pertama dilakukan.

Pertimbangan

  • CRR: Setelah Anda mengaktifkan CRR, item cadangan dapat memakan waktu hingga 48 jam untuk tersedia di wilayah sekunder.

Biaya

Brankas GRS dikenakan biaya tambahan untuk replikasi lintas wilayah dan penyimpanan di wilayah sekunder. Transfer data antara wilayah Azure dikenakan biaya berdasarkan tarif bandwidth standar antarregion. CRR dikenakan tarif yang berbeda karena Microsoft meningkatkan penyimpanan vault Anda dari GRS ke RA-GRS. Untuk informasi selengkapnya, lihat Harga cadangan.

Mengonfigurasi dukungan multiregional

  • Buat vault baru yang menggunakan GRS dan CRR: Saat membuat vault, Anda juga harus mengonfigurasi redundansi penyimpanan. Setelah memilih GRS, Anda dapat mengaktifkan CRR secara opsional di vault. Langkah-langkah yang Anda ikuti bergantung pada jenis vault. Untuk informasi lebih lanjut, baca artikel berikut:

  • Konfigurasikan GRS dan CRR pada vault yang ada: Untuk vault Backup, Anda harus mengonfigurasi redundansi penyimpanan saat membuat vault.

    Untuk Layanan Pemulihan vault, Anda harus mengonfigurasi redundansi penyimpanan sebelum melindungi setiap beban kerja. Setelah beban kerja dilindungi, pengaturan dikunci dan Anda tidak dapat mengubahnya.

    Anda dapat mengaktifkan CRR pada vault GRS yang ada. Setelah mengaktifkan CRR, Anda tidak dapat menonaktifkannya.

Perilaku ketika semua wilayah sehat

Bagian ini menjelaskan apa yang diharapkan saat Anda mengonfigurasi vault untuk menggunakan GRS dan semua wilayah dalam keadaan operasional.

  • Operasi lintas wilayah: Pencadangan selalu dilakukan di wilayah utama, yakni wilayah tempat vault dan sumber data disebarkan.

  • Replikasi data lintas wilayah: Saat Anda mengonfigurasi vault untuk menggunakan GRS, pencadangan terlebih dahulu dilakukan ke wilayah utama dengan menggunakan LRS. Setelah berhasil diselesaikan di wilayah utama, data direplikasi secara asinkron ke wilayah sekunder. Wilayah sekunder menggunakan LRS untuk menyimpan data. Data cadangan dapat memakan waktu hingga 12 jam untuk mereplikasi dari wilayah utama ke wilayah sekunder.

Perilaku selama kegagalan wilayah

Bagian ini menjelaskan apa yang dapat Anda harapkan ketika Anda mengonfigurasi vaults untuk menggunakan GRS dan terjadi pemadaman di wilayah utama.

  • Deteksi dan respons: Untuk sumber data yang mendukung CRR dan yang telah diaktifkan pada vault, Anda dapat memulai inisiasi CRR sendiri ke wilayah yang dipasangkan kapan saja, termasuk saat terjadi pemadaman wilayah atau bencana. Anda bertanggung jawab untuk mendeteksi pemadaman dan mengambil tindakan pemulihan, termasuk memulihkan cadangan ke wilayah yang sehat.

    Untuk semua skenario lainnya, data yang direplikasi ke wilayah sekunder tersedia untuk dipulihkan di wilayah sekunder hanya jika Azure mendeklarasikan bencana di wilayah utama. Microsoft bertanggung jawab untuk menyatakan bencana. Jumlah waktu yang diperlukan untuk menyatakan bencana tergantung pada tingkat keparahan insiden dan waktu yang diperlukan untuk menilai situasi. Microsoft biasanya mendeklarasikan bencana hanya setelah jangka waktu yang lama.

  • Notification: Microsoft tidak secara otomatis memberi tahu Anda saat suatu wilayah tidak berfungsi. Namun:

    • Anda dapat menggunakan Azure Resource Health untuk memantau kesehatan sumber daya individual, dan Anda dapat menyiapkan pemberitahuan Resource Health untuk memberi tahu Anda tentang masalah.

    • Anda dapat menggunakan Azure Service Health untuk memahami kesehatan keseluruhan layanan, termasuk kegagalan wilayah apa pun, dan Anda dapat menyiapkan pemberitahuan Service Health untuk memberi tahu Anda tentang masalah.

  • Kehilangan data yang diharapkan: RPO untuk data cadangan Anda bergantung pada beberapa faktor, termasuk jadwal pencadangan Anda. Secara umum, untuk pemadaman wilayah, harapkan hingga 36 jam kehilangan data karena RPO di wilayah utama adalah 24 jam, dan dapat memakan waktu hingga 12 jam untuk mereplikasi data cadangan dari wilayah primer ke sekunder.

  • Waktu henti yang diperkirakan: RTO berbeda untuk setiap skenario berikut:

    • Sumber data dan sumber daya lain di wilayah yang gagal mungkin tidak tersedia sampai wilayah pulih, sehingga RTO tidak terdefinisi.

    • Pencadangan mungkin tidak dapat melakukan operasi pencadangan atau pemulihan di wilayah yang mengalami kegagalan hingga wilayah pulih, sehingga RTO tidak terdefinisi.

    • Jika Anda menggunakan CRR, RTO untuk memulai pemulihan cadangan yang sudah direplikasi ke wilayah yang dipasangkan adalah nol. Jika Anda tidak menggunakan CRR, RTO bergantung pada berapa lama waktu yang diperlukan Microsoft untuk mendeklarasikan bencana di wilayah yang gagal.

  • Redistribusi: Tidak ada tugas pencadangan yang dapat dijalankan saat wilayah utama offline. Anda dapat memulihkan data di vault, tetapi Anda tidak dapat menambahkan data baru.

    Anda bertanggung jawab untuk memulihkan cadangan Anda ke infrastruktur di wilayah yang dipasangkan dan untuk mengonfigurasi ulang load balancer, klien, dan sistem lainnya untuk mengalihkan lalu lintas ke infrastruktur yang sehat di wilayah yang dipasangkan.

Pemulihan wilayah

Ketika wilayah utama sudah pulih, Pencadangan secara otomatis mengembalikan operasi di wilayah tersebut. Pekerjaan dilanjutkan dan data tetap tersedia.

Pengujian untuk mendeteksi kegagalan wilayah

Anda dapat menggunakan CRR untuk melakukan operasi pemulihan ke wilayah yang dipasangkan. Anda dapat menggunakan pendekatan ini untuk memverifikasi pemulihan dan proses pemulihan lainnya.

Ketahanan terhadap kehilangan data cadangan

Cadangan menyediakan dua fitur pemulihan utama untuk mencegah penghapusan data cadangan Anda yang tidak disengaja atau berbahaya:

  • Penghapusan sementara memungkinkan Anda memulihkan objek dan vault yang dihapus selama periode retensi yang dapat dikonfigurasi. Secara default, periode ini adalah 14 hari, tetapi Anda dapat mengeditnya. Anggap penghapusan lunak sebagai tempat daur ulang untuk cadangan dan vault Anda. Untuk informasi selengkapnya, lihat Aman secara default dengan penghapusan lunak untuk Backup.

  • Vault yang tidak dapat diubah (immutable vaults) dapat membantu Anda melindungi data cadangan Anda dengan menghalangi operasi yang dapat mengakibatkan hilangnya titik pemulihan. Anda dapat mengunci pengaturan brankas agar tidak dapat diubah. Anda juga dapat menggunakan penyimpanan tulis sekali, membaca banyak (WORM) untuk cadangan guna mencegah aktor jahat menonaktifkan kekekalan dan menghapus cadangan. Untuk informasi selengkapnya, lihat Brankas Immutable sebagai Pencadangan.

Perjanjian tingkat layanan

Perjanjian tingkat layanan (SLA) untuk layanan Azure menjelaskan ketersediaan yang diharapkan dari setiap layanan dan kondisi yang harus dipenuhi solusi Anda untuk mencapai harapan ketersediaan tersebut. Untuk informasi selengkapnya, lihat SLA untuk layanan online.

SLA Cadangan mencakup ketersediaan layanan untuk operasi pencadangan dan pemulihan. Agar tercakup oleh SLA, Anda perlu mencoba kembali pekerjaan pencadangan atau pemulihan yang gagal setidaknya sekali setiap 30 menit.

Konten terkait

  • Last updated on