Bagikan melalui

Apa yang dimaksud dengan cadangan Layanan Azure Kubernetes?

Pencadangan Azure Kubernetes Service (AKS) adalah proses cloud-native sederhana yang dapat Anda gunakan untuk mencadangkan dan memulihkan aplikasi dan data kontainer yang berjalan di kluster AKS Anda. Anda dapat mengonfigurasi cadangan terjadwal untuk status kluster dan data aplikasi yang disimpan pada Volume Persisten Kubernetes di Azure Disk Storage berbasis driver Container Storage Interface (CSI).

Solusinya memberi Anda kontrol terperinci. Anda dapat mencadangkan atau memulihkan namespace tertentu atau seluruh kluster dengan menyimpan cadangan secara lokal dalam kontainer blob dan sebagai rekam jepret disk. Anda dapat menggunakan cadangan AKS untuk skenario end-to-end, termasuk pemulihan operasional, kloning lingkungan pengembang atau pengujian, dan skenario peningkatan kluster.

Pencadangan AKS terintegrasi dengan pusat Backup di Azure, untuk menyediakan satu tampilan yang dapat membantu Anda mengatur, memantau, mengoperasikan, dan menganalisis cadangan dalam skala besar. Cadangan Anda juga tersedia di portal Microsoft Azure di bawah Pengaturan pada menu layanan untuk instans AKS.

Bagaimana cara kerja pencadangan AKS?

Anda dapat menggunakan fitur pencadangan AKS untuk mencadangkan beban kerja AKS dan Volume Tetap yang disebarkan di kluster AKS. Solusi ini mengharuskan ekstensi Backup diinstal di dalam kluster AKS. Vault Backup berkomunikasi dengan ekstensi untuk menyelesaikan operasi pencadangan dan pemulihan. Menggunakan ekstensi Backup adalah wajib. Ekstensi harus diinstal di dalam kluster AKS untuk mengaktifkan pencadangan dan pemulihan untuk kluster. Saat mengonfigurasi cadangan AKS, Anda menambahkan nilai untuk akun penyimpanan dan kontainer blob tempat cadangan disimpan.

Bersamaan dengan ekstensi Backup, sebuah identitas pengguna (disebut identitas ekstensi) dibuat dalam grup sumber daya terkelola di cluster AKS. Identitas ekstensi diberi peran Kontributor Akun Penyimpanan pada akun penyimpanan tempat cadangan disimpan dalam kontainer blob.

Untuk mendukung kluster berbasis IP publik, privat, dan terotorisasi, pencadangan AKS mengharuskan Anda mengaktifkan fitur akses tepercaya antara kluster AKS dan Vault Backup. Akses Tepercaya memungkinkan vault Backup untuk mengakses kluster AKS karena izin khusus ditetapkan untuk operasi pencadangan. Untuk informasi selengkapnya tentang Akses Tepercaya AKS, lihat Mengaktifkan sumber daya Azure untuk mengakses kluster AKS melalui Akses Tepercaya.

Pencadangan AKS memungkinkan Anda menyimpan cadangan di Tingkat Operasional dan Tingkat Vault. Lapisan Operasional adalah penyimpanan data lokal (cadangan disimpan di penyewa Anda sebagai cuplikan). Anda sekarang dapat memindahkan satu titik pemulihan per hari dan menyimpannya dalam Lapisan Vault dalam bentuk blob (di luar lingkup penyewa Anda) dengan menggunakan cadangan AKS. Cadangan yang disimpan di Tingkat Vault juga dapat digunakan untuk memulihkan data di wilayah sekunder (wilayah berpasangan Azure).

Setelah menginstal ekstensi Cadangan dan mengaktifkan Akses Tepercaya, Anda dapat mengonfigurasi cadangan terjadwal untuk kluster sesuai dengan kebijakan pencadangan Anda. Anda juga dapat memulihkan cadangan ke kluster asli atau ke kluster yang berbeda di langganan dan wilayah yang sama. Saat menyiapkan operasi tertentu, Anda dapat memilih namespace tertentu atau seluruh kluster sebagai konfigurasi pencadangan dan pemulihan.

Fitur pencadangan AKS memungkinkan operasi pencadangan untuk sumber data AKS Anda yang terpasang di dalam kluster. Ini juga memungkinkan operasi pencadangan untuk data yang disimpan dalam Volume Persisten untuk kluster. Cadangan kemudian disimpan dalam wadah penyimpanan blob. Volume Persisten berbasis disk dicadangkan sebagai cuplikan disk dalam grup sumber daya cuplikan. Cuplikan dan status kluster digabungkan dalam blob untuk membentuk titik pemulihan yang disebut Lapisan Operasional yang disimpan di penyewa Anda. Anda juga dapat mengonversi cadangan (cadangan pertama yang berhasil dalam sehari, minggu, bulan, atau tahun) di Operational Tier ke blobs, lalu memindahkannya ke vault (di luar tenant Anda) satu kali per hari.

Catatan

Saat ini, Azure Backup hanya mendukung Volume Persisten di Azure Disk Storage berbasis driver CSI. Selama pencadangan, solusi melewati jenis Volume Persisten lainnya, seperti berbagi Azure Files dan blob. Selain itu, jika Anda menetapkan aturan retensi yang ditentukan untuk Tingkat Vault, cadangan hanya memenuhi syarat untuk dipindahkan ke vault jika Volume Persisten kurang dari atau sama dengan 1 TB.

Konfigurasi cadangan

Untuk mengonfigurasi cadangan untuk kluster AKS, pertama-tama buat vault Backup. Vault memberi Anda tampilan terkonsolidasi dari cadangan yang dikonfigurasi di berbagai sumber data. Pencadangan AKS mendukung cadangan untuk Lapisan Operasional dan Lapisan Vault.

Pengaturan redundansi penyimpanan vault Backup (penyimpanan redundan lokal atau penyimpanan geo-redundan) hanya berlaku untuk cadangan yang disimpan di Tingkat Vault. Jika Anda ingin menggunakan cadangan untuk pemulihan bencana, atur redundansi penyimpanan sebagai GRS dengan Pemulihan Lintas Wilayah diaktifkan.

Catatan

Vault Backup dan kluster AKS yang ingin Anda cadangkan atau pulihkan harus berada di wilayah dan langganan yang sama.

Cadangan AKS secara otomatis memicu pekerjaan cadangan yang dijadwalkan. Pekerjaan menyalin sumber daya kluster ke dalam kontainer blob dan membuat cuplikan bertahap dari Volume Persisten berbasis disk yang ditentukan oleh frekuensi pencadangan. Cadangan dipertahankan di Tingkat Operasional dan Tingkat Vault sesuai dengan durasi retensi yang ditentukan dalam kebijakan pencadangan. Cadangan dihapus ketika durasi selesai.

Anda dapat menggunakan cadangan AKS untuk membuat beberapa instans cadangan untuk satu kluster AKS dengan menggunakan konfigurasi cadangan yang berbeda per instans cadangan. Namun, kami sarankan Anda membuat setiap instans cadangan kluster AKS dengan salah satu dari dua cara berikut:

  • Dalam Backup vault yang berbeda
  • Dengan menggunakan kebijakan pencadangan terpisah dalam gudang pencadangan yang sama

Mengelola cadangan

Ketika konfigurasi cadangan untuk kluster AKS selesai, instans cadangan dibuat di vault Backup. Anda dapat melihat instans cadangan untuk kluster di bagian Cadangan untuk instans AKS di portal Azure. Anda dapat melakukan operasi terkait pencadangan untuk instans, seperti memulai pemulihan, pemantauan, menghentikan perlindungan, dan sebagainya, melalui instans cadangan yang sesuai.

Pencadangan AKS juga terintegrasi langsung dengan pusat Backup untuk membantu Anda mengelola perlindungan secara terpusat untuk semua kluster AKS dan beban kerja lain yang didukung cadangan. Pusat Cadangan menyediakan tampilan tunggal untuk semua kebutuhan pencadangan Anda, seperti pemantauan tugas serta status pencadangan dan pemulihan. Pusat cadangan membantu Anda memastikan kepatuhan dan tata kelola, menganalisis penggunaan cadangan, dan melakukan operasi penting untuk mencadangkan dan memulihkan data.

Pencadangan AKS menggunakan identitas terkelola untuk mengakses sumber daya Azure lainnya. Untuk mengonfigurasi cadangan kluster AKS dan memulihkan dari cadangan sebelumnya, identitas terkelola brankas Backup memerlukan serangkaian izin pada kluster AKS. Ini juga memerlukan serangkaian izin pada grup sumber daya rekam jepret tempat rekam jepret dibuat dan dikelola. Saat ini, kluster AKS memerlukan serangkaian izin pada grup sumber daya rekam jepret.

Selain itu, ekstensi Backup membuat identitas pengguna dan menetapkan sekumpulan izin untuk mengakses akun penyimpanan tempat cadangan disimpan dalam blob. Anda dapat memberikan izin ke identitas terkelola dengan menggunakan kontrol akses berbasis peran Azure. Identitas terkelola adalah jenis prinsip layanan khusus yang hanya dapat digunakan dengan sumber daya Azure. Pelajari selengkapnya tentang identitas terkelola.

Mengembalikan dari cadangan

Anda dapat memulihkan data dari waktu tertentu yang poin pemulihannya ada. Titik pemulihan dibuat saat instans cadangan dalam keadaan terlindungi. Ini dapat digunakan untuk memulihkan data sampai kebijakan cadangan menyimpan data.

Azure Backup memberi Anda opsi untuk memulihkan semua item yang dicadangkan atau menggunakan kontrol mendetail untuk memilih item spesifik dari cadangan dengan menggunakan namespace dan opsi filter lainnya. Selain itu, Anda dapat melakukan pemulihan pada kluster AKS asli (kluster yang dicadangkan) atau pada kluster AKS alternatif. Anda dapat memulihkan cadangan yang disimpan di Tingkat Operasional dan Tingkat Vault ke kluster dalam langganan yang sama atau berbeda. Hanya cadangan yang disimpan di Tier Vault yang dapat digunakan untuk memulihkan ke kluster di wilayah yang berbeda (wilayah berpasangan Azure).

Untuk memulihkan cadangan yang disimpan di Tingkat Vault, Anda harus menyediakan lokasi penahapan tempat data cadangan dihidrasi. Lokasi persiapan ini mencakup grup sumber daya dan akun penyimpanan di wilayah dan langganan yang sama dengan kluster target untuk pemulihan. Selama pemulihan, sumber daya tertentu (kontainer blob, disk, dan rekam jepret disk) dibuat sebagai bagian dari hidrasi. Mereka dibersihkan setelah operasi pemulihan selesai.

Azure Backup untuk AKS saat ini mendukung dua opsi berikut untuk skenario di mana bentrokan sumber daya terjadi. Konflik sumber daya terjadi ketika sumber daya yang diperbarui memiliki nama yang sama dengan sumber daya di kluster AKS target. Anda dapat memilih salah satu opsi ini saat menentukan konfigurasi pemulihan.

  • Lewati: Opsi ini dipilih secara default. Misalnya, jika Anda mencadangkan Klaim Volume Persisten (PVC) bernama pvc-azuredisk dan Anda memulihkannya di kluster target yang memiliki PVC dengan nama yang sama, ekstensi cadangan melewatkan pemulihan PVC yang dicadangkan. Dalam skenario seperti itu, kami sarankan Anda menghapus sumber daya dari kluster. Kemudian, lakukan operasi pemulihan agar item yang dicadangkan hanya tersedia di kluster dan tidak terlewatkan.

  • Patch: Opsi ini memungkinkan pembaruan variabel yang dapat diubah pada sumber daya yang dicadangkan ke sumber daya di kluster target. Jika Anda ingin memperbarui jumlah replika di kluster target, Anda dapat memilih patching sebagai operasi.

Catatan

Cadangan AKS saat ini tidak menghapus dan membuat ulang sumber daya di kluster target jika sudah ada. Jika Anda mencoba memulihkan Volume Persisten di lokasi asli, hapus Volume Persisten yang ada, lalu lakukan operasi pemulihan.

Gunakan kait khusus untuk pencadangan dan pemulihan

Anda dapat menggunakan kait khusus untuk mengambil cuplikan konsisten aplikasi dari volume yang digunakan untuk basis data yang diterapkan sebagai beban kerja ter-container.

Apa itu kait kustom?

Anda dapat menggunakan AKS backup untuk menjalankan custom hook sebagai bagian dari operasi pencadangan dan pemulihan. Hook dikonfigurasi untuk menjalankan satu atau beberapa perintah yang dieksekusi dalam pod di bawah kontainer selama operasi pencadangan atau setelah pemulihan data.

Anda mendefinisikan kait ini sebagai sumber daya kustom dan menerapkannya di kluster AKS yang ingin Anda cadangkan atau pulihkan. Ketika sumber daya kustom disebarkan di kluster AKS pada namespace yang diperlukan, Anda memberikan detail sebagai input dalam alur pengaturan pencadangan dan pemulihan. Ekstensi Backup menjalankan kait seperti yang didefinisikan dalam file YAML.

Catatan

Hooks tidak dieksekusi dalam shell pada wadah-wadah.

Cadangan di AKS memiliki dua jenis kait.

  • Pengait Cadangan
  • Pulihkan kait

Pengait Cadangan

Saat Anda menggunakan hook cadangan, Anda dapat mengonfigurasi perintah untuk menjalankan hook sebelum pemrosesan tindakan kustom (PreHooks). Anda juga dapat menjalankan hook setelah seluruh proses tindakan kustom selesai dan item tambahan yang ditentukan dalam tindakan kustom telah dicadangkan (PostHooks).

Misalnya, berikut adalah templat YAML untuk sumber daya kustom yang akan disebarkan dengan menggunakan kait cadangan:

apiVersion: clusterbackup.dataprotection.microsoft.com/v1alpha1
kind: BackupHook
metadata:
  # BackupHook CR Name and Namespace
  name: bkphookname0
  namespace: default
spec:
  # BackupHook is a list of hooks to execute before and after backing up a resource.
  backupHook:
    # BackupHook Name. This is the name of the hook that will be executed during backup.
    # compulsory
  - name: hook1
    # Namespaces where this hook will be executed.
    includedNamespaces: 
    - hrweb
    excludedNamespaces:
    labelSelector:
    # PreHooks is a list of BackupResourceHooks to execute prior to backing up an item.
    preHooks:
      - exec:
          # Container is the container in the pod where the command should be executed.
          container: webcontainer
          # Command is the command and arguments to execute.
          command:
            - /bin/uname
            - -a
          # OnError specifies how Velero should behave if it encounters an error executing this hook  
          onError: Continue
          # Timeout is the amount of time to wait for the hook to complete before considering it failed.
          timeout: 10s
      - exec:
          command:
            - /bin/bash
            - -c
            - echo hello > hello.txt && echo goodbye > goodbye.txt
          container: webcontainer
          onError: Continue
    # PostHooks is a list of BackupResourceHooks to execute after backing up an item.
    postHooks:
      - exec:
          container: webcontainer
          command:
            - /bin/uname
            - -a
          onError: Continue
          timeout: 10s

Pulihkan kait

Dalam skrip hook pemulihan, perintah khusus atau skrip ditulis untuk dijalankan di dalam kontainer sebuah pod AKS yang telah dipulihkan.

Berikut adalah templat YAML untuk sumber daya kustom yang disebarkan melalui restore hooks:

apiVersion: clusterbackup.dataprotection.microsoft.com/v1alpha1
kind: RestoreHook
metadata:
  name: restorehookname0
  namespace: default
spec:
  # RestoreHook is a list of hooks to execute after restoring a resource.
  restoreHook:
    # Name is the name of this hook.
  - name: myhook-1  
    # Restored Namespaces where this hook will be executed.
    includedNamespaces: 
    excludedNamespaces:
    labelSelector:
    # PostHooks is a list of RestoreResourceHooks to execute during and after restoring a resource.
    postHooks:
      - exec:
          # Container is the container in the pod where the command should be executed.
          container: webcontainer
          # Command is the command and arguments to execute from within a container after a pod has been restored.
          command:
            - /bin/bash
            - -c
            - echo hello > hello.txt && echo goodbye > goodbye.txt
          # OnError specifies how Velero should behave if it encounters an error executing this hook
          # default value is Continue
          onError: Continue
          # Timeout is the amount of time to wait for the hook to complete before considering it failed.
          execTimeout: 30s
          # WaitTimeout defines the maximum amount of time Velero should wait for the container to be ready before attempting to run the command.
          waitTimeout: 5m

Pelajari cara menggunakan hook saat pencadangan AKS.

Selama pemulihan, ekstensi cadangan menunggu kontainer muncul dan kemudian menjalankan perintah exec pada kontainer tersebut, yang ditentukan dalam hook pemulihan.

Jika Anda melakukan pemulihan ke namespace yang sama dengan yang dicadangkan, hook pemulihan tidak dijalankan. Ini hanya mencari kontainer yang baru dibuat. Hasil ini terjadi terlepas dari apakah Anda menggunakan kebijakan lompati atau patch.

Modifikasi sumber daya saat memulihkan cadangan ke kluster AKS

Anda dapat menggunakan fitur Modifikasi Sumber Daya untuk memodifikasi sumber daya Kubernetes yang dicadangkan selama pemulihan dengan menentukan patch JSON seperti configmap yang disebarkan di kluster AKS.

Membuat dan menerapkan peta konfigurasi pengubah sumber daya selama pemulihan

Untuk membuat dan menerapkan modifikasi sumber daya, ikuti langkah-langkah berikut:

  1. Buat pengubah sumber daya configmap.

    Anda perlu membuat satu configmap di namespace pilihan Anda dari file YAML yang menentukan pengubah sumber daya.

    Contoh untuk membuat perintah:

    version: v1
resourceModifierRules:
- conditions:
    groupResource: persistentvolumeclaims
    resourceNameRegex: "^mysql.*$"
    namespaces:
    - bar
    - foo
    labelSelector:
        matchLabels:
          foo: bar
  patches:
  - operation: replace
    path: "/spec/storageClassName"
    value: "premium"
  - operation: remove
    path: "/metadata/labels/test"
    • Sebelumnya configmap menerapkan patch JSON ke semua salinan Volume Persisten di namespaces bilah dan foo dengan nama yang dimulai dengan mysql dan match label foo: bar. Patch JSON menggantikan storageClassName dengan premium dan menghapus label test dari salinan Volume Persisten.
    • Di sini, namespace adalah namespace asli sumber daya yang dicadangkan, dan bukan namespace baru tempat sumber daya akan dipulihkan.
    • Anda dapat menentukan beberapa patch JSON untuk sumber daya tertentu. Patch diterapkan sesuai dengan urutan yang ditentukan dalam configmap. Patch berikutnya diterapkan secara berurutan. Jika beberapa patch ditentukan untuk jalur yang sama, patch terakhir akan mengambil alih patch sebelumnya.
    • Anda dapat menentukan beberapa resourceModifierRules di configmap. Aturan diterapkan sesuai dengan urutan yang ditentukan dalam configmap.

  2. Membuat referensi pengubah sumber daya dalam konfigurasi pemulihan

    Saat Anda melakukan operasi pemulihan, berikan ConfigMap name dan namespace tempat penyebarannya sebagai bagian dari konfigurasi pemulihan. Detail ini perlu disediakan di bawah Aturan Pengubah Sumber Daya.

    Cuplikan layar yang memperlihatkan lokasi untuk memberikan detail sumber daya.

Operasi yang didukung oleh Pengubah Sumber Daya

  • Tambahkan

    Anda dapat menggunakan operasi Tambahkan untuk menambahkan blok baru ke JSON sumber daya. Dalam contoh berikut, operasi menambahkan detail kontainer baru ke spesifikasi melalui proses penyebaran.

    version: v1
resourceModifierRules:
- conditions:
    groupResource: deployments.apps
    resourceNameRegex: "^test-.*$"
    namespaces:
    - bar
    - foo
  patches:
    # Dealing with complex values by escaping the yaml
  - operation: add
    path: "/spec/template/spec/containers/0"
    value: "{\"name\": \"nginx\", \"image\": \"nginx:1.14.2\", \"ports\": [{\"containerPort\": 80}]}"

  • Hapus

    Anda dapat menggunakan operasi Hapus untuk menghapus kunci dari JSON sumber daya. Dalam contoh berikut, operasi menghapus label dengan test sebagai kunci.

    version: v1
resourceModifierRules:
- conditions:
      groupResource: persistentvolumeclaims
      resourceNameRegex: "^mysql.*$"
      namespaces:
      - bar
      - foo
      labelSelector:
        matchLabels:
            foo: bar
  patches:
  - operation: remove
    path: "/metadata/labels/test"

  • Menggantikan

    Anda dapat menggunakan operasi Ganti untuk mengganti nilai untuk jalur yang telah disebutkan ke nilai alternatif. Dalam contoh berikut, operasi mengganti storageClassName di PVC dengan premium.

    version: v1
resourceModifierRules:
- conditions:
     groupResource: persistentvolumeclaims
     resourceNameRegex: "^mysql.*$"
     namespaces:
     - bar
     - foo
     labelSelector:
        matchLabels:
           foo: bar
  patches:
  - operation: replace
    path: "/spec/storageClassName"
    value: "premium"

  • Menyalin

    Anda dapat menggunakan operasi Salin untuk menyalin nilai dari satu jalur dari sumber daya yang ditentukan ke jalur lain.

    version: v1
resourceModifierRules:
- conditions:
    groupResource: deployments.apps
    resourceNameRegex: "^test-.*$"
    namespaces:
    - bar
    - foo
  patches:
  - operation: copy
    from: "/spec/template/spec/containers/0"
    path: "/spec/template/spec/containers/1"

  • Tes

    Anda dapat menggunakan operasi Uji untuk memeriksa apakah nilai tertentu ada di sumber daya. Jika nilai tersebut terdapat, patch akan diterapkan. Jika nilai tidak ada, patch tidak diterapkan. Dalam contoh berikut, operasi memeriksa apakah PVC tersebut memiliki premium sebagai StorageClassName dan menggantinya dengan standard jika demikian.

    version: v1
resourceModifierRules:
- conditions:
    groupResource: persistentvolumeclaims
    resourceNameRegex: ".*"
    namespaces:
    - bar
    - foo
  patches:
  - operation: test
    path: "/spec/storageClassName"
    value: "premium"
  - operation: replace
    path: "/spec/storageClassName"
    value: "standard"

  • Patch JSON

    Ini configmap menerapkan patch JSON ke semua deployment di dalam namespace secara default, dan nginx dengan nama yang dimulai dengan nginxdep. Patch JSON memperbarui jumlah replika ke 12 untuk semua penyebaran tersebut.

    version: v1
resourceModifierRules:
- conditions:
    groupResource: deployments.apps
    resourceNameRegex: "^nginxdep.*$"
    namespaces:
   - default
   - nginx
  patches:
  - operation: replace
    path: "/spec/replicas"
    value: "12"

  • Patch penggabungan JSON

    Ini configmap menerapkan patch penggabungan JSON ke semua penyebaran di namespace default dan nginx dengan nama yang dimulai dengan nginxdep. Patch penggabungan JSON akan menambahkan atau memperbarui label app dengan nilai nginx1.

    version: v1
resourceModifierRules:
  - conditions:
      groupResource: deployments.apps
      resourceNameRegex: "^nginxdep.*$"
      namespaces:
        - default
        - nginx
    mergePatches:
      - patchData: |
          {
            "metadata" : {
              "labels" : {
                "app" : "nginx1"
              }
            }
          }

  • Patch penggabungan secara strategis

    configmap ini menerapkan penggabungan patch strategis ke semua pod di namespace default yang namanya dimulai dengan nginx. Patch penggabungan strategis memperbarui gambar kontainer nginx ke mcr.microsoft.com/cbl-mariner/base/nginx:1.22.

    version: v1
resourceModifierRules:
- conditions:
    groupResource: pods
    resourceNameRegex: "^nginx.*$"
    namespaces:
    - default
  strategicPatches:
  - patchData: |
      {
        "spec": {
          "containers": [
            {
              "name": "nginx",
              "image": "mcr.microsoft.com/cbl-mariner/base/nginx:1.22"
            }
          ]
        }
      }

Tingkat penyimpanan cadangan mana yang didukung oleh cadangan AKS?

Azure Backup untuk AKS mendukung dua tingkat penyimpanan sebagai penyimpanan data cadangan:

  • Tingkat Operasional: Ekstensi Backup yang diinstal di kluster AKS terlebih dahulu mengambil cadangan dengan mengambil rekam jepret volume melalui driver CSI. Selanjutnya, menyimpan status kluster dalam wadah blob di penyewa Anda sendiri. Tingkat ini mendukung tujuan titik pemulihan (RPO) yang lebih rendah dengan durasi minimum empat jam antara dua cadangan. Selain itu, untuk volume berbasis disk Azure, Tingkat Operasional mendukung pemulihan yang lebih cepat.

  • Tingkat Vault: Untuk menyimpan data cadangan untuk durasi yang lebih lama dengan biaya yang lebih rendah daripada rekam jepret, cadangan AKS mendukung datastore standar vault. Menurut aturan retensi yang ditetapkan dalam kebijakan cadangan, pencadangan pertama yang berhasil (dari satu hari, minggu, bulan, atau tahun) dipindahkan ke kontainer blob di luar tenant Anda. Datastore ini tidak hanya memungkinkan retensi yang lebih lama, tetapi juga memberikan perlindungan ransomware. Anda juga dapat memindahkan cadangan yang disimpan di vault ke wilayah lain (wilayah berpasangan Azure) untuk pemulihan dengan mengaktifkan Geo-redundansi dan Pemulihan Lintas Wilayah di brankas Cadangan.

    Catatan

    Anda dapat menyimpan data cadangan di datastore standar vault melalui Kebijakan Pencadangan dengan menentukan aturan retensi. Setiap hari, hanya satu titik pemulihan terjadwal yang akan dipindahkan ke Tier Vault. Namun, Anda dapat memindahkan sejumlah cadangan sesuai permintaan ke vault sesuai dengan aturan yang dipilih.

Memahami harga

Anda dikenakan biaya untuk:

  • Biaya instans yang dilindungi: Azure Backup untuk AKS membebankan biaya instans yang dilindungi per namespace per bulan. Saat Anda mengonfigurasi cadangan untuk kluster AKS, instans yang dilindungi dibuat. Setiap instans memiliki sejumlah namespace tertentu yang dicadangkan seperti yang didefinisikan dalam konfigurasi cadangan. Untuk informasi selengkapnya tentang harga cadangan AKS, lihat Harga untuk pencadangan Azure dan pilih Azure Kubernetes Service sebagai beban kerja.

  • Biaya rekam jepret: Azure Backup untuk AKS melindungi Volume Persisten berbasis disk dengan mengambil rekam jepret yang disimpan dalam grup sumber daya di langganan Azure Anda. Rekam jepret ini dikenakan biaya penyimpanan rekam jepret. Karena rekam jepret tidak disalin ke vault Backup, biaya penyimpanan cadangan tidak berlaku. Untuk informasi selengkapnya tentang harga rekam jepret, lihat Harga Disk Terkelola.

  • Biaya penyimpanan cadangan: Azure Backup untuk AKS juga mendukung penyimpanan cadangan di Tingkat Vault. Anda dapat menyimpan cadangan di Tingkat Vault dengan menetapkan aturan retensi untuk standar vault dalam kebijakan cadangan, di mana satu titik pemulihan per hari dapat dipindahkan ke vault. Titik pemulihan yang disimpan di Tingkat Vault dikenakan biaya terpisah (disebut biaya penyimpanan Cadangan) sesuai dengan total data yang disimpan (dalam gigabyte) dan jenis redundansi diaktifkan pada vault Backup.

Konten terkait