Azure Kubernetes Service とは

[アーティクル]
09/09/2024

Azure Kubernetes Service (AKS) バックアップは、AKS クラスターで実行されているコンテナー化されたアプリケーションとデータのバックアップと復元に使用できる、クラウドネイティブのシンプルなプロセスです。 CSI ドライバーベースの Azure Disk Storage の永続ボリュームに保存されているクラスターの状態とアプリケーションデータのスケジュールされたバックアップを構成できます。このソリューションでは、バックアップを BLOB コンテナーにローカルに保存したり、ディスクスナップショットとして保存したりすることで、バックアップまたは復元する特定の名前空間またはクラスター全体を選択するための詳細な制御が提供されます。 AKS バックアップを使用して、運用回復、開発者/テスト環境の複製、クラスターのアップグレードシナリオなど、エンドツーエンドのシナリオを解放できます。

AKS バックアップは、Azure の Backup センターと統合され、大規模なバックアップを管理、監視、運用、分析するのに役立つ単一のビューを提供します。バックアップは、AKS インスタンスのサービスメニューの [設定] の下の Azure portal でも使用できます。

AKS バックアップのしくみ

AKS バックアップを使用して、AKS クラスターにデプロイされている AKS ワークロードと永続ボリュームをバックアップします。このソリューションでは、Backup 拡張機能を AKS クラスター内にインストールする必要があります。 Backup コンテナーは拡張機能と通信して、バックアップと復元に関連する操作を完了します。 Backup 拡張機能の使用は必須であり、クラスターのバックアップと復元を有効にするには、拡張機能を AKS クラスター内にインストールする必要があります。 AKS バックアップを構成するときは、ストレージアカウントとバックアップが保存されている BLOB コンテナーの値を追加します。

Backup 拡張機能と共に、AKS クラスターの管理対象リソースグループにユーザー ID ("拡張機能 ID" と呼ばれます) が作成されます。この拡張機能 ID には、バックアップが BLOB コンテナーに保存されているストレージアカウントに対するストレージアカウント共同作成者ロールが割り当てられます。

パブリック、プライベート、認可された IP ベースのクラスターをサポートするには、AKS バックアップでは、AKS クラスターと Backup コンテナーの間で信頼されたアクセスを有効にする必要があります。信頼されたアクセスにより、Backup コンテナーは、バックアップ操作用の特定のアクセス許可が割り当てられ、AKS クラスターにアクセスできるようになります。 AKS の信頼されたアクセスの詳細については、「信頼されたアクセスを使用して Azure リソースから AKS クラスターにアクセスできるようにする」を参照してください。

Note

AKS バックアップを使用すると、運用層とコンテナー層の両方にバックアップを格納できます。運用層はローカルデータストア (バックアップはスナップショットとしてテナント内に存在) です。これで、AKS バックアップを使用して 1 日に 1 つの復旧ポイントを移動し、コンテナー層に BLOB (テナント外) として保存できるようになりました。コンテナーに格納されているバックアップを使用して、セカンダリリージョン (Azure ペアリージョン) のデータを復元することもできます。

Backup 拡張機能がインストールされ、信頼されたアクセスが有効になると、バックアップポリシーに従ってクラスターのスケジュールされたバックアップを構成できます。また、バックアップを元のクラスターまたは同じサブスクリプションとリージョン内の代替クラスターに復元することもできます。特定の操作を設定するときに、特定の名前空間またはクラスター全体をバックアップと復元の構成として選択できます。

バックアップソリューションでは、クラスターにデプロイされている AKS データソースと、クラスターの永続ボリュームに保存されているデータに対するバックアップ操作を行い、その後 BLOB コンテナーにバックアップを保存できます。ディスクベースの永続ボリュームは、スナップショットリソースグループ内のディスクスナップショットとしてバックアップされます。 BLOB 内のスナップショットとクラスターの状態を組み合わせることで、運用層と呼ばれるテナントに保存される復旧ポイントを生成できます。また、運用層のバックアップ (日、週、月、または年ごとに最初に成功したバックアップ) を BLOB に変換し、1 日に 1 回コンテナー (テナント外) に移動することもできます。

Note

現在、Azure Backup は、CSI ドライバーベースの Azure Disk Storage 内の永続ボリュームのみをサポートします。バックアップ中、このソリューションは、Azure ファイル共有や BLOB などの他の永続ボリュームの種類をスキップします。また、コンテナー層の保持ルールを定義している場合、永続ボリュームのサイズが 1 TB 以下の場合にのみ、バックアップをコンテナーに移動できます。

バックアップの構成

AKS クラスターのバックアップを構成するには、まず Backup ボールトを作成します。このコンテナーは、さまざまなデータソースに構成されているバックアップの統合ビューを提供します。 AKS バックアップは、運用層とコンテナー層の両方のバックアップをサポートします。
Note
- Backup コンテナーと、バックアップまたは復元する AKS クラスターは、同じリージョンとサブスクリプションに存在する必要があります。
- Backup ボールトのストレージ冗長性設定 (LRS/GRS) は、コンテナー層に保存されているバックアップにのみ適用されます。ディザスターリカバリー用にバックアップを使用する場合は、リージョン間の復元を有効にしてストレージの冗長性を GRS に設定します。
AKS バックアップでは、スケジュールされたバックアップジョブが自動的にトリガーされます。ジョブはクラスターリソースを BLOB コンテナーにコピーし、バックアップ頻度に従ってディスクベースの永続ボリュームの増分スナップショットを作成します。バックアップはバックアップポリシーで定義されている保持期間に従って運用層とコンテナー層に保持され、保持期間が終了すると削除されます。

Note

AKS バックアップを使用すると、バックアップインスタンスごとに異なるバックアップ構成を使用して、1 つの AKS クラスターに対して複数のバックアップインスタンスを作成できます。ただし、AKS クラスターの各バックアップインスタンスは、それぞれ異なる Backup コンテナーに作成するか、あるいは同じ Backup コンテナー内の個別のバックアップポリシーを使用して作成する必要があります。

バックアップの管理

AKS クラスターのバックアップ構成が完了すると、Backup ボールトにバックアップインスタンスが作成されます。クラスターのバックアップインスタンスは、Azure portal の AKS インスタンスの [Backup] セクションで確認できます。ユーザーは、対応するバックアップインスタンスを使用して、復元の開始、監視、保護の停止など、インスタンスに対して任意のバックアップ関連の操作を実行できます。

また、AKS バックアップは Backup センターと直接統合され、すべての AKS クラスターとその他のバックアップでサポートされているワークロードの保護を一元的に管理するのに役立ちます。バックアップセンターは、ジョブの監視やバックアップと復元の状態など、すべてのバックアップのすべての要件に対応する 1 つのビューです。 Backup センターを使用すると、コンプライアンスとガバナンスを確保し、バックアップの使用状況を分析し、データをバックアップおよび復元する重要な操作を行います。

AKS バックアップは、マネージド ID を使用して他の Azure リソースにアクセスします。 AKS クラスターのバックアップを構成し、以前のバックアップから復元するには、Backup コンテナーのマネージド ID には、AKS クラスターとスナップショットを作成および管理するスナップショットリソースグループに対する一連のアクセス許可が必要です。現在、AKS クラスターには、スナップショットリソースグループに対する一連のアクセス許可が必要です。また、Backup 拡張機能ではユーザー ID を作成し、バックアップが BLOB に保存されているストレージアカウントにアクセスするための一連のアクセス許可を割り当てます。マネージド ID には、Azure ロールベースのアクセス制御 (Azure RBAC) を使用してアクセス許可を付与できます。マネージド ID は、Azure リソースでのみ使用できる、特殊な種類のサービスプリンシパルです。マネージド IDの詳細を確認してください。

バックアップから復元する

回復ポイントが存在する任意の時点からデータを復元できます。回復ポイントは、バックアップインスタンスが保護された状態のときに作成され、バックアップポリシーによって保持されるまでのデータを復元するために使用できます。

Azure Backup を使用すると、バックアップされたすべての項目を復元し、名前空間やその他のフィルターオプションを選択することで、きめ細かい制御を使用してバックアップから特定の項目を選択できます。また、元の AKS クラスター (バックアップされているクラスター) や代替 AKS クラスターで復元を実行することもできます。運用層とコンテナー層に保存されているバックアップは、同じサブスクリプションと異なるサブスクリプションにあるクラスターに復元できます。別のリージョン (Azure ペアリージョン) にあるクラスターへの復元には、コンテナー層に保存されているバックアップのみを使用できます。

コンテナー層に保存されているバックアップを復元するには、バックアップデータがハイドレートされるステージング場所を指定する必要があります。このステージング場所には、同じリージョン内のリソースグループとストレージアカウントに加え、復元のターゲットクラスターとしてのサブスクリプションが含まれます。復元中、ハイドレーションの一部として特定のリソース (BLOB コンテナー、ディスク、ディスクスナップショット) が作成され、復元操作の完了後にクリアされます。

現在、Azure Backup for AKS では、リソースの競合の発生時に復元操作を実行するときに、次の 2 つのオプションがサポートされています (バックアップされたリソースの名前はターゲット AKS クラスター内のリソースの名前と同じです)。復元構成を定義するときに、これらのオプションのいずれかを選択できます。

スキップ: 既定では、このオプションが選択されます。たとえば、pvc-azuredisk という名前の PVC をバックアップし、それを同じ名前の PVC を持つターゲットクラスター内に復元する場合、バックアップ拡張機能はバックアップされた永続ボリューム要求 (PVC) の復元をスキップします。このようなシナリオでは、バックアップアイテムのみをクラスター内で利用できるようにし、スキップが行われないようにするために、クラスターから該当リソースを削除してから復元操作を実行することをお勧めします。
パッチ: このオプションを使用すると、ターゲットクラスター内のリソース上のバックアップリソースの変更可能な変数にパッチを適用できます。ターゲットクラスター内のレプリカの数を更新したい場合は、操作としてパッチ適用を選択できます。

Note

AKS バックアップは現在、ターゲットクラスター内にリソースが既に存在する場合はリソースの削除と再作成を行いません。元の場所にある永続ボリュームを復元する場合は、既存の永続ボリュームを削除してから、復元操作を実行します。

バックアップと復元用のカスタムフックの使用

カスタムフックを使用して、コンテナー化されたワークロードとしてデプロイされたデータベースに使用されるボリュームのアプリケーション整合性スナップショットを取得できます。

カスタムフックとは

AKS バックアップを使用すると、バックアップと復元操作の一部としてカスタムフックを実行できます。フックは、バックアップ操作中または復元後にポッド内のコンテナーで実行される 1 つ以上のコマンドを実行するように構成されたコマンドです。これらのフックをカスタムリソースとして定義し、バックアップまたは復元したい AKS クラスターにデプロイします。必要な名前空間の AKS クラスターにカスタムリソースがデプロイされている場合は、バックアップと復元を構成するためのフローの入力として詳細を指定します。 Backup 拡張機能は、YAML ファイルで定義されているフックを実行します。

Note

フックは、"シェル" でコンテナーに対して実行されるのではありません。

AKS の Backup には、次の 2 種類のフックがあります。

Backup フック
復元フック

Backup フック

バックアップフックでは、コマンドをカスタムアクション処理の前に実行するように (事前フック)、またはすべてのカスタムアクションが完了し、カスタムアクションで指定した追加項目がバックアップされる前に実行するように (事後フック) 構成できます。

たとえば、バックアップフックを使用してデプロイするカスタムリソースの YAML テンプレートを次に示します。

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

復元フック

復元フックスクリプトでは、復元された AKS ポッドのコンテナーでカスタムコマンドまたはスクリプトを実行するように記述します。

復元フックを使用してデプロイするカスタムリソースの YAML テンプレートを次に示します。

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

AKS バックアップ中にフックを使用する方法については、こちらを参照してください。

Note

復元中、バックアップ拡張機能はコンテナーが起動するのを待機し、復元フックで定義されたとおりにコンテナー上で exec コマンドを実行します。
バックアップされたのと同じ名前空間への復元を実行している場合、復元フックは実行されません。これは復元フックが生成された新しいコンテナーしか検索しないからです。これは、スキップポリシーやパッチポリシーが選択されているかどうかに関係がありません。

AKS クラスターへのバックアップの復元中にリソースを変更する

"リソース変更" 機能を使用して、AKS クラスターにデプロイされた configmap として JSON パッチを指定すると、復元中にバックアップされた Kubernetes リソースを変更できます。

復元中にリソース修飾子の configmap を作成して適用する

リソースの変更を作成して適用するには、次の手順に従います。

リソース修飾子の configmap を作成します。

リソース修飾子を定義した YAML ファイルから、優先する名前空間に 1 つの configmap を作成する必要があります。

コマンドを作成する例:
```
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"
```
- 上記の configmap は、名前が mysql と match label foo: bar で始まる "名前空間" bar と foo 内のすべての永続ボリュームコピーに JSON パッチを適用します。 JSON パッチにより storageClassName が premium に置き換えられ、永続ボリュームコピーからラベル test が削除されます。
- ここで、"名前空間" はバックアップされたリソースの元の名前空間であり、リソースが復元される新しい名前空間ではありません。
- 特定のリソースに対して複数の JSON パッチを指定できます。修正プログラムは、configmap で指定された順序に従って適用されます。後続のパッチは順番に適用されます。同じパスに複数のパッチが指定されている場合、最後のパッチは前のパッチをオーバーライドします。
- configmap には複数の resourceModifierRules を指定できます。ルールは、configmap で指定された順序に従って適用されます。
復元の構成でのリソース修飾子参照の作成

復元操作を実行するときは、"ConfigMap 名" と、復元構成の一部としてデプロイされる "名前空間" を指定します。これらの詳細は、リソース修飾子ルールで指定する必要があります。

リソース修飾子でサポートされる操作

追加

追加操作を使用することで、リソース json に新しいブロックを追加できます。以下の例では、この操作によってデプロイに関する仕様に新しいコンテナーの詳細が追加されます。

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}]}"

削除

削除操作を使用することで、リソース json からキーを削除できます。以下の例では、この操作によって test をキーとして持つラベルが削除されます。

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

Replace

置換操作を使用することで、指定したパスの値を別の値に置き換えることができます。以下の例では、この操作によって永続ボリューム要求内の storageClassName が premium に置き換えられます。

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

コピー

コピー操作を使用することで、定義されたリソースからのあるパスから別のパスへと値をコピーできます。

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"

テスト

テスト操作を使用して、リソースに特定の値が存在するかどうかを確認できます。値が存在する場合は、パッチが適用されます。値が存在しない場合、パッチは適用されません。以下の例では、この操作によって永続ボリューム要求の StorageClassName が premium であるかどうかが確認され、もしそうであればそれが standard に置き換えられます。
```
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 パッチ

この configmap は、既定で名前空間内のすべてのデプロイに JSON パッチと "nginxwith the name that starts withnginxdep" を適用します。 JSON パッチは、このようなすべてのデプロイのレプリカ数を 12 に更新します。
```
version: v1
resourceModifierRules:
- conditions:
    groupResource: deployments.apps
    resourceNameRegex: "^nginxdep.*$"
    namespaces:
   - default
   - nginx
  patches:
  - operation: replace
    path: "/spec/replicas"
    value: "12"
```

JSON マージパッチ

この構成マップは、名前空間 default および nginx 内の名前が nginxdep で始まるすべてのデプロイメントに対して JSON マージパッチを適用します。 JSON マージパッチは、"app" というラベルを値 "nginx1" に追加または更新します。

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

戦略的マージパッチ

この構成マップは、名前空間 default 内の名前が nginx で始まるすべてのポッドに対して戦略的マージパッチを適用します。戦略的マージパッチにより、コンテナー nginx のイメージが 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"
            }
          ]
        }
      }

AKS バックアップはどのバックアップストレージ層をサポートしますか?

AKS 用 Azure Backup は、バックアップデータストアとして 2 つのストレージ層をサポートします。

運用層: AKS クラスターにインストールされているバックアップ拡張機能は、最初に CSI ドライバーを介してボリュームスナップショットを取得することでバックアップを取得し、ユーザーのテナントの BLOB コンテナーにクラスターの状態を保存します。この層は 4 時間に 2 回のバックアップを行い、保持期間を最小に抑えることで、より低い RPO を実現します。さらに、Azure ディスクベースのボリュームの場合、運用レベルはより迅速な復元を実現します。
コンテナー層: バックアップデータをスナップショットよりも低コストで長期間保存するために、AKS バックアップではコンテナー標準データストアがサポートされます。バックアップポリシーで設定された保持ルールに従って、最初に成功したバックアップ (日、週、月、または年ごと) がテナント外の BLOB コンテナーに移動されます。このデータストアはより長い保持期間を実現するだけでなく、ランサムウェアの防止にも役立ちます。また、Backup ボールト内で geo 冗長とリージョン間復元を有効にすると、コンテナーに保存されているバックアップを別のリージョン (Azure ペアリージョン) に移動することもできます。

Note

保持ルールを定義することで、Backup Policy を使用して、コンテナー標準データストアにバックアップデータを保存できます。スケジュールされた復旧ポイントは、1 日に 1 つだけコンテナー層に移動されます。ただし、選択したルールに従って、任意の数のオンデマンドバックアップをコンテナーに移動できます。

価格について

次の料金が発生します。

保護されたインスタンスの料金: Azure Backup for AKS では、名前空間ごとに 1 か月あたりの "保護されたインスタンスの料金" が請求されます。 AKS クラスターのバックアップを構成すると、保護されたインスタンスが作成されます。各インスタンスには、バックアップ構成で定義されているとおりにバックアップされる特定の数の名前空間があります。 AKS バックアップの価格の詳細については、「クラウドバックアップの価格」を参照し、ワークロードとして Azure Kubernetes Service を選択してください
スナップショットの料金: Azure Backup for AKS では、Azure サブスクリプションのリソースグループに保存されているスナップショットを取得することで、ディスクベースの永続ボリュームが保護されます。これらのスナップショットには、スナップショットストレージの料金が発生します。スナップショットはバックアップコンテナーにコピーされないため、バックアップストレージコストは適用されません。スナップショットの価格の詳細については、「Managed Disks の価格」を参照してください。
バックアップストレージ料金: AKS 用 Azure Backup では、コンテナー層でのバックアップの格納もサポートされています。これを実現するには、バックアップポリシーでコンテナー標準保持規則を定義し、1 日に 1 つの復元ポイントを Vault に移動できます。 Vault レベルに格納されている復元ポイントには、Backup Vault に格納されているデータの合計 (GB 単位) と冗長の種類の有効化に従って、バックアップストレージ料金と呼ばれる別の料金が課金されます。

次のステップ

Azure Kubernetes Service バックアップの前提条件

次の方法で共有

Azure Kubernetes Service とは

AKS バックアップのしくみ

バックアップの構成

バックアップの管理

バックアップから復元する

バックアップと復元用のカスタムフックの使用

カスタムフックとは

Backup フック

復元フック

AKS クラスターへのバックアップの復元中にリソースを変更する

復元中にリソース修飾子の configmap を作成して適用する

リソース修飾子でサポートされる操作

AKS バックアップはどのバックアップストレージ層をサポートしますか?

価格について

次のステップ

フィードバック

その他のリソース

次の方法で共有

Azure Kubernetes Service とは

AKS バックアップのしくみ

バックアップの構成

バックアップの管理

バックアップから復元する

バックアップと復元用のカスタム フックの使用

カスタム フックとは

Backup フック

復元フック

AKS クラスターへのバックアップの復元中にリソースを変更する

復元中にリソース修飾子の configmap を作成して適用する

リソース修飾子でサポートされる操作

AKS バックアップはどのバックアップ ストレージ層をサポートしますか?

価格について

次のステップ

フィードバック

その他のリソース

バックアップと復元用のカスタムフックの使用

カスタムフックとは

AKS バックアップはどのバックアップストレージ層をサポートしますか?