Wat is Azure Kubernetes Service backup?

AKS-back-up (Azure Kubernetes Service) is een eenvoudig, cloudeigen proces dat u kunt gebruiken om een back-up te maken van toepassingen en gegevens die in containers worden uitgevoerd in uw AKS-cluster en deze te herstellen. U kunt geplande back-ups configureren voor clusterstatus- en toepassingsgegevens die zijn opgeslagen op permanente volumes in Azure Disk Storage op basis van CSI-stuurprogramma's. De oplossing biedt u gedetailleerde controle om een specifieke naamruimte of een volledig cluster te kiezen om back-ups te maken of te herstellen door back-ups lokaal op te slaan in een blobcontainer en als momentopnamen van schijven. U kunt AKS-back-ups gebruiken voor end-to-end-scenario's, waaronder operationeel herstel, kloonomgevingen voor ontwikkelaars/testomgevingen en scenario's voor clusterupgrades.

AKS-backups kunnen worden geïntegreerd met Het Back-upcentrum in Azure, met één weergave waarmee u back-ups op schaal kunt beheren, bewaken, gebruiken en analyseren. Uw back-ups zijn ook beschikbaar in Azure Portal onder Instellingen in het servicemenu voor een AKS-exemplaar.

Hoe werkt AKS-back-up?

Gebruik een AKS-back-up om een back-up te maken van uw AKS-workloads en permanente volumes die zijn geïmplementeerd in AKS-clusters. Voor de oplossing moet de back-upextensie worden geïnstalleerd in het AKS-cluster. De Backup-kluis communiceert met de extensie om bewerkingen te voltooien die betrekking hebben op back-up en herstel. Het gebruik van de back-upextensie is verplicht en de extensie moet worden geïnstalleerd in het AKS-cluster om back-up en herstel voor het cluster in te schakelen. Wanneer u een AKS-back-up configureert, voegt u waarden toe voor een opslagaccount en een blobcontainer waarin back-ups worden opgeslagen.

Naast de back-upextensie wordt een gebruikersidentiteit (een extensie-id genoemd) gemaakt in de beheerde resourcegroep van het AKS-cluster. De extensie-id wordt toegewezen aan de rol Inzender voor opslagaccounts in het opslagaccount waarin back-ups worden opgeslagen in een blobcontainer.

Voor ondersteuning van openbare, privé- en geautoriseerde IP-clusters moet voor AKS-back-up vertrouwde toegang worden ingeschakeld tussen het AKS-cluster en de Backup-kluis. Met Vertrouwde toegang kan de Backup-kluis toegang krijgen tot het AKS-cluster vanwege specifieke machtigingen die eraan zijn toegewezen voor back-upbewerkingen. Zie Azure-resources inschakelen voor toegang tot AKS-clusters met vertrouwde toegang voor meer informatie over vertrouwde toegang tot AKS.

Notitie

Met AKS-back-ups kunt u back-ups opslaan in zowel de operationele laag als de kluislaag. De operationele laag is een lokaal gegevensarchief (back-ups worden opgeslagen in uw tenant als momentopnamen). U kunt nu één herstelpunt per dag verplaatsen en opslaan in kluislaag als blobs (buiten uw tenant) met behulp van AKS-back-up. Back-ups die zijn opgeslagen in de kluis, kunnen ook worden gebruikt om gegevens in een secundaire regio (gekoppelde Azure-regio) te herstellen.

Nadat de back-upextensie is geïnstalleerd en Vertrouwde toegang is ingeschakeld, kunt u geplande back-ups configureren voor de clusters volgens uw back-upbeleid. U kunt de back-ups ook herstellen naar het oorspronkelijke cluster of naar een alternatief cluster dat zich in hetzelfde abonnement en dezelfde regio bevindt. U kunt een specifieke naamruimte of een volledig cluster kiezen als back-up- en herstelconfiguratie tijdens het instellen van de specifieke bewerking.

De back-upoplossing maakt de back-upbewerkingen mogelijk voor uw AKS-gegevensbronnen die zijn geïmplementeerd in het cluster en voor de gegevens die zijn opgeslagen in het permanente volume voor het cluster en sla de back-ups vervolgens op in een blobcontainer. Er wordt een back-up gemaakt van de permanente volumes op basis van de schijf als momentopnamen in een resourcegroep voor momentopnamen. De momentopnamen en de clusterstatus in een blob combineren beide om een herstelpunt te vormen dat is opgeslagen in uw tenant met de naam Operationele laag. U kunt ook back-ups (eerste geslaagde back-up in een dag, week, maand of jaar) in de operationele laag converteren naar blobs en deze vervolgens één keer per dag verplaatsen naar een kluis (buiten uw tenant).

Notitie

Momenteel ondersteunt Azure Backup alleen permanente volumes in Azure Disk Storage op basis van CSI-stuurprogramma's. Tijdens back-ups slaat de oplossing andere permanente volumetypen, zoals Azure-bestandsshare en blobs, over. Als u bewaarregels voor de kluislaag hebt gedefinieerd, komen back-ups alleen in aanmerking voor verplaatsing naar de kluis als de permanente volumes kleiner zijn dan of gelijk zijn aan 1 TB.

Back-up configureren

• Als u back-ups voor AKS-clusters wilt configureren, maakt u eerst een Backup-kluis. De kluis biedt u een geconsolideerde weergave van de back-ups die zijn geconfigureerd in verschillende gegevensbronnen. Back-ups van AKS ondersteunen back-ups van zowel operationele lagen als kluislagen.

  Notitie

  • De Backup-kluis en het AKS-cluster waarvoor u een back-up wilt maken of herstellen, moeten zich in dezelfde regio en hetzelfde abonnement bevinden.
  • De instelling voor opslagredundantie van de Back-upkluis (LRS/GRS) is alleen van toepassing op back-ups die zijn opgeslagen in de kluislaag. Als u back-ups wilt gebruiken voor herstel na noodgevallen, stelt u de opslagredundantie in als GRS waarvoor Herstel tussen regio's is ingeschakeld.

• Met een AKS-back-up wordt automatisch een geplande back-uptaak geactiveerd. De taak kopieert de clusterbronnen naar een blobcontainer en maakt een incrementele momentopname van de permanente volumes op basis van de schijf volgens de back-upfrequentie. De back-ups worden bewaard in de operationele laag en kluislaag volgens de retentieduur die is gedefinieerd in het back-upbeleid en worden verwijderd zodra de duur is verstreken.

  Notitie

  U kunt AKS-back-ups gebruiken om meerdere back-upexemplaren voor één AKS-cluster te maken met behulp van verschillende back-upconfiguraties per back-upexemplaren. Elk back-upexemplaren van een AKS-cluster moeten echter worden gemaakt in een andere Backup-kluis of met behulp van een afzonderlijk back-upbeleid in dezelfde Backup-kluis.

Back-ups beheren

Wanneer de back-upconfiguratie voor een AKS-cluster is voltooid, wordt er een back-upexemplaren gemaakt in de Backup-kluis. U kunt het back-upexemplaren voor het cluster weergeven in de sectie Back-up voor een AKS-exemplaar in Azure Portal. U kunt alle back-upbewerkingen uitvoeren voor het exemplaar, zoals het initiëren van herstelbewerkingen, bewaking, het stoppen van beveiliging, enzovoort, via het bijbehorende back-upexemplaren.

AKS-back-up kan ook rechtstreeks worden geïntegreerd met Backup Center, zodat u de beveiliging voor al uw AKS-clusters en andere door back-ups ondersteunde workloads centraal kunt beheren. Back-upcentrum is één weergave voor al uw back-upvereisten, zoals bewakingstaken en de status van back-ups en herstelbewerkingen. Back-upcentrum helpt u naleving en governance te garanderen, back-upgebruik te analyseren en kritieke bewerkingen uit te voeren om een back-up te maken van gegevens en deze te herstellen.

AKS-back-up maakt gebruik van beheerde identiteit voor toegang tot andere Azure-resources. Als u een back-up van een AKS-cluster wilt configureren en wilt herstellen vanaf een eerdere back-up, vereist de beheerde identiteit van de Backup-kluis een set machtigingen voor het AKS-cluster en de resourcegroep voor momentopnamen waarin momentopnamen worden gemaakt en beheerd. Op dit moment is voor het AKS-cluster een set machtigingen vereist voor de resourcegroep voor momentopnamen. De back-upextensie maakt ook een gebruikersidentiteit en wijst een set machtigingen toe voor toegang tot het opslagaccount waarin back-ups worden opgeslagen in een blob. U kunt machtigingen verlenen aan de beheerde identiteit met behulp van op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC). Een beheerde identiteit is een speciaal type service-principe dat alleen kan worden gebruikt met Azure-resources. Meer informatie over beheerde identiteiten.

Herstellen vanaf back-up

U kunt gegevens herstellen vanaf elk tijdstip waarvoor een herstelpunt bestaat. Er wordt een herstelpunt gemaakt wanneer een back-upinstantie een beveiligde status heeft en kan worden gebruikt om gegevens te herstellen totdat deze worden bewaard door het back-upbeleid.

Azure Backup biedt u de mogelijkheid om alle items waarvan een back-up is gemaakt te herstellen of om gedetailleerde besturingselementen te gebruiken om specifieke items in de back-ups te selecteren door naamruimten en andere filteropties te kiezen. U kunt ook de herstelbewerking uitvoeren op het oorspronkelijke AKS-cluster (het cluster waarvan een back-up is gemaakt) of op een alternatief AKS-cluster. U kunt back-ups herstellen die zijn opgeslagen in de operationele laag en de kluislaag naar een cluster in hetzelfde en verschillende abonnement. Alleen back-ups die zijn opgeslagen in de kluislaag kunnen worden gebruikt om een herstelbewerking uit te voeren naar een cluster in een andere regio (gekoppelde Azure-regio).

Als u back-ups wilt herstellen die zijn opgeslagen in de kluislaag, moet u een faseringslocatie opgeven waar de back-upgegevens worden gehydrateerd. Deze faseringslocatie bevat een resourcegroep en een opslagaccount in dezelfde regio en een abonnement als het doelcluster voor herstel. Tijdens het herstellen worden specifieke resources (blobcontainer, schijf- en schijfmomentopnamen) gemaakt als onderdeel van hydratatie, die vervolgens wordt gewist nadat de herstelbewerking is voltooid.

Azure Backup voor AKS ondersteunt momenteel de volgende twee opties bij het uitvoeren van een herstelbewerking wanneer er sprake is van een conflict tussen resources (een back-upresource heeft dezelfde naam als de resource in het doel-AKS-cluster). U kunt een van deze opties kiezen bij het definiëren van de herstelconfiguratie.

1. Overslaan: deze optie is standaard geselecteerd. Als u bijvoorbeeld een back-up hebt gemaakt van een PVC met de naam pvc-azuredisk en u deze herstelt in een doelcluster met dezelfde naam, slaat de back-upextensie het herstellen van de back-up permanente volumeclaim (PVC) over. In dergelijke scenario's raden we u aan om de resource uit het cluster te verwijderen en vervolgens de herstelbewerking uit te voeren, zodat de back-upitems alleen beschikbaar zijn in het cluster en niet worden overgeslagen.

2. Patch: Met deze optie kan de veranderlijke patchvariabele in de back-upresource van de resource in het doelcluster worden gepatcht. Als u het aantal replica's in het doelcluster wilt bijwerken, kunt u ervoor kiezen om te patchen als een bewerking.

Notitie

AKS-back-up verwijdert momenteel geen resources in het doelcluster en maakt deze opnieuw als deze al bestaan. Als u permanente volumes op de oorspronkelijke locatie probeert te herstellen, verwijdert u de bestaande permanente volumes en voert u de herstelbewerking uit.

Aangepaste hooks gebruiken voor back-up en herstel

U kunt aangepaste hooks gebruiken om toepassingsconsistente momentopnamen te maken van volumes die worden gebruikt voor databases die zijn geïmplementeerd als workloads in containers.

Wat zijn aangepaste hooks?

U kunt AKS-back-ups gebruiken om aangepaste hooks uit te voeren als onderdeel van een back-up- en herstelbewerking. Hooks zijn opdrachten die zijn geconfigureerd om een of meer opdrachten uit te voeren die moeten worden uitgevoerd in een pod onder een container tijdens een back-upbewerking of na het herstellen. U definieert deze hooks als een aangepaste resource en implementeert deze in het AKS-cluster waarvoor u een back-up wilt maken of herstellen. Wanneer de aangepaste resource wordt geïmplementeerd in het AKS-cluster in de vereiste naamruimte, geeft u de details op als invoer voor de stroom voor het configureren van back-up en herstel. Met de back-upextensie worden de hooks uitgevoerd zoals gedefinieerd in een YAML-bestand.

Notitie

Hooks worden niet uitgevoerd in een shell op de containers.

Back-up in AKS heeft twee soorten hooks:

• Back-uphook
• Hooks herstellen

Back-uphook

In een back-uphook kunt u de opdrachten configureren om de hook uit te voeren voordat een aangepaste actie wordt verwerkt (voorhaken) of nadat alle aangepaste acties zijn voltooid en eventuele extra items die zijn opgegeven door aangepaste acties, worden een back-up gemaakt (post-hooks).

Hier volgt bijvoorbeeld de YAML-sjabloon voor een aangepaste resource die moet worden geïmplementeerd met behulp van back-uphook:

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 herstellen

In het herstelhookscript worden aangepaste opdrachten of scripts geschreven die moeten worden uitgevoerd in de containers van een herstelde AKS-pod.

Hier volgt de YAML-sjabloon voor een aangepaste resource die moet worden geïmplementeerd met behulp van herstelhook:

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

Meer informatie over het gebruik van hooks tijdens het maken van AKS-back-ups.

Notitie

• Tijdens het herstellen wacht de back-upextensie totdat de container wordt weergegeven en vervolgens exec-opdrachten worden uitgevoerd, gedefinieerd in de herstelhook.
• Als u herstel uitvoert naar dezelfde naamruimte waarvan een back-up is gemaakt, worden de herstelhaken niet uitgevoerd omdat er alleen wordt gezocht naar nieuwe container die wordt geactiveerd. Dit is ongeacht of het beleid voor overslaan of patchen is gekozen.

Resource wijzigen tijdens het herstellen van back-ups naar AKS-cluster

U kunt de functie Resourcewijziging gebruiken om tijdens het herstellen back-up van Kubernetes-resources te wijzigen door JSON-patches op te geven zoals configmap geïmplementeerd in het AKS-cluster.

Een resourceaanpassingsconfiguratiemap maken en toepassen tijdens het herstellen

Voer de volgende stappen uit om resourcewijziging te maken en toe te passen:

1. Resourcemodifiers configmap maken.

   U moet één configuratiemap maken in uw voorkeursnaamruimte vanuit een YAML-bestand dat resourceaanpassingen heeft gedefinieerd.

   Voorbeeld voor het maken van een opdracht:

   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"
   

   • De bovenstaande configmap past de JSON-patch toe op alle permanente volumekopieën in de naamruimtenbalk en foo met de naam die begint met mysql en match label foo: bar. De JSON-patch vervangt het storageClassName label door premium en verwijdert het label test uit de permanente volumekopieën.
   • Hier is de naamruimte de oorspronkelijke naamruimte van de back-upresource en niet de nieuwe naamruimte waar de resource wordt hersteld.
   • U kunt meerdere JSON-patches voor een bepaalde resource opgeven. De patches worden toegepast volgens de volgorde die is opgegeven in de configuratiemap. Er wordt een volgende patch op volgorde toegepast. Als er meerdere patches zijn opgegeven voor hetzelfde pad, overschrijft de laatste patch de vorige patches.
   • U kunt meerdere resourceModifierRules opgeven in de configuratiemap. De regels worden toegepast volgens de volgorde die is opgegeven in de configmap.

2. Een verwijzing voor resourceaanpassing maken in de herstelconfiguratie

   Wanneer u een herstelbewerking uitvoert, geeft u de naam van de ConfigMap en de naamruimte op waar deze wordt geïmplementeerd als onderdeel van de herstelconfiguratie. Deze details moeten worden opgegeven onder Resource Modifier-regels.

   

Bewerkingen die worden ondersteund door Resource Modifier

• Toevoegen

  U kunt de bewerking Toevoegen gebruiken om een nieuw blok toe te voegen aan de resource-json. In het onderstaande voorbeeld voegt de bewerking een nieuwe containerdetails toe aan de specificatie met een implementatie.

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

• Verwijderen

  U kunt de bewerking Verwijderen gebruiken om een sleutel uit de resource-json te verwijderen. In het onderstaande voorbeeld verwijdert de bewerking het label met test als sleutel.

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

• Replace

  U kunt de bewerking Vervangen gebruiken om een waarde te vervangen voor het pad dat wordt vermeld in een alternatieve. In het onderstaande voorbeeld vervangt de bewerking storageClassName in de permanente volumeclaim door Premium.

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

• kopie

  U kunt de kopieerbewerking gebruiken om een waarde te kopiëren van het ene pad van de resources die zijn gedefinieerd naar een ander pad.

  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"
  

•   Testen

  U kunt de testbewerking gebruiken om te controleren of een bepaalde waarde aanwezig is in de resource. Als de waarde aanwezig is, wordt de patch toegepast. Als de waarde niet aanwezig is, wordt de patch niet toegepast. In het onderstaande voorbeeld controleert de bewerking of de permanente volumeclaims Premium als StorageClassName hebben en worden vervangen door standaard, indien waar.

  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

  Met deze configuratiemap wordt de JSON-patch standaard toegepast op alle implementaties in de naamruimten en 'nginxwith the name that starts withnginxdep'. De JSON-patch werkt het aantal replica's bij naar 12 voor al deze implementaties.

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

• JSON-samenvoegpatch

  Met deze configuratietoewijzing wordt de JSON-samenvoegpatch toegepast op alle implementaties in de standaardnaamruimten en nginx met de naam die begint met nginxdep. Met de JSON Merge Patch wordt het label 'app' toegevoegd/bijgewerkt met de waarde 'nginx1'.

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

• Patch voor strategische samenvoeging

  Met deze configuratietoewijzing wordt de Patch voor strategische samenvoeging toegepast op alle pods in de standaardnaamruimte met de naam die begint met nginx. De Patch voor strategische samenvoeging werkt de installatiekopieën van container nginx bij naar 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"
              }
            ]
          }
        }
  

Welke back-upopslaglaag ondersteunt AKS-back-up?

Azure Backup voor AKS ondersteunt twee opslaglagen als back-upgegevensarchieven:

• Operationele laag: de back-upextensie die is geïnstalleerd in het AKS-cluster maakt eerst de back-up door volumemomentopnamen te maken via het CSI-stuurprogramma en de clusterstatus op te slaan in een blobcontainer in uw eigen tenant. Deze laag ondersteunt een lagere RPO met de minimale duur tussen twee back-ups van vier uur. Daarnaast ondersteunt operationele laag voor volumes op basis van Azure Disk snellere herstelbewerkingen.

• Kluislaag: Als u back-upgegevens voor langere tijd wilt opslaan tegen lagere kosten dan momentopnamen, ondersteunt AKS-back-up kluisstandaardgegevensopslag. Volgens de bewaarregels die zijn ingesteld in het back-upbeleid, wordt de eerste geslaagde back-up (van een dag, week, maand of jaar) verplaatst naar een blobcontainer buiten uw tenant. Dit gegevensarchief staat niet alleen langere retentie toe, maar biedt ook ransomwarebeveiliging. U kunt ook back-ups die in de kluis zijn opgeslagen, verplaatsen naar een andere regio (gekoppelde Azure-regio) voor herstel door georedundantie en herstel tussen regio's in de Back-upkluis in te schakelen.

Notitie

U kunt de back-upgegevens opslaan in een kluisstandaard gegevensopslag via back-upbeleid door bewaarregels te definiëren. Er wordt slechts één gepland herstelpunt per dag verplaatst naar de kluislaag. U kunt echter een willekeurig aantal back-ups op aanvraag naar de kluis verplaatsen volgens de geselecteerde regel.

Inzicht in prijscategorieën

Er worden kosten in rekening gebracht voor:

• Kosten voor beveiligde exemplaren: Voor Azure Backup voor AKS worden kosten in rekening gebracht voor een beveiligd exemplaar per naamruimte per maand. Wanneer u een back-up voor een AKS-cluster configureert, wordt er een beveiligd exemplaar gemaakt. Elk exemplaar heeft een specifiek aantal naamruimten waarvan een back-up wordt gemaakt zoals gedefinieerd in de back-upconfiguratie. Zie Prijzen voor Cloud Backup en selecteer Azure Kubernetes Service als workload voor meer informatie over de AKS-back-upprijzen

• Kosten voor momentopnamen: Azure Backup voor AKS beveiligt een permanent volume op basis van schijven door momentopnamen te maken die zijn opgeslagen in de resourcegroep in uw Azure-abonnement. Voor deze momentopnamen worden opslagkosten voor momentopnamen in rekening gebracht. Omdat de momentopnamen niet naar de Backup-kluis worden gekopieerd, zijn de kosten voor back-upopslag niet van toepassing. Zie Prijzen voor Managed Disk voor meer informatie over de prijzen voor momentopnamen.

• Kosten voor back-upopslag: Azure Backup voor AKS biedt ook ondersteuning voor het opslaan van back-ups in de kluislaag. Dit kan worden bereikt door bewaarregels te definiëren voor kluisstandaard in het back-upbeleid, waarbij één herstelpunt per dag in aanmerking komt om naar de kluis te worden verplaatst. Herstelpunten die zijn opgeslagen in de kluislaag, worden een afzonderlijke vergoeding in rekening gebracht, back-upopslagkosten genoemd volgens het totale aantal gegevens dat is opgeslagen (in GB's) en het redundantietype dat is ingeschakeld voor de Backup Vault.

Volgende stap

Vereisten voor back-up van Azure Kubernetes Service