Dela via


Vad är Azure Kubernetes Service Backup?

Säkerhetskopiering av Azure Kubernetes Service (AKS) är en enkel, molnbaserad process som du kan använda för att säkerhetskopiera och återställa containerbaserade program och data som körs i ditt AKS-kluster. Du kan konfigurera schemalagda säkerhetskopieringar för klustertillstånd och programdata som lagras på Kubernetes Persistent Volumes in Container Storage Interface (CSI) drivrutinsbaserad Azure Disk Storage.

Lösningen ger dig detaljerad kontroll. Du kan säkerhetskopiera eller återställa ett specifikt namnområde eller ett helt kluster genom att lagra säkerhetskopior lokalt i en blobcontainer och som ögonblicksbilder av diskar. Du kan använda AKS-säkerhetskopiering för scenarier från slutpunkt till slutpunkt, inklusive driftåterställning, kloning av utvecklare eller testmiljöer och scenarier för klusteruppgradering.

AKS-säkerhetskopiering integreras med Backup Center i Azure för att ge en enda vy som kan hjälpa dig att styra, övervaka, använda och analysera säkerhetskopior i stor skala. Dina säkerhetskopior är också tillgängliga i Azure-portalen under Inställningar på tjänstmenyn för en AKS-instans.

Hur fungerar AKS-säkerhetskopiering?

Du kan använda AKS-säkerhetskopiering för att säkerhetskopiera dina AKS-arbetsbelastningar och beständiga volymer som distribueras i AKS-kluster. Lösningen kräver att säkerhetskopieringstillägget installeras i AKS-klustret. Backup-valvet kommunicerar med tillägget för att slutföra säkerhetskopierings- och återställningsåtgärder. Det är obligatoriskt att använda tillägget Säkerhetskopiering. Tillägget måste installeras i AKS-klustret för att aktivera säkerhetskopiering och återställning för klustret. När du konfigurerar AKS-säkerhetskopiering lägger du till värden för ett lagringskonto och en blobcontainer där säkerhetskopior lagras.

Tillsammans med tillägget Säkerhetskopiering skapas en användaridentitet (kallas en tilläggsidentitet) i AKS-klustrets hanterade resursgrupp. Tilläggsidentiteten tilldelas rollen Storage Account Contributor på det lagringskonto där säkerhetskopior lagras i en blobcontainer.

För att stödja offentliga, privata och auktoriserade IP-baserade kluster kräver AKS-säkerhetskopiering att du aktiverar funktionen Betrodd åtkomst mellan AKS-klustret och säkerhetskopieringsvalvet. Med betrodd åtkomst kan säkerhetskopieringsvalvet komma åt AKS-klustret eftersom specifika behörigheter har tilldelats till det för säkerhetskopieringsåtgärder. Mer information om betrodd AKS-åtkomst finns i Aktivera Azure-resurser för åtkomst till AKS-kluster med hjälp av betrodd åtkomst.

Med AKS-säkerhetskopiering kan du lagra säkerhetskopior på både driftnivå och valvnivå. Driftnivån är ett lokalt datalager (säkerhetskopior lagras i din klientorganisation som ögonblicksbilder). Nu kan du flytta en återställningspunkt per dag och lagra den i Blob i Vault-nivån (utanför din tenant) med hjälp av AKS-säkerhetskopiering. Säkerhetskopior som lagras på valvnivån kan också användas för att återställa data i en sekundär region (En Azure-länkad region).

När du har installerat tillägget Säkerhetskopiering och aktiverat betrodd åtkomst kan du konfigurera schemalagda säkerhetskopieringar för klustren enligt din säkerhetskopieringsprincip. Du kan också återställa säkerhetskopiorna till det ursprungliga klustret eller till ett annat kluster i samma prenumeration och region. När du konfigurerar den specifika åtgärden kan du välja ett specifikt namnområde eller ett helt kluster som en konfiguration för säkerhetskopiering och återställning.

AKS-säkerhetskopiering möjliggör säkerhetskopieringsåtgärder för dina AKS-datakällor som distribueras i klustret. Det möjliggör även säkerhetskopieringsåtgärder för data som lagras i den beständiga volymen för klustret. Sedan lagras säkerhetskopiorna i en blobcontainer. De diskbaserade beständiga volymerna säkerhetskopieras som diskögonblicksbilder i en resursgrupp för ögonblicksbilder. Ögonblicksbilderna och klustertillståndet i en blob kombineras för att bilda en återställningspunkt som benämns den operativa nivån och lagras i din hyresgäst. Du kan också konvertera säkerhetskopior (den första lyckade säkerhetskopieringen på en dag, vecka, månad eller år) på driftnivån till blobar och sedan flytta dem till ett valv (utanför klientorganisationen) en gång per dag.

Kommentar

För närvarande stöder Azure Backup endast beständiga volymer i CSI-drivrutinsbaserad Azure Disk Storage. Under säkerhetskopieringar hoppar lösningen över andra typer av beständiga volymer, till exempel Azure Files-resurs och blobar. Om du anger definierade kvarhållningsregler för valvnivån är säkerhetskopieringar endast berättigade att flyttas till valvet om beständiga volymer är mindre än eller lika med 1 TB.

Konfigurera säkerhetskopiering

Om du vill konfigurera säkerhetskopior för AKS-kluster skapar du först ett säkerhetskopieringsvalv. Valvet ger dig en samlad vy över de säkerhetskopior som har konfigurerats över olika datakällor. AKS-säkerhetskopiering stöder säkerhetskopieringar för både driftnivån och valvnivån.

Inställningen Lagringsredundans för Backup Vault (lokalt redundant lagring eller geo-redundant lagring) gäller endast för säkerhetskopior som lagras på valvnivån. Om du vill använda säkerhetskopior för haveriberedskap anger du lagringsredundansen som GRS med återställning mellan regioner aktiverad.

Kommentar

Säkerhetskopieringsvalvet och AKS-klustret som du vill säkerhetskopiera eller återställa måste finnas i samma region och prenumeration.

AKS-säkerhetskopiering utlöser automatiskt ett schemalagt säkerhetskopieringsjobb. Jobbet kopierar klusterresurserna till en blobcontainer och skapar en inkrementell ögonblicksbild av diskbaserade beständiga volymer enligt säkerhetskopieringsfrekvensen. Säkerhetskopiorna behålls på driftnivån och valvnivån enligt den kvarhållningstid som definieras i säkerhetskopieringsprincipen. Säkerhetskopiorna tas bort när varaktigheten är över.

Du kan använda AKS-säkerhetskopiering för att skapa flera säkerhetskopieringsinstanser för ett enda AKS-kluster med hjälp av olika säkerhetskopieringskonfigurationer per säkerhetskopieringsinstans. Vi rekommenderar dock att du skapar varje säkerhetskopieringsinstans av ett AKS-kluster på något av följande två sätt:

  • I ett annat Säkerhetskopieringsvalv
  • Genom att använda en separat säkerhetskopieringsprincip i samma säkerhetskopieringsvalv

Hantera säkerhetskopiering

När säkerhetskopieringskonfigurationen för ett AKS-kluster är klar skapas en säkerhetskopieringsinstans i säkerhetskopieringsvalvet. Du kan visa säkerhetskopieringsinstansen för klustret i avsnittet Säkerhetskopiering för en AKS-instans i Azure Portal. Du kan utföra alla säkerhetskopieringsrelaterade åtgärder för instansen, till exempel initiera återställningar, övervaka, stoppa skydd och så vidare via motsvarande säkerhetskopieringsinstans.

AKS-säkerhetskopiering integreras också direkt med Backup Center för att hjälpa dig att centralt hantera skydd för alla dina AKS-kluster och andra arbetsbelastningar som stöds av säkerhetskopiering. Säkerhetskopieringscenter innehåller en enda vy för alla dina krav på säkerhetskopiering, till exempel övervakningsjobb och tillståndet för säkerhetskopieringar och återställningar. Säkerhetskopieringscenter hjälper dig att säkerställa efterlevnad och styrning, analysera användningen av säkerhetskopiering och utföra kritiska åtgärder för att säkerhetskopiera och återställa data.

AKS-säkerhetskopiering använder hanterad identitet för att få åtkomst till andra Azure-resurser. För att konfigurera säkerhetskopieringen av ett AKS-kluster och återställa från en tidigare säkerhetskopia kräver säkerhetskopieringsvalvets hanterade identitet en uppsättning behörigheter för AKS-klustret. Det kräver också en uppsättning behörigheter för resursgruppen för ögonblicksbilder där ögonblicksbilder skapas och hanteras. För närvarande kräver AKS-klustret en uppsättning behörigheter för resursgruppen för ögonblicksbilder.

Dessutom skapar säkerhetskopieringstillägget en användaridentitet och tilldelar en uppsättning behörigheter för att komma åt lagringskontot där säkerhetskopior lagras i en blob. Du kan bevilja behörigheter till den hanterade identiteten med hjälp av rollbaserad åtkomstkontroll i Azure. En hanterad identitet är en särskild typ av tjänstprincip som endast kan användas med Azure-resurser. Läs mer om hanterade identiteter.

Återställ från en säkerhetskopia

Du kan återställa data från vilken tidpunkt som helst där en återställningspunkt finns. En återställningspunkt skapas när en säkerhetskopieringsinstans är i ett skyddat tillstånd. Den kan användas för att återställa data tills säkerhetskopieringsprincipen behåller data.

Med Azure Backup kan du återställa alla objekt som säkerhetskopieras eller använda detaljerade kontroller för att välja specifika objekt från säkerhetskopiorna med hjälp av namnområden och andra filteralternativ. Du kan också göra återställningen på det ursprungliga AKS-klustret (det säkerhetskopierade klustret) eller i ett alternativt AKS-kluster. Du kan återställa säkerhetskopior som lagras på driftnivån och valvnivån till ett kluster i samma eller en annan prenumeration. Endast säkerhetskopior som lagras på valvnivån kan användas för att återställa till ett kluster i en annan region (En Azure-länkad region).

Om du vill återställa en säkerhetskopia som lagras på valvnivån måste du ange en mellanlagringsplats där säkerhetskopierade data är hydratiserade. Den här mellanlagringsplatsen innehåller en resursgrupp och ett lagringskonto inom samma region och prenumeration som målklustret för återställning. Under återställningen skapas specifika resurser (blobcontainer, diskar och diskavbilder) som en del av hydratiseringsprocessen. De tas bort när återställningen har slutförts.

Azure Backup för AKS stöder för närvarande följande två alternativ för ett scenario där en resurskonflikt inträffar. En resurskonflikt uppstår när en säkerhetskopierad resurs har samma namn som resursen i AKS-målklustret. Du kan välja något av dessa alternativ när du definierar återställningskonfigurationen.

  • Hoppa över: Det här alternativet är markerat som standard. Om du till exempel säkerhetskopierar en Persistent Volume Claim (PVC) med namnet pvc-azuredisk och återställer den i ett målkluster som har en PVC med samma namn, så hoppar säkerhetskopieringstillägget över återställningen av den säkerhetskopierade PVC:en. I sådana scenarier rekommenderar vi att du tar bort resursen från klustret. Utför sedan återställningsåtgärden så att säkerhetskopierade objekt är tillgängliga i klustret och inte utelämnas.

  • Korrigering: Med det här alternativet kan du korrigera föränderlig variabel i den säkerhetskopierade resursen på resursen i målklustret. Om du vill uppdatera antalet repliker i målklustret kan du välja att använda patchning som en åtgärd.

Kommentar

AKS-säkerhetskopiering tar för närvarande inte bort och återskapar resurser i målklustret om de redan finns. Om du försöker återställa beständiga volymer på den ursprungliga platsen tar du bort befintliga beständiga volymer och utför sedan återställningsåtgärden.

Använda anpassade krokar för säkerhetskopiering och återställning

Du kan använda anpassade hookar för att ta programkonsekventa ögonblicksbilder av volymer som används för databaser som distribueras som containeriserade arbetslaster.

Vad är custom hooks?

Du kan använda AKS-säkerhetskopiering för att köra anpassade skript som en del av en säkerhetskopiering och återställning. Hooks har konfigurerats för att köra ett eller flera kommandon som ska köras i en podd under en container under en säkerhetskopieringsåtgärd eller efter återställningen.

Du definierar dessa hooks som en anpassad resurs och distribuerar dem i det AKS-kluster som du vill säkerhetskopiera eller återställa. När den anpassade resursen distribueras i AKS-klustret i det obligatoriska namnområdet anger du informationen som indata för flödet för att konfigurera säkerhetskopiering och återställning. Säkerhetskopieringstillägg kör hakarna som definierats i en YAML-fil.

Kommentar

Krokar körs inte i ett gränssnitt på containrarna.

Säkerhetskopiering i AKS har två typer av anknytningspunkter:

  • Krok för säkerhetskopiering
  • Återställa krokar

Krok för säkerhetskopiering

När du använder en säkerhetskopieringskrok kan du konfigurera kommandona för att köra kroken innan du bearbetar anpassade åtgärder (PreHooks). Du kan även köra skriptet efter att alla anpassade åtgärder har slutförts och eventuella ytterligare objekt som specificerats av anpassade åtgärder har säkerhetskopierats (PostHooks).

Här är till exempel YAML-mallen för en anpassad resurs som ska distribueras med hjälp av säkerhetskopieringskrokar:

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

Återställa krokar

I återställningsskriptet skrivs anpassade kommandon eller skript som ska köras i containrarna på en återställd AKS-podd.

Här är YAML-mallen för en anpassad resurs som distribueras via återställningskrokar:

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

Lär dig hur du använder hookar vid säkerhetskopiering i AKS.

Under återställningen väntar backup-tillägget på att containern ska starta och utför sedan exec-kommandon på containrarna, som definieras i återställningsskripten.

Om du utför en återställning till samma namespace som säkerhetskopierades körs inte hooken för återställning. Den letar bara efter en nyskapad container. Det här resultatet inträffar oavsett om du använder principen hoppa över eller korrigera.

Ändra resurs vid återställning av säkerhetskopior till AKS-kluster

Du kan använda funktionen Resursmodifiering för att ändra säkerhetskopierade Kubernetes-resurser under återställningen genom att specificera JSON-korrigeringar, som tillämpas i AKS-klustret.

Skapa och tillämpa en konfigurationsmapp för resursmodifierare under återställningen

Följ dessa steg för att skapa och tillämpa resursändring:

  1. Skapa en resursmodifierare configmap.

    Du måste skapa en configmap i önskat namnområde från en YAML-fil som definierade resursmodifierare.

    Exempel för att skapa ett kommando:

    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 Föregående tillämpar JSON-korrigeringen på alla beständiga volymkopior i namespaces fältet och foo med ett namn som börjar med mysql och match label foo: bar. JSON-korrigeringen ersätter storageClassName med premium och tar bort etiketten test från kopiorna av Persistent Volume.
    • namespace Här är det ursprungliga namnområdet för den säkerhetskopierade resursen och inte det nya namnområdet som resursen ska återställas till.
    • Du kan ange flera JSON-korrigeringar för en viss resurs. Patcharna tillämpas enligt den ordning som anges i configmap. Nästa korrigering tillämpas i ordning. Om flera korrigeringar anges för samma sökväg åsidosätter den senaste korrigeringen de tidigare korrigeringarna.
    • Du kan ange flera resourceModifierRules i configmap. Reglerna tillämpas enligt den ordning som anges i configmap.
  2. Skapa en referens för resursmodifierare i återställningskonfigurationen

    När du utför en återställningsåtgärd anger du ConfigMap name och namespace där den distribueras som en del av återställningskonfigurationen. Den här informationen måste anges under Regler för resursmodifierare.

    Skärmbild som visar platsen där du kan ange resursinformation.

Åtgärder som stöds av resursmodifierare

  • Lägg till

    Du kan använda åtgärden Lägg till för att lägga till ett nytt block i resursens JSON. I följande exempel lägger åtgärden till ny containerinformation i specifikationen med en deployering.

    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}]}"
    
  • Ta bort

    Du kan använda åtgärden Ta bort för att ta bort en nyckel från resursens JSON. I följande exempel tar åtgärden bort etiketten med test som nyckel.

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

    Du kan använda åtgärden Ersätt för att ersätta ett värde för sökvägen som anges till en annan. I följande exempel ersätter operationen storageClassName i PVC med premium.

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

    Du kan använda åtgärden Kopiera för att kopiera ett värde från en sökväg från de resurser som definierats till en annan sökväg.

    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"
    
  • Testa

    Du kan använda teståtgärden för att kontrollera om ett visst värde finns i resursen. Om värdet finns tillämpas korrigeringen. Om värdet inte finns tillämpas inte korrigeringen. I följande exempel kontrollerar åtgärden om PVC har premium som StorageClassName och ersätter det med standard, om det är sant.

    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-korrigering

    Detta configmap tillämpar JSON-korrigeringen på alla distributioner i namnrymderna som standard och nginx med namnet som börjar med nginxdep. JSON-korrigeringen uppdaterar antalet repliker till 12 för alla sådana distributioner.

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

    Detta configmap tillämpar JSON-sammanslagningskorrigeringen på alla distributioner i namnrymderna default och nginx med namn som börjar med nginxdep. JSON-sammanslagningskorrigeringen lägger till eller uppdaterar etiketten app med värdet nginx1.

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

    Detta configmap tillämpar den strategiska sammanslagningskorrigeringen på alla pods i namnområdet 'default' med namn som börjar med nginx. Den strategiska sammanslagningskorrigeringen uppdaterar bilden av containern nginx till 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"
                }
              ]
            }
          }
    

Vilken lagringsnivå för säkerhetskopiering stöder AKS-säkerhetskopiering?

Azure Backup för AKS stöder två lagringsnivåer som säkerhetskopieringsdatalager:

  • Driftnivå: Säkerhetskopieringstillägget som är installerat i AKS-klustret tar först säkerhetskopian genom att ta ögonblicksbilder av volymer via CSI-drivrutinen. Den sparar sedan klustertillståndet i en blobcontainer i din egen klient. Den här nivån stöder ett mål för lägre återställningspunkt (RPO) med en varaktighet på minst fyra timmar mellan två säkerhetskopior. För Diskbaserade Volymer i Azure har driftnivån dessutom stöd för snabbare återställningar.

  • Valvnivå: Om du vill lagra säkerhetskopierade data under en längre tid till en lägre kostnad än ögonblicksbilder stöder AKS-säkerhetskopiering valvstandarddatalager. Enligt kvarhållningsreglerna som anges i säkerhetskopieringspolicyn flyttas den första lyckade säkerhetskopieringen (för en dag, vecka, månad eller år) till en blobcontainer utanför hyrorganisationen. Det här dataarkivet tillåter inte bara längre kvarhållning, utan ger även skydd mot utpressningstrojaner. Du kan också flytta säkerhetskopior som lagras i valvet till en annan region (Azure-länkad region) för återställning genom att aktivera geo-redundans och återställning mellan regioner i säkerhetskopieringsvalvet.

    Kommentar

    Du kan lagra säkerhetskopierade data i ett standard-datalager via säkerhetskopieringspolicy genom att specificera kvarhållningsregler. Endast en schemalagd återställningspunkt per dag flyttas till valvnivån. Du kan dock flytta valfritt antal säkerhetskopieringar på begäran till valvet enligt den valda regeln.

Förstå prissättningen

Du debiteras för:

  • Avgift för skyddad instans: Azure Backup för AKS debiterar en avgift för skyddad instans per namnområde per månad. När du konfigurerar säkerhetskopiering för ett AKS-kluster skapas en skyddad instans. Varje instans har ett visst antal namnområden som säkerhetskopieras enligt definitionen i säkerhetskopieringskonfigurationen. Mer information om prissättningen för AKS-säkerhetskopiering finns i Prissättning för Azure-säkerhetskopiering och välj Azure Kubernetes Service som arbetsbelastning.

  • Avgift för ögonblicksbilder: Azure Backup för AKS skyddar en diskbaserad beständig volym genom att ta ögonblicksbilder som lagras i resursgruppen i din Azure-prenumeration. Dessa ögonblicksbilder medför lagringsavgifter. Eftersom ögonblicksbilderna inte kopieras till säkerhetskopieringsvalvet gäller inte kostnaderna för lagring av säkerhetskopior. Mer information om priser för ögonblicksbilder finns i Prissättning för hanterade diskar.

  • Lagringsavgift för säkerhetskopiering: Azure Backup för AKS stöder också lagring av säkerhetskopior på valvnivån. Du kan lagra säkerhetskopior på valvnivån genom att definiera kvarhållningsregler för valvstandarden i säkerhetskopieringsprincipen, med en återställningspunkt per dag som kan flyttas till valvet. Återställningspunkter som lagras på valvlager debiteras en separat avgift, kallad säkerhetskopieringslagringsavgift, baserat på den totala mängden data som lagras (i gigabyte) och redundanstypen som är aktiverad i säkerhetskopieringsvalvet.