Fazer backup e restaurar no Kubernetes

Nesta página, mostramos como fazer backup e restaurar seus dados do AlloyDB Omni usando o operador AlloyDB Omni no Kubernetes. Isso requer conhecimento básico 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 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 definidas no recurso backupPlan. Se não houver uma programação de backup 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 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 do banco de dados. É necessário criar um recurso backupPlan para cada cluster de banco de dados para ativar o backup contínuo. Esse recurso de plano de backup define os seguintes parâmetros:

• O local em que o operador do AlloyDB Omni armazena backups. Isso pode ser local para seu cluster do Kubernetes ou para 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, inclusive ao definir o plano de backup pela primeira vez. Se um plano de backup estiver pausado, os backups programados não serão criados, mas você ainda poderá 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. Isso pode levar de um dia a 90 dias. O valor padrão é 14.

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

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:

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

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

• DB_CLUSTER_NAME: o nome do cluster de banco de dados, que você atribuiu ao criar o cluster.

• FULL_CRON_SCHEDULE: uma programação de backup para criar um backup completo, contendo todos os dados, expressos no formato cron. Por exemplo, defina como "0 0 * * 0" para fazer um backup completo às 00h de 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 mudanças intermediárias nos dados, expressas no formato cron. Por exemplo, defina "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 alterados desde o último backup completo, diferencial ou incremental. Ele é expresso no formato cron. 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 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. Informe um dos seguintes valores:

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

  • false: o operador AlloyDB Omni cria backups de acordo com a programação especificada por cronSchedule. Esse é o valor padrão, se não for definido explicitamente como true.

  O valor padrão é false.

Criar um plano que armazena 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 seu espaço em disco com cuidado. Quanto maior o período de armazenamento, mais espaço você vai precisar.

1. Criar 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 do Identity and Access Management storage.objectAdmin à conta de serviço.

4. Crie uma chave para a conta de serviço. Isso faz o download da chave privada para o ambiente local.

5. Renomeie o arquivo de chave transferido por download 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:

   • 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ê fez o download nas etapas anteriores.

   • NAMESPACE: o namespace do cluster do 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:

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

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

   • DB_CLUSTER_NAME: o nome do cluster de banco de dados, que você atribuiu ao criar o cluster.

   • FULL_CRON_SCHEDULE: uma programação de backup para criar um backup completo, contendo todos os dados, expressos no formato cron. Por exemplo, defina como "0 0 * * 0" para fazer um backup completo às 00h de 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 mudanças intermediárias nos dados, expressas no formato cron. Por exemplo, defina "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 alterados desde o último backup completo, diferencial ou incremental. Ele é expresso no formato cron. 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 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. Informe um dos seguintes valores:

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

     • false: o operador AlloyDB Omni cria backups de acordo com a programação especificada por cronSchedule. Esse é 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 use 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 um backup manualmente

É possível criar um recurso de backup manualmente a qualquer momento usando qualquer 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:

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

• NAMESPACE: o namespace do Kubernetes desse restabelecimento. Ele precisa corresponder ao namespace do cluster do banco de dados.

• BACKUP_PLAN_NAME: o nome do recurso do plano de backup a que esse backup pertence. Ele precisa corresponder ao nome escolhido ao criar o plano de backup.

• DB_CLUSTER_NAME: o nome do cluster do banco de dados, que você atribuiu ao criar o cluster.

• 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 mudanças intermediárias dos 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 de backup e backups são todos recursos no cluster do Kubernetes. Para conferir informações sobre eles, use o comando kubectl get.

Conferir o resumo de um plano de backup

Para conferir 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 do banco de dados.

A saída será assim:

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

Visualizar uma lista de backups

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

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

Substitua NAMESPACE pelo namespace do cluster do banco de dados.

A saída será assim:

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

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 ser restaurado.
• O carimbo de data/hora de criação do backup.

Restaurar a partir de um backup

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

O AlloyDB permite restaurar backups individuais ou clonar um cluster usando um backup de um momento específico.

Restaurar de um backup nomeado

Para restaurar de um backup, substituindo os dados no cluster de banco de dados pelos dados no backup, siga estas etapas.

1. Liste todos os backups com a fase Succeeded.

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

   Substitua NAMESPACE pelo namespace do cluster do banco de dados.

   Se pelo menos um candidato de backup válido existir, a saída será semelhante a 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 para restaurar. 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:

   • RESTORE_NAME: um nome a ser usado com o recurso de restauração de dados criado por esse manifesto. Por exemplo, restore-1.

   • DB_CLUSTER_NAME: o nome do cluster de banco de dados, que você atribuiu ao criar o cluster.

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

Clonar um cluster de um momento específico

O operador do AlloyDB Omni permite clonar os dados do cluster a 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 estiver definido como 14 dias, não será possível recuperar dados com mais de 14 dias. É possível restaurar para qualquer ponto no tempo dentro do período 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 AlloyDB Omni só oferece suporte a clones de um ponto no mesmo namespace e cluster do Kubernetes. Não é possível clonar entre namespaces. Para restaurar ou clonar entre clusters, consulte o manual de recuperação de desastres com base em backup e restauração.

1. Monitore a 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 a seguir um exemplo de resposta:

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

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

2. Crie e aplique o seguinte manifesto de recursos 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:

   • RESTORE_NAME: um nome a ser usado com o recurso de restauração de dados criado por esse manifesto, por exemplo, restore-1.

   • DB_CLUSTER_NAME: o nome do cluster de banco de dados, que você atribuiu quando o criou.

   • DATE_AND_TIME_STAMP: o carimbo de data/hora RFC 3339 na 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.

Conferir o status da restauração

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

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

   Substitua NAMESPACE pelo namespace do cluster do banco de dados.

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

   A saída será assim:

   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. Confira o progresso do cluster de banco de dados restaurado ou clonado que está sendo colocado on-line:

   kubectl get dbclusters -A -n NAMESPACE

   Substitua NAMESPACE pelo namespace do cluster do banco de dados.

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

   A saída será assim:

   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 AlloyDB Omni exclui automaticamente 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 a estes requisitos:

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

• O backup não tem outros backups dependentes dele. 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:

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

• NAMESPACE: o namespace do cluster do 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 a atualização.

   O operador 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 oferecer suporte à 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, siga um destes procedimentos:

• Edite e reaplique o arquivo de manifesto do plano de backup.

• Use o comando kubectl patch.

Por exemplo, para pausar um plano de backup em execução, mude 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 exclui permanentemente todos os backups associados a esse plano.

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

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

Substitua:

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

• NAMESPACE: o namespace do cluster do 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.