Partager via

Qu’est-ce que la sauvegarde Azure Kubernetes Service ?

La sauvegarde Azure Kubernetes Service (AKS) est un processus natif cloud simple que vous pouvez utiliser pour sauvegarder et restaurer des applications et des données conteneurisées qui s’exécutent dans votre cluster AKS. Vous pouvez configurer des sauvegardes planifiées pour l’état du cluster et les données d’application stockées sur des volumes persistants Kubernetes dans le stockage de disque Azure basé sur le pilote CSI (Container Storage Interface).

La solution vous donne un contrôle granulaire. Vous pouvez sauvegarder ou restaurer un espace de noms spécifique ou un cluster entier en stockant les sauvegardes localement dans un conteneur d’objets blob et en tant que captures instantanées de disque. Vous pouvez utiliser la sauvegarde AKS pour les scénarios de bout en bout, notamment la récupération opérationnelle, le clonage des environnements de développement ou de test et les scénarios de mise à niveau de cluster.

La sauvegarde AKS s’intègre au centre de sauvegarde dans Azure pour fournir une vue unique qui peut vous aider à régir, surveiller, exploiter et analyser les sauvegardes à grande échelle. Vos sauvegardes sont également disponibles dans le portail Azure sous Paramètres dans le menu de service d’une instance AKS.

Comment fonctionne la sauvegarde AKS ?

Vous pouvez utiliser la sauvegarde AKS pour sauvegarder vos charges de travail AKS et les volumes persistants déployés dans des clusters AKS. La solution nécessite l’installation d’une Extension de sauvegarde au sein du cluster AKS. Le coffre de sauvegarde communique avec l’extension pour effectuer les opérations de sauvegarde et de restauration. L’utilisation de l’extension De sauvegarde est obligatoire. L’extension doit être installée à l’intérieur du cluster AKS pour activer la sauvegarde et la restauration du cluster. Lorsque vous configurez la sauvegarde AKS, vous ajoutez des valeurs pour un compte de stockage et un conteneur blob dans lesquels les sauvegardes sont stockées.

Avec l’extension de sauvegarde, une identité utilisateur (appelée identité d’extension) est créée dans le groupe de ressources managé du cluster AKS. L’identité d’extension est affectée au rôle de Contributeur de compte de stockage sur le compte de stockage où les sauvegardes sont stockées dans un conteneur blob.

Pour prendre en charge les clusters publics, privés et autorisés basés sur IP, la sauvegarde AKS nécessite l’activation de la fonctionnalité d’accès approuvé entre le cluster AKS et le coffre de sauvegarde. L’accès approuvé permet au coffre de sauvegarde d’accéder au cluster AKS, car des autorisations spécifiques lui sont attribuées pour les opérations de sauvegarde. Pour obtenir plus d’informations sur l’accès approuvé AKS, consultez Activer des ressources Azure pour accéder aux clusters AKS en utilisant l’accès approuvé.

La sauvegarde AKS vous permet de stocker des sauvegardes au niveau opérationnel et au niveau du coffre. Le niveau opérationnel est un magasin de données local (les sauvegardes sont stockées dans votre instance sous forme d’instantanés). Vous pouvez maintenant déplacer un point de récupération par jour, et le stocker dans le niveau Coffre sous forme d’objet blob (en dehors de votre locataire) en utilisant la sauvegarde AKS. Les sauvegardes stockées dans le niveau Coffre peuvent également être utilisées pour restaurer des données dans une région secondaire (région jumelée Azure).

Après avoir installé l’extension de sauvegarde et activé l’accès approuvé, vous pouvez configurer des sauvegardes planifiées pour les clusters en fonction de votre stratégie de sauvegarde. Vous pouvez également restaurer les sauvegardes sur le cluster d’origine ou sur un autre cluster dans le même abonnement et la même région. Lorsque vous configurez l’opération spécifique, vous pouvez choisir un espace de noms spécifique ou un cluster entier comme configuration de sauvegarde et de restauration.

La sauvegarde AKS permet d’effectuer des opérations de sauvegarde pour vos sources de données AKS déployées dans le cluster. Il active également les opérations de sauvegarde pour les données stockées dans le volume persistant du cluster. Il stocke ensuite les sauvegardes dans un conteneur blob. Les volumes persistants basés sur disque sont sauvegardés en tant que captures instantanées de disque dans un groupe de ressources d’instantanés. Les instantanés et l’état du cluster dans un blob se combinent pour former un point de récupération appelé « niveau Opérationnel » stocké dans votre locataire. Vous pouvez également convertir des sauvegardes (la première sauvegarde réussie d’un jour, d’une semaine, d’un mois ou d’une année) du niveau Opérationnel en blobs, puis les déplacer vers un coffre (en dehors de votre locataire) une fois par jour.

Remarque

Actuellement, Azure Backup prend uniquement en charge les volumes persistants dans le pilote CSI de stockage disque Azure. Pendant les sauvegardes, la solution ignore d’autres types de volumes persistants, tels que le partage Azure Files et les objets blob. En outre, si vous définissez des règles de rétention définies pour le niveau coffre, les sauvegardes ne peuvent être déplacées vers le coffre que si les volumes persistants sont inférieurs ou égaux à 1 To.

Configurer une sauvegarde

Pour configurer les sauvegardes de clusters AKS, créez d’abord un coffre de sauvegarde. Le coffre vous donne une vue consolidée des sauvegardes configurées dans différentes sources de données. La sauvegarde AKS prend en charge les sauvegardes pour le niveau Opérationnel et pour le niveau Coffre.

Le paramètre de redondance du coffre de sauvegarde (stockage localement redondant ou stockage géoredondant) s’applique uniquement aux sauvegardes stockées dans le niveau coffre. Si vous souhaitez utiliser des sauvegardes pour la récupération d’urgence, définissez la redondance de stockage en tant que GRS avec restauration interrégion activée.

Remarque

Le coffre de sauvegarde et le cluster AKS que vous souhaitez sauvegarder ou restaurer doivent se trouver dans la même région et le même abonnement.

Une sauvegarde AKS déclenche automatiquement un travail de sauvegarde planifiée. Le travail copie les ressources du cluster dans un conteneur d’objets blob et crée un instantané incrémentiel des volumes persistants basés sur le disque en fonction de la fréquence de sauvegarde. Les sauvegardes sont conservées dans le niveau opérationnel et le niveau coffre en fonction de la durée de rétention définie dans la stratégie de sauvegarde. Les sauvegardes sont supprimées lorsque la durée est terminée.

Vous pouvez utiliser une sauvegarde AKS afin de créer plusieurs instances de sauvegarde pour un seul cluster AKS en utilisant différentes configurations de sauvegarde par instance de sauvegarde. Toutefois, nous vous recommandons de créer chaque instance de sauvegarde d’un cluster AKS de l’une des deux manières suivantes :

  • Dans un autre coffre de sauvegarde
  • En utilisant une stratégie de sauvegarde distincte dans le même coffre de sauvegarde

Gérer la sauvegarde

Une fois la configuration de sauvegarde terminée d’un cluster AKS, une instance de sauvegarde est créée dans le coffre de sauvegarde. Vous pouvez afficher l’instance de sauvegarde du cluster dans la section Sauvegarde d’une instance AKS dans le Portail Azure. Vous pouvez effectuer toutes les opérations liées à la sauvegarde pour l’instance (par exemple lancer des restaurations, effectuer un monitoring, arrêter la protection, etc.) via son instance de sauvegarde correspondante.

La sauvegarde AKS s’intègre également directement au Centre de sauvegarde pour vous aider à gérer de manière centralisée la protection de tous vos clusters AKS et d’autres charges de travail prises en charge par la sauvegarde. Le centre de sauvegarde fournit une vue unique pour toutes vos exigences de sauvegarde, telles que la surveillance des travaux et l’état des sauvegardes et des restaurations. Le centre de sauvegarde vous permet de veiller à la conformité et à la gouvernance, d’analyser l’utilisation de sauvegardes et d’effectuer des opérations essentielles pour sauvegarder et restaurer des données.

Une sauvegarde AKS utilise l’identité managée pour accéder à d’autres ressources Azure. Pour configurer la sauvegarde d’un cluster AKS et pour effectuer une restauration à partir d’une sauvegarde antérieure, l’identité managée du coffre de sauvegarde nécessite un ensemble d’autorisations sur le cluster AKS. Il nécessite également un ensemble d’autorisations sur le groupe de ressources d’instantanés où les instantanés sont créés et gérés. Le cluster AKS nécessite actuellement un ensemble d’autorisations sur le groupe de ressources de captures instantanées.

En outre, l’extension de sauvegarde crée une identité utilisateur et affecte un ensemble d’autorisations pour accéder au compte de stockage où les sauvegardes sont stockées dans un blob. Vous pouvez accorder des autorisations à l’identité managée à l’aide du contrôle d’accès en fonction du rôle Azure. Une identité gérée est un type spécial de principe de service pouvant uniquement être utilisé avec des ressources Azure. En savoir plus sur les identités managées.

Restaurer à partir d’une sauvegarde

Il est possible de restaurer des données à partir de tous les points dans le temps pour lesquels un point de récupération existe. Un point de récupération est créé lorsqu’une instance de sauvegarde est dans un état protégé. Il peut être utilisé pour restaurer des données jusqu’à ce que la stratégie de sauvegarde conserve les données.

Sauvegarde Azure vous offre la possibilité de restaurer tous les éléments sauvegardés ou d’utiliser des contrôles granulaires pour sélectionner des éléments spécifiques dans les sauvegardes à l’aide d’espaces de noms et d’autres options de filtre. En outre, vous pouvez effectuer la restauration sur le cluster AKS d’origine (le cluster sauvegardé) ou sur un autre cluster AKS. Vous pouvez restaurer des sauvegardes stockées dans le niveau opérationnel et le niveau Coffre sur un cluster dans le même abonnement ou un autre abonnement. Seules les sauvegardes stockées dans le niveau Coffre peuvent être utilisées pour effectuer une restauration sur un cluster dans une autre région (région jumelée Azure).

Pour restaurer une sauvegarde stockée au niveau Coffre, vous devez fournir un emplacement intermédiaire où les données de sauvegarde sont hydratées. Cet emplacement intermédiaire inclut un groupe de ressources et un compte de stockage dans la même région et le même abonnement que le cluster cible pour la restauration. Pendant la restauration, des ressources spécifiques (conteneur d’objets blob, disques et instantanés de disque) sont créées dans le cadre de l’hydratation. Elles sont effacées une fois l’opération de restauration terminée.

Sauvegarde Azure pour AKS prend actuellement en charge les deux options suivantes pour un scénario dans lequel un conflit de ressources se produit. Un conflit de ressources se produit lorsqu’une ressource sauvegardée porte le même nom que la ressource dans le cluster AKS cible. Vous pouvez choisir l’une de ces options lorsque vous définissez la configuration de la restauration.

  • Ignorer : cette option est sélectionnée par défaut. Par exemple, si vous sauvegardez une revendication de volume persistant (PVC) nommée pvc-azuredisk et que vous la restaurez dans un cluster cible portant le même nom, l’extension de sauvegarde ignore la restauration du PVC sauvegardé. Dans de tels scénarios, nous vous recommandons de supprimer la ressource du cluster. Ensuite, effectuez l’opération de restauration afin que les éléments sauvegardés soient disponibles seulement dans le cluster et ne soient pas ignorés.

  • Patch : cette option permet d'appliquer un correctif sur la variable mutable dans la ressource sauvegardée du cluster cible. Si vous souhaitez mettre à jour le nombre de réplicas dans le cluster cible, vous pouvez opter pour la mise à jour corrective en tant qu’opération.

Remarque

La sauvegarde AKS ne supprime pas et ne recrée pas actuellement les ressources dans le cluster cible si elles existent déjà. Si vous essayez de restaurer des volumes persistants dans l’emplacement d’origine, supprimez les volumes persistants existants, puis effectuez l’opération de restauration.

Utiliser des hooks personnalisés pour la sauvegarde et la restauration

Vous pouvez utiliser des hooks personnalisés pour effectuer des captures instantanées cohérentes avec les applications des volumes utilisés pour des bases de données déployées en tant que charges de travail conteneurisées.

Que sont les hooks personnalisés ?

Vous pouvez utiliser une sauvegarde AKS pour exécuter des hooks personnalisés dans le cadre d’une opération de sauvegarde et de restauration. Les hooks sont configurés pour permettre l'exécution de une ou plusieurs commandes dans un pod, sous le conteneur, pendant une opération de sauvegarde ou après une opération de restauration.

Vous définissez ces hooks en tant que ressource personnalisées et vous les déployez dans le cluster AKS que vous souhaitez sauvegarder ou restaurer. Quand la ressource personnalisée est déployée dans le cluster AKS de l’espace de noms requis, vous fournissez les informations comme entrées pour le flux afin de configurer une sauvegarde et une restauration. L’extension Sauvegarde exécute les hooks définis dans un fichier YAML.

Remarque

Les hooks ne sont pas exécutés dans un interpréteur de commandes sur les conteneurs.

Une sauvegarde dans AKS dispose de deux types de hook :

  • Hooks de sauvegarde
  • Hooks de restauration

Hooks de sauvegarde

Lorsque vous utilisez un hook de sauvegarde, vous pouvez configurer les commandes pour exécuter le hook avant tout traitement d’action personnalisé (PreHooks). Vous pouvez également exécuter le hook une fois toutes les actions personnalisées terminées et tous les éléments supplémentaires spécifiés par les actions personnalisées sont sauvegardés (PostHooks).

Par exemple, voici le modèle YAML pour une ressource personnalisée à déployer en utilisant des hooks de sauvegarde :

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

Hooks de restauration

Dans le script de point d'ancrage de restauration, des commandes ou scripts personnalisés sont écrits pour être exécutés dans les conteneurs d’un pod AKS restauré.

Voici le modèle YAML pour une ressource personnalisée déployée via des hooks de restauration :

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

Découvrez comment utiliser des hooks pendant une sauvegarde AKS.

Pendant la restauration, l’extension de sauvegarde attend que le conteneur s’affiche, puis exécute les commandes exec sur celles-ci, définies dans les hooks de restauration.

Si vous effectuez une restauration sur le même espace de noms sauvegardé, le hook de restauration n’est pas exécuté. Il recherche seulement un conteneur nouvellement généré. Ce résultat se produit, que vous utilisiez la stratégie skip ou patch.

Modifier la ressource lors de la restauration des sauvegardes sur un cluster AKS

Vous pouvez utiliser la fonctionnalité De modification des ressources pour modifier les ressources Kubernetes sauvegardées pendant la restauration en spécifiant des correctifs JSON tels qu’ils configmap sont déployés dans le cluster AKS.

Créer et appliquer un configmap de modificateur de ressource pendant la restauration

Pour créer et appliquer la modification des ressources, procédez comme suit :

  1. Créez un modificateur configmapde ressource.

    Vous devez en créer un configmap dans votre espace de noms préféré à partir d’un fichier YAML qui a défini des modificateurs de ressources.

    Exemple de création d’une commande :

    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"
    • Le configmap précédent applique le correctif JSON à toutes les copies de volume persistant dans la barre namespaces et foo avec un nom qui commence par mysql et match label foo: bar. Le correctif JSON remplace storageClassName par premium et supprime l’étiquette test des copies de Volume Persistant.
    • namespace est l'espace de noms d'origine de la ressource sauvegardée, et non le nouvel espace de noms auquel la ressource va être restaurée.
    • Vous pouvez spécifier plusieurs patchs JSON pour une ressource particulière. Les correctifs sont appliqués en fonction de l’ordre spécifié dans le configmap. Le correctif suivant est appliqué dans l’ordre. Si plusieurs patchs sont spécifiés pour le même chemin d’accès, le dernier patch remplace les patchs précédents.
    • Vous pouvez spécifier plusieurs resourceModifierRules dans le configmap. Les règles sont appliquées en fonction de l’ordre spécifié dans le configmap.

  2. Créer une référence de modificateur de ressource dans la configuration de restauration

    Lorsque vous effectuez une opération de restauration, fournissez l’emplacement ConfigMap name et l’emplacement namespace où il se déploie dans le cadre de la configuration de restauration. Ces détails doivent être fournis sous les Règles de modificateur de ressources.

    Capture d’écran montrant l’emplacement pour fournir les détails de la ressource.

Opérations prises en charge par le modificateur de ressource

  • Ajouter

    Vous pouvez utiliser l’opération Add pour ajouter un nouveau bloc à la ressource JSON. Dans l'exemple suivant, l'opération ajoute de nouveaux détails de conteneur à la spécification dans le cadre d'un déploiement.

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

  • Supprimer

    Vous pouvez utiliser l’opération Supprimer pour supprimer une clé de la ressource JSON. Dans l’exemple suivant, l’opération supprime l’étiquette avec test la clé.

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

  • Remplacer

    Vous pouvez utiliser l’opération Remplacer pour remplacer une valeur pour le chemin mentionné par une autre. Dans l’exemple suivant, l’opération remplace le storageClassName dans le PVC par premium.

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

  • Copier

    Vous pouvez utiliser l’opération Copier pour copier une valeur d’un chemin d’accès des ressources définies vers un autre chemin.

    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"

  • Test

    Vous pouvez utiliser l’opération Test pour vérifier si une valeur particulière est présente dans la ressource. Si la valeur est présente, le patch est appliqué. Si la valeur n’est pas présente, le patch n’est pas appliqué. Dans l’exemple suivant, l’opération vérifie si les PVC ont la valeur premium pour StorageClassName et la remplace par standard si c’est vrai.

    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

    Ce configmap applique le correctif JSON à tous les déploiements dans les espaces de noms par défaut et nginx dont le nom commence par nginxdep. Le correctif JSON met à jour le nombre de réplicas à 12 pour tous ces déploiements.

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

  • Correctif de fusion JSON

    Ce configmap applique le correctif JSON à tous les déploiements dans les espaces de noms par défaut et nginx dont le nom commence par nginxdep. Le correctif de fusion JSON ajoute ou met à jour l’étiquette app avec la valeur nginx1.

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

  • Correctif de fusion stratégique

    Ce configmap applique le correctif de fusion stratégique à tous les pods de l’espace de noms par défaut dont le nom commence par nginx. Le correctif de fusion stratégique met à jour l’image du conteneur nginx sur 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"
            }
          ]
        }
      }

Quel niveau de stockage de sauvegarde la sauvegarde AKS prend-elle en charge ?

Le service Sauvegarde Azure pour AKS prend en charge deux niveaux de stockage en tant que solutions de stockage de sauvegarde.

  • Niveau opérationnel : l’extension de sauvegarde installée dans le cluster AKS prend d’abord la sauvegarde en prenant des captures instantanées de volume via le pilote CSI. Il stocke ensuite l’état du cluster dans un conteneur d’objets blob dans votre propre locataire. Ce niveau prend en charge un objectif de point de récupération (RPO) inférieur avec la durée minimale de quatre heures entre deux sauvegardes. En outre, pour les volumes basés sur disque Azure, le niveau opérationnel prend en charge les restaurations plus rapides.

  • Niveau Coffre : pour stocker les données de sauvegarde plus longtemps à un coût inférieur à celui des instantanés, la sauvegarde AKS prend en charge les magasin de données standard au niveau du coffre. Selon les règles de rétention définies dans la stratégie de sauvegarde, la première sauvegarde réussie (d’un jour, d’une semaine, d’un mois ou d’une année) est déplacée vers un conteneur BLOB en dehors de votre entité. Ce magasin de données permet non seulement une rétention plus longue, mais il offre également une protection contre les rançongiciels. Vous pouvez également déplacer des sauvegardes stockées dans le coffre vers une autre région (région jumelée Azure) pour la récupération en activant la géoredondance et la restauration inter-régions dans le coffre de sauvegarde.

    Remarque

    Vous pouvez stocker des données de sauvegarde dans un magasin de données standard au niveau du coffre via une stratégie de sauvegarde en définissant des règles de rétention. Un seul point de récupération planifié par jour est déplacé vers le niveau Coffre. Cependant, vous pouvez déplacer autant de sauvegardes à la demande que vous le souhaitez vers le coffre en fonction de la règle sélectionnée.

Comprendre les tarifs

Vous encourez des frais pour :

  • Frais d’instance protégée : Sauvegarde Azure pour AKS facture des frais d’instance protégée par espace de noms et par mois. Lorsque vous configurez une sauvegarde pour un cluster AKS, une instance protégée est créée. Chaque instance a un nombre spécifique d’espaces de noms qui sont sauvegardés tel que défini dans la configuration de sauvegarde. Pour plus d’informations sur la tarification de la sauvegarde AKS, consultez Tarification de la sauvegarde Azure et sélectionnez Azure Kubernetes Service comme charge de travail.

  • Frais pour les instantanés : Sauvegarde Azure pour AKS protège un volume persistant sur disque en prenant des instantanés stockées dans le groupe de ressources de votre abonnement Azure. Ces captures instantanées entraînent des frais de stockage de capture instantanée. Étant donné que les instantanés ne sont pas copiés dans le coffre de sauvegarde, les coûts de stockage de sauvegarde ne s’appliquent pas. Pour plus d’informations sur la tarification des instantanés, consultez Tarification des disques managés.

  • Frais pour le stockage des sauvegardes : Sauvegarde Azure pour AKS prend également en charge le stockage des sauvegardes dans le niveau Coffre. Vous pouvez stocker des sauvegardes au niveau Coffre en définissant des règles de rétention pour le standard de coffre dans la stratégie de sauvegarde, avec un point de restauration par jour éligible pour être déplacé dans le coffre. Les points de restauration stockés dans le niveau coffre sont facturés des frais distincts (appelés frais de stockage de sauvegarde) en fonction du type total de données stockées (en gigaoctets) et du type de redondance activés sur le coffre de sauvegarde.

Contenu connexe