Backup e restauração no Kubernetes

Selecione uma versão da documentação: 16.3.0

• Atual (16.8.0)
• 16.8.0
• 16.3.0
• 15.12.0
• 15.7.1
• 15.7.0
• 15.5.5
• 15.5.4
• 15.5.2

Nesta página, mostramos como fazer backup e restaurar seus dados do AlloyDB Omni usando o operador do AlloyDB Omni no Kubernetes. Para isso, é necessário ter conhecimentos básicos sobre como atualizar um cluster do Kubernetes usando arquivos de manifesto e a ferramenta de linha de comando kubectl. Para mais informações sobre como instalar e executar o AlloyDB Omni em um cluster do Kubernetes, consulte Instalar o AlloyDB Omni no Kubernetes.

Para ativar o backup e a recuperação contínuos do AlloyDB Omni, crie um plano de backup para cada cluster de banco de dados. Os backups são feitos com base nas programações de backup definidas no recurso backupPlan. Se nenhuma programação de backup for definida no plano, os backups contínuos serão feitos diariamente por padrão. É possível restaurar ou clonar backups de qualquer carimbo de data/hora na janela de recuperação com uma granularidade de segundos.

Para informações sobre como fazer backup e restaurar dados do AlloyDB Omni em implantações que não são do Kubernetes, consulte Configurar o Barman para o AlloyDB Omni e Configurar o pgBackRest para o AlloyDB Omni.

Ativar e programar backups

Os backups contínuos são ativados quando você cria um recurso de plano de backup para o cluster de banco de dados. Você precisa criar um recurso backupPlan para cada cluster de banco de dados e ativar o backup contínuo para o cluster. Esse recurso de plano de backup define os seguintes parâmetros:

• O local em que o operador do AlloyDB Omni armazena os backups. Pode ser local no cluster do Kubernetes ou em um bucket do Cloud Storage.

• Uma opção para definir várias programações de backup que criam automaticamente backups full, incremental e differential. É possível pausar essa programação a qualquer momento, incluindo na definição do plano de backup. Se um plano de backup for pausado, os backups programados não serão criados, mas ainda será possível usá-lo para criar backups manualmente.

  Se nenhuma programação de backup for especificada, o padrão será "0 0 * * *", que faz um backup completo diário à meia-noite, no horário local.

• Um período de armazenamento para backups armazenados. Esse período pode ser de um dia a 90 dias. O valor padrão é 14.

Importante: os CronJobs do Kubernetes permitem automatizar a criação de programações de backup e interpretar os CronJobs com base no fuso horário local do componente kube-controller-manager. Se o kube-controller-manager for executado em um fuso horário diferente do UTC, os backups poderão não ser executados como esperado. Para garantir que as programações de backup sejam interpretadas de forma consistente em UTC, recomendamos adicionar o campo timeZone: "Etc/UTC" à especificação BackupPlan.

Seu cluster de banco de dados pode ter vários planos de backup, cada um com nome e configuração próprios. Se você criar vários recursos backupPlan com programações de backup diferentes para um cluster de banco de dados, defina um local de backup exclusivo para cada recurso de backup.

Criar um plano para armazenar backups localmente

Para ativar os backups armazenados localmente, aplique o seguinte manifesto:

    apiVersion: alloydbomni.dbadmin.goog/v1
    kind: BackupPlan
    metadata:
      name: BACKUP_PLAN_NAME
      namespace: NAMESPACE
    spec:
      dbclusterRef: DB_CLUSTER_NAME
      backupSchedules:
        full: "FULL_CRON_SCHEDULE"
        differential: "DIFF_CRON_SCHEDULE"
        incremental: "INCR_CRON_SCHEDULE"
      backupRetainDays: RETENTION_DAYS
      paused: PAUSED_BOOLEAN

Substitua o seguinte:

• BACKUP_PLAN_NAME: um nome para esse recurso de plano de backup, por exemplo, backup-plan-1.

• NAMESPACE: o namespace do Kubernetes para este plano de backup. Ele precisa corresponder ao namespace do cluster de banco de dados.

• DB_CLUSTER_NAME: o nome do cluster de banco de dados, que você atribuiu ao criá-lo.

• FULL_CRON_SCHEDULE: uma programação de backup para criar um backup completo, contendo todos os dados, expresso no formato cron. Por exemplo, defina como "0 0 * * 0" para fazer um backup completo às 0h todos os domingos.

• DIFF_CRON_SCHEDULE: uma programação de backup para criar backups que são inicialmente backups completos. Os backups subsequentes são diferenciais, com base nas alterações de intervenção nos dados, expressas no formato cron. Por exemplo, defina como "0 22 * * 3" para fazer um backup diferencial às 22h todas as quartas-feiras.

• INCR_CRON_SCHEDULE: uma programação de backup para criar backups que incluem dados que foram alterados desde o último backup completo, diferencial ou incremental. Ela é expressa no formatocron. Por exemplo, defina como "0 21 * * *" para fazer um backup incremental às 21h todos os dias.

• RETENTION_DAYS: o número de dias em que o operador do AlloyDB Omni retém esse backup. Ele precisa ser um número inteiro entre 1 e 90. O valor padrão é 14.

• PAUSED_BOOLEAN: especifica se o plano de backup está pausado ou não. Forneça um dos seguintes valores:

  • true: os backups são pausados e nenhum backup programado é criado.

  • false: o operador do AlloyDB Omni cria backups de acordo com o cronograma especificado por cronSchedule. Esse será o valor padrão, se não for definido explicitamente como true.

  O valor padrão é false.

Criar um plano que armazene backups no Cloud Storage

Para ativar os backups armazenados no Cloud Storage, siga estas etapas:

Observação: se você optar por armazenar backups localmente, planeje o espaço em disco com cuidado. Quanto maior o período de armazenamento, mais espaço será necessário.

1. Crie um bucket do Cloud Storage. Anote o nome atribuído a esse bucket, porque você vai precisar dele em uma etapa posterior.

2. Crie uma conta de serviço para adicionar backups ao bucket.

3. Conceda o papel Gerenciamento de identidade e acesso storage.objectAdmin à conta de serviço.

4. Crie uma chave para a conta de serviço. Isso baixará a chave privada para o ambiente local.

5. Renomeie o arquivo de chave baixado para key.json.

6. Crie um secret do Kubernetes que contenha a chave privada:

   kubectl create secret generic SECRET_NAME --from-file=KEY_PATH -n NAMESPACE

   Substitua o seguinte:

   • SECRET_NAME: o nome do secret do Kubernetes que você está criando. Por exemplo, gcs-key.

   • KEY_PATH: o caminho do sistema de arquivos local para o arquivo key.json que você baixou nas etapas anteriores.

   • NAMESPACE: o namespace do cluster de banco de dados.

7. Aplique o seguinte manifesto:

     apiVersion: alloydbomni.dbadmin.goog/v1
     kind: BackupPlan
     metadata:
       name: BACKUP_PLAN_NAME
       namespace: NAMESPACE
     spec:
       dbclusterRef: DB_CLUSTER_NAME
       backupSchedules:
         full: "FULL_CRON_SCHEDULE"
         differential: "DIFF_CRON_SCHEDULE"
         incremental: "INCR_CRON_SCHEDULE"
       backupRetainDays: RETENTION_DAYS
       paused: PAUSED_BOOLEAN
       backupLocation:
         type: GCS
         gcsOptions:
           bucket: BUCKET_URL
           key: BACKUP_PATH
           secretRef:
             name: SECRET_NAME
             namespace: NAMESPACE
   

   Substitua o seguinte:

   • BACKUP_PLAN_NAME: um nome para esse recurso de plano de backup, por exemplo, backup-plan-1.

   • NAMESPACE: o namespace do Kubernetes para este plano de backup. Ele precisa corresponder ao namespace do cluster de banco de dados.

   • DB_CLUSTER_NAME: o nome do cluster de banco de dados, que você atribuiu ao criá-lo.

   • FULL_CRON_SCHEDULE: uma programação de backup para criar um backup completo, contendo todos os dados, expresso no formato cron. Por exemplo, defina como "0 0 * * 0" para fazer um backup completo às 0h todos os domingos.

   • DIFF_CRON_SCHEDULE: uma programação de backup para criar backups que são inicialmente backups completos. Os backups subsequentes são diferenciais, com base nas alterações de intervenção nos dados, expressas no formato cron. Por exemplo, defina como "0 22 * * 3" para fazer um backup diferencial às 22h todas as quartas-feiras.

   • INCR_CRON_SCHEDULE: uma programação de backup para criar backups que incluem dados que foram alterados desde o último backup completo, diferencial ou incremental. Ela é expressa no formatocron. Por exemplo, defina como "0 21 * * *" para fazer um backup incremental às 21h todos os dias.

   • RETENTION_DAYS: o número de dias em que o operador do AlloyDB Omni retém esse backup. Ele precisa ser um número inteiro entre 1 e 90. O valor padrão é 14.

   • PAUSED_BOOLEAN: especifica se o plano de backup está pausado ou não. Forneça um dos seguintes valores:

     • true: os backups são pausados e nenhum backup programado é criado.

     • false: o operador do AlloyDB Omni cria backups de acordo com o cronograma especificado por cronSchedule. Esse será o valor padrão, se não for definido explicitamente como true.

     O valor padrão é false.

   • BUCKET_URL: o nome do bucket do Cloud Storage criado em uma etapa anterior. Esse não é o URL completo do bucket. Não coloque o prefixo gs:// no nome do bucket.

   • BACKUP_PATH: o caminho do diretório em que o operador do AlloyDB Omni grava backups no bucket do Cloud Storage. O caminho precisa ser absoluto e começar com /.

   • SECRET_NAME: o nome escolhido para o secret do Kubernetes criado em uma etapa anterior.

Criar backups para armazenamento compatível com S3

É possível usar o campo s30options para enviar backups a endpoints compatíveis com S3.

As etapas no procedimento a seguir são gerais. Para instruções específicas para seu caso de uso, consulte a documentação do provedor do S3.

Para ativar os backups no seu armazenamento compatível com S3, siga estas etapas gerais:

1. Crie um bucket de armazenamento do S3. Anote o nome atribuído a esse bucket, porque você vai precisar dele em uma etapa posterior.
2. Para acessar o bucket de armazenamento do S3, crie um principal, por exemplo, uma conta de serviço ou um usuário. Verifique com seu provedor do S3 se é necessário conceder um papel ou uma política predefinida ao principal.
3. Conceda acesso de leitura e gravação ao principal criado na etapa anterior. Essa etapa permite ler e gravar no bucket de armazenamento do S3.
4. Crie uma chave de acesso para o principal que você criou. A chave de acesso inclui um ID e um segredo. Essa operação baixa a chave para o ambiente local.

5. Crie um secret do Kubernetes que contenha a chave:

   kubectl create secret generic SECRET_NAME --from-literal=access-key-id=KEY_ID --from-literal=access-key=KEY -n NAMESPACE

   Substitua:

   • SECRET_NAME: o nome do secret do Kubernetes que você está criando. Por exemplo, s3-key.
   • KEY_ID: o ID da chave de acesso.
   • KEY: o segredo da chave de acesso.
   • NAMESPACE: o espaço em que o nome do secret é mantido. Esse valor precisa ser exclusivo.

6. Aplique o seguinte manifesto:

   apiVersion: alloydbomni.dbadmin.goog/v1
   kind: BackupPlan
   metadata:
     name: BACKUP_PLAN_NAME
     namespace: NAMESPACE
   spec:
     dbclusterRef: DB_CLUSTER_NAME
     backupSchedules:
       full: "FULL_CRON_SCHEDULE"
       differential: "DIFF_CRON_SCHEDULE"
       incremental: "INCR_CRON_SCHEDULE"
     backupRetainDays: RETENTION_DAYS
     paused: PAUSED_BOOLEAN
     backupLocation:
       type: S3
       s3Options:
         bucket: BUCKET_NAME
         region: REGION
         endpoint: S3ENDPOINT
         key: BACKUP_PATH
         secretRef:
           namespace: NAMESPACE
           name: SECRET_NAME
         certRef:
           name: CA_BUNDLE_SECRET_NAME
           namespace: NAMESPACE
   

   Substitua:

   • BACKUP_PLAN_NAME: um nome para esse recurso de plano de backup, por exemplo, backup-plan-1.
   • NAMESPACE: o namespace do Kubernetes para este plano de backup. O namespace precisa corresponder ao namespace do cluster de banco de dados.
   • DB_CLUSTER_NAME: o nome do cluster de banco de dados, que você atribuiu ao criá-lo.
   • FULL_CRON_SCHEDULE: uma programação de backup para criar um backup completo, contendo todos os dados, expresso no formato cron. Por exemplo, para fazer um backup completo às 0h todos os domingos, defina FULL_CRON_SCHEDULE como
     0 0 * * 0.
   • DIFF_CRON_SCHEDULE: uma programação de backup para criar backups que são inicialmente backups completos. Os backups subsequentes são diferenciais, com base nas alterações de intervenção nos dados, expressas no formato cron. Por exemplo, para fazer um backup diferencial às 22h todas as quartas-feiras, defina como 0 22 * * 3 .
   • INCR_CRON_SCHEDULE: uma programação de backup para criar backups que incluem dados que foram alterados desde o último backup completo, diferencial ou incremental. Ela é expressa no formatocron. Por exemplo, para fazer um backup incremental às 21h todos os dias, defina como 0 21 * * * .
   • RETENTION_DAYS: o número de dias em que o operador do AlloyDB Omni no Kubernetes retém esse backup. Esse parâmetro precisa ser um número inteiro entre 1 e 90. O valor padrão é 14.
   • PAUSED_BOOLEAN: especifica se o plano de backup está pausado ou não. Forneça um dos seguintes valores:
     • true: os backups são pausados e nenhum backup programado é criado.
     • false: o valor padrão. O operador do AlloyDB Omni cria backups de acordo com o cronograma especificado por cronSchedule. Esse será o valor padrão, se não for definido explicitamente como true.
   • BUCKET_NAME: o nome do bucket de armazenamento do S3 que você criou. O nome do bucket não é o URL completo dele. Não coloque o prefixo gs:// no nome do bucket.
   • REGION: a região em que o bucket do S3 está armazenado.
   • S3ENDPOINT: o endpoint do bucket de armazenamento do S3.
   • BACKUP_PATH: o caminho do diretório em que o operador do AlloyDB Omni grava backups no bucket de armazenamento do S3. O caminho precisa ser absoluto e começar com /.
   • NAMESPACE: o espaço em que o nome do secret precisa ser exclusivo.
   • SECRET_NAME: o nome escolhido para o secret do Kubernetes criado.

   • CA_BUNDLE_SECRET_NAME: um pool de certificados de CA codificados por PEM que o servidor do S3 usa para validar o certificado. Verifique se o pacote está incluído no secret em uma chave chamada ca.crt.

     O exemplo a seguir mostra como criar um secret que contém o certificado, em que PEM_FILE_PATH é o caminho para o arquivo de pacote ca:

     kubectl create secret generic CA_BUNDLE_SECRET_NAME -n NAMESPACE --from-file=ca.crt=PEM_FILE_PATH
     

Criar um backup manualmente

É possível criar um recurso de backup manualmente a qualquer momento usando um plano de backup que já tenha sido aplicado a um cluster de banco de dados. O operador do AlloyDB Omni aplica o local de armazenamento e o período de armazenamento do plano de backup escolhido ao novo backup manual.

Para criar um backup manualmente, aplique o seguinte manifesto:

apiVersion: alloydbomni.dbadmin.goog/v1
kind: Backup
metadata:
  name: BACKUP_NAME
  namespace: NAMESPACE
spec:
  dbclusterRef: DB_CLUSTER_NAME
  backupPlanRef: BACKUP_PLAN_NAME
  manual: true
  physicalBackupSpec:
    backupType: BACKUP_TYPE

Substitua o seguinte:

• BACKUP_NAME: um nome para o backup, por exemplo, backup-1.

• NAMESPACE: o namespace do Kubernetes desta restauração. Ele precisa corresponder ao namespace do cluster de banco de dados.

• BACKUP_PLAN_NAME: o nome do recurso do plano de backup ao qual este backup pertence. Ele precisa corresponder ao nome escolhido quando você criou o plano de backup.

• DB_CLUSTER_NAME: o nome do cluster de banco de dados, que você atribuiu ao criá-lo .

• BACKUP_TYPE: especifica o tipo de backup manual que você quer criar. Escolha um dos seguintes valores:

  • full: cria um backup completo, contendo todos os dados.

  • diff: cria um backup diferencial que depende do último backup completo. Os backups subsequentes são diferenciais, com base nas alterações de intervenção nos dados.

  • incr: cria um backup incremental que depende do backup completo ou diferencial anterior para incluir dados que foram alterados desde o último backup completo ou diferencial.

Monitorar e listar backups

Seus planos e backups são todos recursos no cluster do Kubernetes. Para visualizar informações sobre eles, use o comando kubectl get.

Visualizar um resumo do plano de backup

Para visualizar informações sobre os planos de backup do cluster de banco de dados, execute o seguinte comando:

kubectl get backupplan.alloydbomni.dbadmin.goog -n NAMESPACE

Substitua NAMESPACE pelo namespace do cluster de banco de dados.

A resposta é parecida com esta:

NAME               PHASE   LASTBACKUPTIME         NEXTBACKUPTIME
backup-plan-prod   Ready   2023-10-26T17:26:43Z   2023-10-27T00:00:00Z

Visualizar uma lista de backups

Para visualizar uma lista de backups disponíveis para o cluster de banco de dados, execute o seguinte comando:

kubectl get backup.alloydbomni.dbadmin.goog -n NAMESPACE

Substitua NAMESPACE pelo namespace do cluster de banco de dados.

A resposta é parecida com esta:

NAME                              PHASE       COMPLETETIME
backup-plan-prod-20231026172643   Succeeded   2023-10-26T17:26:53Z
manual-backup-1                   Succeeded   2023-10-26T18:15:27Z
manual-backup-2                   InProgress

Cada linha na tabela de saída representa um recurso de backup, com os seguintes atributos:

• O nome do backup.
• O estado do backup, com Succeeded marcando um backup pronto para restauração.
• O carimbo de data/hora da criação do backup.

Restaurar a partir de um backup

Atenção: a restauração a partir de um backup substitui todos os dados do cluster de banco de dados.

Com o AlloyDB, é possível restaurar backups individuais ou clonar um cluster usando um backup de um momento específico.

Restauração com base em um backup nomeado

Para fazer a restauração com base em um backup, substituindo os dados no cluster de banco de dados pelos dados no backup, siga estas etapas.

1. Liste todos os backups cuja fase é Succeeded.

   kubectl get backup.alloydbomni.dbadmin.goog -n NAMESPACE | grep Succeeded

   Substitua NAMESPACE pelo namespace do cluster de banco de dados.

   Se houver pelo menos um bom candidato a backup, a resposta será parecida com esta:

   backup-plan-prod-20231026172643   Succeeded   2023-10-26T17:26:53Z
   manual-backup-1                   Succeeded   2023-10-26T18:15:27Z
   

2. Escolha um dos backups listados na etapa anterior como o backup com base no qual será feita a restauração. Anote o nome dele, que será usado na próxima etapa.

3. Aplique o seguinte manifesto:

     apiVersion: alloydbomni.dbadmin.goog/v1
     kind: Restore
     metadata:
       name: RESTORE_NAME
       namespace: NAMESPACE
     spec:
       sourceDBCluster: DB_CLUSTER_NAME
       backup: BACKUP_NAME
   

   Substitua o seguinte:

   • RESTORE_NAME: um nome a ser usado com o recurso data-restore criado por esse manifesto. Por exemplo, restore-1.

   • DB_CLUSTER_NAME: o nome do cluster de banco de dados, que você atribuiu ao criá-lo .

   • BACKUP_NAME: o nome do backup escolhido na etapa anterior.

Clonagem pontual de um cluster

O operador do AlloyDB Omni permite clonar os dados do cluster de qualquer momento dentro de uma janela de recuperação. A duração da janela de recuperação é determinada diretamente pelo período de armazenamento.

Por exemplo, se o período de armazenamento for de 14 dias, não será possível recuperar dados com mais de 14 dias. É possível fazer a restauração para qualquer momento dentro da janela de recuperação. O operador do AlloyDB Omni retém backups e registros por um dia a mais do que o valor especificado.

Observação: o operador do AlloyDB Omni só é compatível com a clonagem de um momento no mesmo namespace e no mesmo cluster do Kubernetes. A clonagem entre namespaces não é compatível. Para restauração ou clonagem entre clusters, consulte o manual de recuperação de desastres com base em backup e restauração.

1. Monitore sua janela de recuperação para identificar o ponto de restauração:

   kubectl get backupplan.alloydbomni.dbadmin.goog BACKUP_NAME -n NAMESPACE -o json | jq .status.recoveryWindow
   

   Confira um exemplo de resposta:

   recoveryWindow:
   begin: "2024-01-31T02:54:35Z"
   

   O valor de carimbo de data/hora no formato RFC 3339 é usado no recurso de restauração.

2. Crie e aplique o seguinte manifesto de recurso de restauração:

   apiVersion: alloydbomni.dbadmin.goog/v1
   kind: Restore
   metadata:
     name: RESTORE_NAME
     namespace: NAMESPACE
   spec:
     sourceDBCluster: DB_CLUSTER_NAME
     pointInTime: "DATE_AND_TIME_STAMP"
     clonedDBClusterConfig:
       dbclusterName: NEW_DB_CLUSTER_NAME
   

   Substitua o seguinte:

   • RESTORE_NAME: um nome a ser usado com o recurso data-restore criado por esse manifesto. Por exemplo, restore-1.

   • DB_CLUSTER_NAME: o nome do cluster de banco de dados, que você atribuiu ao criá-lo.

   • DATE_AND_TIME_STAMP: o carimbo de data/hora RFC 3339 com granularidade de minutos do backup contínuo que você quer restaurar. Por exemplo, 2024-03-05T15:32:10Z.

   • NEW_DB_CLUSTER_NAME: o nome do novo cluster de banco de dados.

Visualizar o status da restauração

1. Visualize o progresso da operação de restauração:

   kubectl get restore.alloydbomni.dbadmin.goog -n NAMESPACE

   Substitua NAMESPACE pelo namespace do cluster de banco de dados.

   Para executar o comando continuamente, adicione a flag -Aw.

   A resposta é parecida com esta:

   NAME        PHASE               COMPLETETIME   RESTOREDPOINTINTIME
   restore-1   RestoreInProgress
   

   Quando o valor da coluna PHASE na tabela de saída for ProvisionSucceeded, a restauração será concluída.

2. Visualize o progresso do cluster de banco de dados restaurado ou clonado ficando on-line:

   kubectl get dbclusters -A -n NAMESPACE

   Substitua NAMESPACE pelo namespace do cluster de banco de dados.

   Para executar o comando continuamente, adicione a flag -Aw.

   A resposta é parecida com esta:

   NAMESPACE   NAME               PRIMARYENDPOINT   PRIMARYPHASE   DBCLUSTERPHASE
   default     db-cluster-1       10.128.0.55       Ready          DBClusterReady
   

   Quando o valor da coluna DBCLUSTERPHASE na tabela de saída for DBClusterReady, o cluster de banco de dados restaurado ou clonado estará pronto para uso.

Excluir um backup

Normalmente, não é necessário excluir backups manualmente. O operador do AlloyDB Omni exclui automaticamente os backups mais antigos que o período de armazenamento especificado ao criar um plano de backup.

Se você quiser excluir um backup manualmente, ele precisará atender aos seguintes requisitos:

• O backup não é o único armazenado para o plano de backup. O operador do AlloyDB Omni exige que haja pelo menos um backup por plano de backup.

• O backup não tem outros backups dependentes. Por exemplo, um backup completo com backups diferenciais ou incrementais que dependem dele ou um backup incremental com backups diferenciais que dependem dele.

Para excluir um backup, execute o seguinte comando:

kubectl delete backup.alloydbomni.dbadmin.goog/BACKUP_NAME -n NAMESPACE

Substitua o seguinte:

• BACKUP_NAME: o nome do backup a ser excluído.

• NAMESPACE: o namespace do cluster de banco de dados.

Redimensionar um disco de backup

Para redimensionar o disco local que armazena seus backups no cluster do Kubernetes, siga estas etapas:

1. Atualize o campo resources.disks do manifesto do DBCluster da seguinte maneira:

   spec:
     primarySpec:
       resources:
         disks:
           - name: BACKUP_DISK
             size: 10Gi
   

   Substitua BACKUP_DISK pelo nome do disco que armazena seus backups.

2. Aplique o manifesto para aplicar obrigatoriamente a atualização.

   O operador do AlloyDB Omni aplica as especificações atualizadas ao DBCluster imediatamente.

As restrições a seguir se aplicam à modificação do disco de backup de um cluster de banco de dados em execução:

• Só é possível aumentar o tamanho de um disco se o storageClass especificado for compatível com a expansão de volume.
• Não é possível diminuir o tamanho de um disco.

Atualizar um plano de backup

Cada plano de backup é um recurso do Kubernetes. Para atualizar a configuração dele, faça o seguinte:

• Edite e aplique novamente o arquivo de manifesto do plano de backup.

• Use o comando kubectl patch.

Por exemplo, para pausar um plano de backup em execução, altere o atributo paused do manifesto para true e aplique o manifesto novamente.

Excluir um plano de backup

Atenção: a exclusão de um plano de backup limpa permanentemente todos os backups associados a ele.

Para excluir um plano de backup e remover todos os recursos dele, execute o seguinte comando:

kubectl delete backupplan.alloydbomni.dbadmin.goog/BACKUP_PLAN_NAME -n NAMESPACE

Substitua o seguinte:

• BACKUP_PLAN_NAME: o nome do plano de backup a ser excluído.

• NAMESPACE: o namespace do cluster de banco de dados.

Para pausar um plano de backup sem excluí-lo, defina o atributo paused do recurso do plano de backup como true. Um plano de backup pausado continua armazenando backups e permite a criação manual de backups.