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 pencadangan terjadwal untuk status kluster dan data aplikasi yang disimpan pada volume persisten di Azure Disk Storage berbasis driver CSI. Solusi tersebut memberi Anda kontrol terperinci untuk memilih namespace layanan tertentu atau seluruh kluster untuk dicadangkan atau dipulihkan dengan menyimpan cadangan secara lokal dalam kontainer blob dan sebagai snapshot disk. Anda dapat menggunakan cadangan AKS untuk skenario menyeluruh, termasuk pemulihan operasional, kloning lingkungan pengembang/pengujian, dan skenario peningkatan kluster.

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

Catatan

Pencadangan vault dan Pemulihan Lintas Wilayah untuk AKS menggunakan Azure Backup saat ini dalam pratinjau.

Bagaimana cara kerja pencadangan AKS?

Gunakan cadangan AKS untuk mencadangkan beban kerja AKS dan volume persisten yang disebarkan di kluster AKS. Solusi ini mengharuskan ekstensi Backup diinstal di dalam kluster AKS. Vault Backup berkomunikasi ke ekstensi untuk menyelesaikan operasi yang terkait dengan pencadangan dan pemulihan. Menggunakan ekstensi Backup adalah wajib, dan 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.

Bersama dengan ekstensi Backup, identitas pengguna (disebut identitas ekstensi) dibuat di grup sumber daya terkelola kluster 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 resmi, pencadangan AKS memerlukan Akses Tepercaya untuk diaktifkan antara kluster AKS dan vault Backup. Akses Tepercaya memungkinkan vault Backup mengakses kluster AKS karena izin tertentu yang ditetapkan untuk operasi pencadangan. Untuk informasi selengkapnya tentang Akses Tepercaya AKS, lihat Mengaktifkan sumber daya Azure untuk mengakses kluster AKS dengan menggunakan Akses Tepercaya.

Catatan

Pencadangan AKS memungkinkan Anda menyimpan cadangan di Tingkat Operasional. Tingkat Operasional adalah datastore lokal (di penyewa Anda sebagai rekam jepret). Anda sekarang dapat memindahkan satu titik pemulihan per hari dan menyimpannya di Tingkat Vault sebagai blob ( di luar penyewa Anda) menggunakan cadangan AKS. Anda juga dapat menggunakan brankas Cadangan untuk mengelola cadangan.

Setelah ekstensi Cadangan diinstal dan Akses Tepercaya diaktifkan, Anda dapat mengonfigurasi cadangan terjadwal untuk kluster sesuai kebijakan pencadangan Anda. Anda juga dapat memulihkan cadangan ke kluster asli atau ke kluster alternatif yang berada di langganan dan wilayah yang sama. Anda dapat memilih namespace tertentu atau seluruh kluster sebagai konfigurasi pencadangan dan pemulihan saat Anda menyiapkan operasi tertentu.

Solusi pencadangan memungkinkan operasi pencadangan untuk sumber data AKS Anda yang disebarkan di kluster dan untuk data yang disimpan dalam volume persisten untuk kluster, lalu menyimpan cadangan dalam kontainer blob. Volume persisten berbasis disk dicadangkan sebagai rekam jepret disk dalam grup sumber daya rekam jepret. Rekam jepret dan status kluster dalam blob keduanya digabungkan untuk membentuk titik pemulihan yang disimpan di penyewa Anda yang disebut Tingkat Operasional. Anda juga dapat mengonversi cadangan (pencadangan pertama yang berhasil dalam sehari, minggu, bulan, atau tahun) di Tingkat Operasional ke blob, lalu memindahkannya ke Vault (di luar penyewa Anda) sekali sehari.

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 Azure File Share dan blob. Selain itu, jika Anda telah menentukan aturan retensi untuk tingkat Vault, maka cadangan hanya memenuhi syarat untuk dipindahkan ke vault jika volume persisten berukuran kurang dari atau sama dengan 1 TB.

Konfigurasikan pencadangan

  • 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 pencadangan Tingkat Operasional dan Tingkat Vault.

    Catatan

    • Vault Backup dan kluster AKS yang ingin Anda cadangkan atau pulihkan harus berada di wilayah dan langganan yang sama.
    • Pengaturan redundansi penyimpanan vault Cadangan (LRS/GRS) 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.
  • Pencadangan AKS secara otomatis memicu pekerjaan pencadangan terjadwal. Pekerjaan menyalin sumber daya kluster ke kontainer blob dan membuat rekam jepret bertahap dari volume persisten berbasis disk sesuai frekuensi cadangan. Cadangan dipertahankan di Tingkat Operasional dan Tingkat Vault sesuai durasi retensi yang ditentukan dalam kebijakan cadangan dan dihapus setelah durasi berakhir.

    Catatan

    Anda dapat menggunakan cadangan AKS untuk membuat beberapa instans cadangan untuk satu kluster AKS dengan menggunakan konfigurasi cadangan yang berbeda per instans cadangan. Namun, setiap instans cadangan kluster AKS harus dibuat baik di brankas Cadangan yang berbeda atau dengan menggunakan kebijakan pencadangan terpisah dalam vault Cadangan 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 untuk semua kluster AKS Dan beban kerja lain yang didukung cadangan secara terpusat. Pusat Cadangan adalah tampilan tunggal untuk semua persyaratan cadangan Anda, seperti pekerjaan pemantauan dan 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 pencadangan kluster AKS dan memulihkan dari cadangan sebelumnya, identitas terkelola brankas Backup memerlukan serangkaian izin pada kluster AKS dan 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 (Azure RBAC). Identitas terkelola adalah jenis prinsip layanan khusus yang hanya dapat digunakan dengan sumber daya Azure. Pelajari selengkapnya tentang identitas terkelola.

Memulihkan dari cadangan

Anda dapat memulihkan data dari point in time apa pun di mana titik pemulihan ada. Titik pemulihan dibuat ketika instans cadangan berada dalam keadaan terlindungi dan dapat digunakan untuk memulihkan data hingga disimpan oleh kebijakan pencadangan.

Azure Backup memberi Anda opsi untuk memulihkan semua item yang dicadangkan atau menggunakan kontrol terperinci untuk memilih item tertentu dari cadangan dengan memilih namespace layanan 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 Vault ke kluster dalam langganan yang sama dan berbeda. Hanya cadangan yang disimpan di Tingkat Vault yang dapat digunakan untuk melakukan pemulihan 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 penahapan ini mencakup grup sumber daya dan akun penyimpanan di dalamnya dalam wilayah yang sama dan langganan sebagai kluster target untuk pemulihan. Selama pemulihan, sumber daya tertentu (kontainer blob, disk, dan rekam jepret disk) dibuat sebagai bagian dari hidrasi, yang kemudian dibersihkan setelah operasi pemulihan selesai.

Azure Backup untuk AKS saat ini mendukung dua opsi berikut saat melakukan operasi pemulihan ketika bentrokan sumber daya terjadi (sumber daya yang dicadangkan memiliki nama yang sama dengan sumber daya di kluster AKS target). Anda dapat memilih salah satu opsi ini saat menentukan konfigurasi pemulihan.

  1. Lewati: Opsi ini dipilih secara default. Misalnya, jika Anda telah mencadangkan PVC bernama pvc-azuredisk dan Anda memulihkannya dalam kluster target yang memiliki PVC dengan nama yang sama, maka ekstensi cadangan melompati pemulihan klaim volume persisten (PVC) yang dicadangkan. Dalam skenario seperti itu, kami sarankan Anda untuk menghapus sumber daya dari kluster, lalu melakukan operasi pemulihan sehingga item yang dicadangkan hanya tersedia di kluster dan tidak dilewati.

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

Catatan

Pencadangan 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.

Menggunakan kait kustom untuk pencadangan dan pemulihan

Anda dapat menggunakan kait kustom untuk mengambil rekam jepret volume yang konsisten dengan aplikasi yang digunakan untuk database yang disebarkan sebagai beban kerja dalam kontainer.

Apa itu kait kustom?

Anda dapat menggunakan cadangan AKS untuk menjalankan kait kustom sebagai bagian dari operasi pencadangan dan pemulihan. Hook adalah perintah yang dikonfigurasi untuk menjalankan satu atau beberapa perintah untuk dijalankan dalam pod di bawah kontainer selama operasi pencadangan atau setelah pemulihan. Anda menentukan kait ini sebagai sumber daya kustom dan menyebarkannya di kluster AKS yang ingin Anda cadangkan atau pulihkan. Ketika sumber daya kustom disebarkan di kluster AKS di namespace yang diperlukan, Anda memberikan detail sebagai input untuk alur untuk mengonfigurasi pencadangan dan pemulihan. Ekstensi Backup menjalankan kait seperti yang didefinisikan dalam file YAML.

Catatan

Kait tidak dijalankan dalam shell pada kontainer.

Cadangan di AKS memiliki dua jenis kait:

  • Kait cadangan
  • Memulihkan kait

Kait cadangan

Dalam hook cadangan, Anda dapat mengonfigurasi perintah untuk menjalankan kait sebelum pemrosesan tindakan kustom (pra-hook), atau setelah semua tindakan kustom selesai dan item tambahan apa pun yang ditentukan oleh tindakan kustom dicadangkan (pasca-kait).

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

Memulihkan kait

Dalam skrip hook pemulihan, perintah kustom atau skrip ditulis untuk dijalankan dalam kontainer pod AKS yang dipulihkan.

Berikut adalah templat YAML untuk sumber daya kustom yang akan disebarkan dengan menggunakan kait pemulihan:

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 kait selama pencadangan AKS.

Catatan

  • 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 yang dicadangkan, kait pemulihan tidak akan dijalankan karena hanya mencari kontainer baru yang akan ditelurkan. Ini terlepas dari apakah kebijakan lompati atau patch dipilih.

Mengubah 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 configmap pengubah sumber daya.

    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"
    
    • Peta konfigurasi di atas menerapkan patch JSON ke semua Salinan Volume Persisten di bilah namespace 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 urutan yang ditentukan dalam peta konfigurasi. 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 dalam peta konfigurasi. Aturan diterapkan sesuai urutan yang ditentukan dalam configmap.
  2. Membuat referensi pengubah sumber daya dalam konfigurasi pemulihan

    Saat Anda melakukan operasi pemulihan, berikan nama ConfigMap dan Namespace tempatnya disebarkan sebagai bagian dari konfigurasi pemulihan. Detail ini perlu disediakan di bawah Aturan Pengubah Sumber Daya.

    Cuplikan layar 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 di bawah ini, operasi menambahkan detail kontainer baru ke spesifikasi dengan 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 di bawah ini, operasi menghapus label dengan uji 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 disebutkan ke operasi alternatif. Dalam contoh di bawah ini, operasi mengganti storageClassName dalam klaim volume persisten 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"
    
  • Ujian

    Anda dapat menggunakan operasi Uji untuk memeriksa apakah nilai tertentu ada di sumber daya. Jika nilai ada, patch diterapkan. Jika nilai tidak ada, patch tidak diterapkan. Dalam contoh di bawah ini, operasi memeriksa apakah klaim volume persisten memiliki premium sebagai StorageClassName dan mengganti jika dengan standar, jika benar.

    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"
    
  • JSON Patch

    Peta konfigurasi ini menerapkan patch JSON ke semua penyebaran di namespace secara default dan ''nginxwith the name that starts withnginxdep'. Patch JSON memperbarui jumlah replika menjadi 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

    Peta konfigurasi ini akan menerapkan Patch Penggabungan JSON ke semua penyebaran di namespace default dan nginx dengan nama yang dimulai dengan nginxdep. JSON Merge Patch akan menambahkan/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 Strategis

    Peta konfigurasi ini akan menerapkan Patch Penggabungan Strategis ke semua pod di namespace default dengan nama yang dimulai dengan nginx. Patch Penggabungan Strategis akan 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 cadangan AKS?

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

  • Tingkat Operasional: Ekstensi Cadangan yang diinstal di kluster AKS terlebih dahulu mengambil cadangan dengan mengambil rekam jepret Volume melalui Driver CSI dan menyimpan status kluster dalam kontainer blob di penyewa Anda sendiri. Tingkat ini mendukung RPO yang lebih rendah dengan durasi minimum antara dua cadangan empat jam. Selain itu, untuk volume berbasis Disk Azure, Tingkat Operasional mendukung pemulihan yang lebih cepat.

  • Tingkat standar vault (pratinjau): Untuk menyimpan data cadangan untuk durasi yang lebih lama dengan biaya lebih rendah daripada rekam jepret, cadangan AKS mendukung datastore standar Vault. Sesuai aturan retensi yang ditetapkan dalam kebijakan pencadangan, pencadangan pertama yang berhasil (dari satu hari, minggu, bulan, atau tahun) dipindahkan ke kontainer blob di luar penyewa 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 redundansi Geo dan Pemulihan Lintas Wilayah di vault Cadangan.

Catatan

Anda dapat menyimpan data cadangan di datastore standar vault melalui Kebijakan Pencadangan dengan menentukan aturan retensi. Hanya satu titik pemulihan terjadwal per hari yang dipindahkan ke Tingkat Vault. Namun, Anda dapat memindahkan sejumlah cadangan sesuai permintaan ke Vault sesuai 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 layanan tertentu yang dicadangkan seperti yang didefinisikan dalam konfigurasi cadangan. Untuk informasi selengkapnya tentang harga cadangan AKS, lihat Harga untuk Cloud Backup 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. Ini dapat dicapai dengan menentukan aturan retensi untuk standar vault dalam kebijakan cadangan, dengan satu titik pemulihan per hari memenuhi syarat untuk dipindahkan ke Vault. Titik pemulihan yang disimpan di Tingkat Vault dikenakan biaya terpisah yang disebut biaya Penyimpanan Cadangan sesuai total data yang disimpan (dalam GB) dan jenis redundansi yang diaktifkan pada Brankas Cadangan.

Langkah selanjutnya