Skip to main content
NetApp Backup and Recovery
O português é fornecido por meio de tradução automática para sua conveniência. O inglês precede o português em caso de inconsistências.

Faça backup de aplicativos Kubernetes agora usando recursos personalizados em Backup and Recovery

Colaboradores netapp-mwallis
PDFs

NetApp Backup and Recovery permite que você faça backup manual de aplicativos Kubernetes usando recursos personalizados (CRs).

Faça backup de um aplicativo Kubernetes agora usando recursos personalizados

Crie manualmente um backup de um aplicativo Kubernetes para estabelecer uma linha de base para futuros backups e snapshots ou para garantir que os dados mais recentes estejam protegidos.

Observação Os recursos com escopo de cluster são incluídos em um backup, Snapshot ou clone se forem explicitamente referenciados na definição do aplicativo ou se tiverem referências a qualquer um dos namespaces do aplicativo.
Antes de começar

Certifique-se de que o tempo de expiração do token de sessão da AWS seja suficiente para quaisquer operações de backup do s3 de longa duração. Se o token expirar durante a operação de backup, a operação pode falhar.

Crie um snapshot local usando um recurso personalizado

Para criar um Snapshot da sua aplicação Kubernetes e armazená-lo localmente, utilize o recurso personalizado Snapshot com atributos específicos.

Passos

  1. Crie o arquivo de recurso personalizado (CR) e nomeie-o local-snapshot-cr.yaml.

  2. No arquivo que você criou, configure os seguintes atributos:

    • metadata.name: (Obrigatório) O nome deste recurso personalizado; escolha um nome único e adequado ao seu ambiente.

    • spec.applicationRef: o nome do aplicativo no Kubernetes para o qual será criado o Snapshot.

    • spec.appVaultRef: (Obrigatório) O nome do AppVault onde o conteúdo do Snapshot (metadados) deve ser armazenado.

    • spec.reclaimPolicy: (Opcional) Define o que acontece com o AppArchive de um snapshot quando o CR do snapshot é excluído. Isso significa que mesmo quando definido como Retain, o snapshot será excluído. Opções válidas:

      • Retain (padrão)

      • Delete

        apiVersion: protect.trident.netapp.io/v1
kind: Snapshot
metadata:
  namespace: my-app-namespace
  name: local-snapshot-cr
spec:
  applicationRef: my-application
  appVaultRef: appvault-name
  reclaimPolicy: Retain

  3. Após preencher o local-snapshot-cr.yaml file com os valores corretos, aplique a CR:

    kubectl apply -f local-snapshot-cr.yaml

Faça backup de um aplicativo em um armazenamento de objetos usando um recurso personalizado

Crie um CR de backup com atributos específicos para fazer backup do seu aplicativo em um object store.

Passos

  1. Crie o arquivo de recurso personalizado (CR) e nomeie-o object-store-backup-cr.yaml.

  2. No arquivo que você criou, configure os seguintes atributos:

    • metadata.name: (Obrigatório) O nome deste recurso personalizado; escolha um nome único e adequado ao seu ambiente.

    • spec.applicationRef: (Obrigatório) O nome do aplicativo Kubernetes a ser feito backup.

    • spec.appVaultRef: (Obrigatório, mutuamente exclusivo com spec.appVaultTargetsRef) Se você usar o mesmo bucket para armazenar o snapshot e o backup, este é o nome do AppVault onde o conteúdo do backup deve ser armazenado.

    • spec.appVaultTargetsRef: (Obrigatório, mutuamente exclusivo com spec.appVaultRef) Se você usar buckets diferentes para armazenar o snapshot e o backup, este é o nome do AppVault onde o conteúdo do backup deve ser armazenado.

    • spec.dataMover: (Opcional, obrigatório para clusters migrados do Trident Protect) Uma string indicando qual ferramenta de backup usar para a operação de backup. Se este cluster foi migrado para Backup and Recovery do Trident Protect, o valor diferencia maiúsculas de minúsculas e deve ser CBS.

    • spec.reclaimPolicy: (Opcional) Define o que acontece com o conteúdo do backup (metadados/dados do volume) quando o CR de backup é excluído. Valores possíveis:

      • Delete

      • Retain (padrão)

    • spec.cleanupSnapshot: (Obrigatório) Garante que o snapshot temporário criado pelo CR de backup não seja excluído após a conclusão da operação de backup. Valor recomendado: false.

      Exemplo de YAML ao usar o mesmo bucket para armazenar o snapshot e o backup:

      apiVersion: protect.trident.netapp.io/v1
kind: Backup
metadata:
  namespace: my-app-namespace
  name: my-cr-name
spec:
  applicationRef: my-application
  appVaultRef: appvault-name
  dataMover: CBS
  reclaimPolicy: Retain
  cleanupSnapshot: false

      Exemplo de YAML ao usar buckets diferentes para armazenar o snapshot e o backup:

    apiVersion: protect.trident.netapp.io/v1
kind: Backup
metadata:
  namespace: my-app-namespace
  name: object-store-backup-cr
spec:
  applicationRef: my-application
  appVaultTargetsRef: appvault-targets-name
  dataMover: CBS
  reclaimPolicy: Retain
  cleanupSnapshot: false

  3. Após preencher o arquivo object-store-backup-cr.yaml com os valores corretos, aplique a CR:

    kubectl apply -f object-store-backup-cr.yaml

Crie um backup 3-2-1 fanout usando um recurso personalizado

O backup usando uma arquitetura de distribuição 3-2-1 copia um backup para storage secundário, bem como para um armazenamento de objetos. Para criar um backup 3-2-1 de distribuição, crie um Backup CR com atributos específicos.

Passos

  1. Crie o arquivo de recurso personalizado (CR) e nomeie-o 3-2-1-fanout-backup-cr.yaml.

  2. No arquivo que você criou, configure os seguintes atributos:

    • metadata.name: (Obrigatório) O nome deste recurso personalizado; escolha um nome único e adequado ao seu ambiente.

    • spec.applicationRef: (Obrigatório) O nome do aplicativo Kubernetes a ser feito backup.

    • spec.appVaultTargetsRef: (Obrigatório) O nome do AppVault onde o conteúdo do backup deve ser armazenado.

    • spec.dataMover: (Opcional) Uma string indicando qual ferramenta de backup usar para a operação de backup. O valor diferencia maiúsculas de minúsculas e deve ser CBS.

    • spec.reclaimPolicy: (Opcional) Define o que acontece com o conteúdo do backup (metadados/dados do volume) quando o CR de backup é excluído. Valores possíveis:

      • Delete

      • Retain (padrão)

    • spec.cleanupSnapshot: (Obrigatório) Garante que o snapshot temporário criado pelo CR de backup não seja excluído após a conclusão da operação de backup. Valor recomendado: false.

    • spec.replicateSnapshot: (Obrigatório) Instrui o NetApp Backup and Recovery a replicar o Snapshot para storage secundário. Valor obrigatório: true.

    • spec.replicateSnapshotReclaimPolicy: (Opcional) Define o que acontece com o snapshot replicado quando ele é excluído. Valores possíveis:

      • Delete

      • Retain (padrão)

        Exemplo YAML:

    apiVersion: protect.trident.netapp.io/v1
kind: Backup
metadata:
  namespace: my-app-namespace
  name: 3-2-1-fanout-backup-cr
spec:
  applicationRef: my-application
  appVaultTargetsRef: appvault-targets-name
  dataMover: CBS
  reclaimPolicy: Retain
  cleanupSnapshot: false
  replicateSnapshot: true
  replicateSnapshotReclaimPolicy: Retain

  3. Após preencher o 3-2-1-fanout-backup-cr.yaml file com os valores corretos, aplique a CR:

    kubectl apply -f 3-2-1-fanout-backup-cr.yaml

Anotações de backup suportadas

A tabela a seguir descreve as anotações que você pode usar ao criar um backup CR.

Anotação Tipo Descrição Valor padrão

protect.trident.netapp.io/backup-completo

string

Especifica se um backup deve ser não incremental. Defina como true para criar um backup não incremental. A melhor prática é realizar um backup completo periodicamente e, em seguida, realizar backups incrementais entre os backups completos para minimizar o risco associado às restaurações.

"false"

protect.trident.netapp.io/snapshot-completion-timeout

string

O tempo máximo permitido para a conclusão geral da operação de Snapshot.

"60m"

protect.trident.netapp.io/volume-snapshots-ready-to-use-timeout

string

Tempo máximo permitido para que os snapshots de volume atinjam o estado pronto para uso.

"30m"

protect.trident.netapp.io/volume-snapshots-created-timeout

string

O tempo máximo permitido para que snapshots de volume sejam criados.

"5m"

protect.trident.netapp.io/pvc-bind-timeout-sec

string

Tempo máximo (em segundos) de espera para que quaisquer PersistentVolumeClaims (PVCs) recém-criadas atinjam a Bound fase antes que a operação falhe.

"1200" (20 minutos)