Faça cópias de segurança e restaure no Kubernetes

Selecione uma versão da documentação:

Esta página mostra-lhe como fazer uma cópia de segurança e restaurar os seus dados do AlloyDB Omni usando o operador do AlloyDB Omni Kubernetes. Isto requer conhecimentos básicos sobre a atualização de um cluster do Kubernetes através de ficheiros de manifesto e da ferramenta de linha de comando kubectl. Para mais informações sobre a instalação e a execução do AlloyDB Omni num cluster do Kubernetes, consulte o artigo Instale o AlloyDB Omni no Kubernetes.

Para ativar a cópia de segurança e recuperação contínuas do AlloyDB Omni, tem de criar um plano de cópia de segurança para cada cluster de base de dados. As cópias de segurança são feitas com base nas programações de cópias de segurança definidas no recurso backupPlan. Se não for definido nenhum horário de cópia de segurança no plano de cópia de segurança, as cópias de segurança contínuas são feitas diariamente por predefinição. Pode restaurar ou clonar cópias de segurança de qualquer data/hora no período de recuperação com uma granularidade de segundos.

Para obter informações sobre como fazer uma cópia de segurança e restaurar os dados do AlloyDB Omni em implementações não baseadas no Kubernetes, consulte os artigos Configure o Barman para o AlloyDB Omni e Configure o pgBackRest para o AlloyDB Omni.

Ative e agende cópias de segurança

As cópias de segurança contínuas são ativadas quando cria um recurso de plano de cópia de segurança para o seu cluster de base de dados. Tem de criar um recurso backupPlan para cada cluster de base de dados para ativar a cópia de segurança contínua desse cluster. Este recurso de plano de cópia de segurança define os seguintes parâmetros:

  • A localização para a qual o operador do AlloyDB Omni armazena as cópias de segurança. Pode ser local para o seu cluster do Kubernetes ou para um contentor do Cloud Storage.

  • Uma opção para definir vários horários de cópia de segurança que criam automaticamente cópias de segurança de full, incremental e differential. Pode pausar esta agenda em qualquer altura, inclusive quando define inicialmente o plano de cópia de segurança. Se um plano de reserva estiver pausado, não são criadas cópias de segurança agendadas, mas pode continuar a usá-lo para criar cópias de segurança manualmente.

    Se não forem especificados horários de cópia de segurança, a predefinição é "0 0 * * *", que faz uma cópia de segurança completa diária à meia-noite, hora local.

  • Um período de retenção para cópias de segurança armazenadas. Este período pode ter uma duração mínima de um dia ou máxima de 90 dias. O valor predefinido é 14.

O cluster de base de dados pode ter vários planos de cópia de segurança, cada um com o seu próprio nome e configuração. Se criar vários recursos backupPlan com diferentes programações de cópias de segurança para um cluster de base de dados, tem de definir uma localização de cópia de segurança exclusiva para cada recurso de cópia de segurança.

Crie um plano para armazenar cópias de segurança localmente

Para ativar as cópias de segurança armazenadas 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 este recurso do plano de cópia de segurança, por exemplo, backup-plan-1.

  • NAMESPACE: o namespace do Kubernetes para este plano de cópia de segurança. Tem de corresponder ao espaço de nomes do cluster da base de dados.

  • DB_CLUSTER_NAME: o nome do cluster da base de dados, que atribuiu quando o criou.

  • FULL_CRON_SCHEDULE: um agendamento de cópia de segurança para criar uma cópia de segurança completa, que contém todos os dados, expressa no formato cron. Por exemplo, defina como "0 0 * * 0" para fazer uma cópia de segurança completa todos os domingos às 00:00.

  • DIFF_CRON_SCHEDULE: um agendamento de cópias de segurança para criar cópias de segurança que são inicialmente cópias de segurança completas. As cópias de segurança subsequentes são diferenciais, com base nas alterações entretanto feitas aos dados, expressas no cron formato. Por exemplo, defina "0 22 * * 3" para fazer uma cópia de segurança diferencial às 22:00 todas as quartas-feiras.

  • INCR_CRON_SCHEDULE: um agendamento de cópias de segurança para criar cópias de segurança que incluem dados que foram alterados desde a última cópia de segurança completa, diferencial ou incremental. É expresso no cron formato. Por exemplo, defina como "0 21 * * *" para fazer uma cópia de segurança incremental às 21:00 todos os dias.

  • RETENTION_DAYS: o número de dias durante os quais o operador do AlloyDB Omni retém esta cópia de segurança. Tem de ser um número inteiro entre 1 e 90. O valor predefinido é 14.

  • PAUSED_BOOLEAN: especifica se o plano de cópia de segurança está ou não pausado. Indique um dos seguintes valores:

    • true: as cópias de segurança estão em pausa e não são criadas cópias de segurança agendadas.

    • false: o operador AlloyDB Omni cria cópias de segurança de acordo com o agendamento especificado por cronSchedule. Este é o valor predefinido se não for definido explicitamente como true.

    O valor predefinido é false.

Crie um plano que armazene cópias de segurança no Cloud Storage

Para ativar as cópias de segurança que são armazenadas no Cloud Storage, siga estes passos:

  1. Crie um contentor do Cloud Storage. Tome nota do nome que atribui a este contentor. Vai precisar dele num passo posterior.

  2. Crie uma conta de serviço para adicionar cópias de segurança ao contentor.

  3. Conceda a função de gestão de identidade e de acesso storage.objectAdmin à conta de serviço.

  4. Crie uma chave para a conta de serviço. Esta ação transfere a chave privada para o seu ambiente local.

  5. Mude o nome do ficheiro de chave transferido para key.json.

  6. Crie um segredo 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 segredo do Kubernetes que está a criar, por exemplo, gcs-key.

    • KEY_PATH: o caminho do sistema de ficheiros local para o ficheiro key.json que transferiu nos passos anteriores.

    • NAMESPACE: o espaço de nomes do cluster da base 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 este recurso do plano de cópia de segurança, por exemplo, backup-plan-1.

    • NAMESPACE: o namespace do Kubernetes para este plano de cópia de segurança. Tem de corresponder ao espaço de nomes do cluster da base de dados.

    • DB_CLUSTER_NAME: o nome do cluster da base de dados, que atribuiu quando o criou.

    • FULL_CRON_SCHEDULE: um agendamento de cópia de segurança para criar uma cópia de segurança completa, que contém todos os dados, expressa no formato cron. Por exemplo, defina como "0 0 * * 0" para fazer uma cópia de segurança completa todos os domingos às 00:00.

    • DIFF_CRON_SCHEDULE: um agendamento de cópias de segurança para criar cópias de segurança que são inicialmente cópias de segurança completas. As cópias de segurança subsequentes são diferenciais, com base nas alterações entretanto feitas aos dados, expressas no cron formato. Por exemplo, defina "0 22 * * 3" para fazer uma cópia de segurança diferencial às 22:00 todas as quartas-feiras.

    • INCR_CRON_SCHEDULE: um agendamento de cópias de segurança para criar cópias de segurança que incluem dados que foram alterados desde a última cópia de segurança completa, diferencial ou incremental. É expresso no cron formato. Por exemplo, defina como "0 21 * * *" para fazer uma cópia de segurança incremental às 21:00 todos os dias.

    • RETENTION_DAYS: o número de dias durante os quais o operador do AlloyDB Omni retém esta cópia de segurança. Tem de ser um número inteiro entre 1 e 90. O valor predefinido é 14.

    • PAUSED_BOOLEAN: especifica se o plano de cópia de segurança está ou não pausado. Indique um dos seguintes valores:

      • true: as cópias de segurança estão em pausa e não são criadas cópias de segurança agendadas.

      • false: o operador AlloyDB Omni cria cópias de segurança de acordo com o agendamento especificado por cronSchedule. Este é o valor predefinido se não for definido explicitamente como true.

      O valor predefinido é false.

    • BUCKET_URL: o nome do contentor do Cloud Storage que criou num passo anterior. Este não é o URL completo do contentor. Não adicione o prefixo gs:// ao nome do contentor.

    • BACKUP_PATH: o caminho do diretório no qual o operador do AlloyDB Omni escreve as cópias de segurança, no contentor do Cloud Storage. O caminho tem de ser absoluto, começando com /.

    • SECRET_NAME: o nome que escolheu para o segredo do Kubernetes que criou num passo anterior.

Crie cópias de segurança para armazenamento compatível com S3

Pode usar o campo s30options para enviar cópias de segurança para pontos finais compatíveis com S3.

Os passos no procedimento seguinte são de nível elevado. Para receber instruções específicas para o seu exemplo de utilização, consulte a documentação do seu fornecedor do S3.

Para ativar as cópias de segurança no seu armazenamento compatível com S3, siga estes passos gerais:

  1. Crie um contentor de armazenamento S3. Tome nota do nome que atribui a este contentor, porque o vai usar num passo posterior.
  2. Para aceder ao contentor de armazenamento S3, crie um principal, por exemplo, uma conta de serviço ou um utilizador. Consulte o seu fornecedor do S3 para saber se tem de conceder uma função ou uma política predefinida ao principal.
  3. Conceda acesso de leitura/escrita ao principal que criou no passo anterior. Este passo permite-lhe ler e escrever no contentor de armazenamento do S3.
  4. Crie uma chave de acesso para o principal que criou. A chave de acesso inclui um ID da chave e um segredo da chave. Esta operação transfere a chave para o seu 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 o seguinte:

    • SECRET_NAME: o nome do secret do Kubernetes que está a criar, por exemplo, s3-key.
    • KEY_ID: o ID da chave de acesso.
    • KEY: o segredo da chave de acesso.
    • NAMESPACE: o espaço no qual o nome secreto é mantido. Este valor tem de ser único.

  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 o seguinte:

    • BACKUP_PLAN_NAME: um nome para este recurso do plano de cópia de segurança, por exemplo, backup-plan-1.
    • NAMESPACE: o namespace do Kubernetes para este plano de cópia de segurança. O namespace tem de corresponder ao namespace do cluster da base de dados.
    • DB_CLUSTER_NAME: o nome do cluster da base de dados que atribuiu quando o criou.
    • FULL_CRON_SCHEDULE: um agendamento de cópia de segurança para criar uma cópia de segurança completa, que contém todos os dados, expresso no formato cron. Por exemplo, para fazer uma cópia de segurança completa todos os domingos às 00:00, defina FULL_CRON_SCHEDULE como
      0 0 * * 0.
    • DIFF_CRON_SCHEDULE: um agendamento de cópias de segurança para criar cópias de segurança que são inicialmente cópias de segurança completas. As cópias de segurança subsequentes são diferenciais, com base nas alterações entretanto feitas aos dados, expressas no formato cron. Por exemplo, para fazer uma cópia de segurança diferencial às 22:00 todas as quartas-feiras, defina a opção para 0 22 * * 3 .
    • INCR_CRON_SCHEDULE: um agendamento de cópias de segurança para criar cópias de segurança que incluem dados que foram alterados desde a última cópia de segurança completa, diferencial ou incremental. Isto é expresso no formato cron. Por exemplo, para fazer uma cópia de segurança incremental às 21:00 todos os dias, defina esta opção como 0 21 * * * .
    • RETENTION_DAYS: o número de dias durante os quais o operador do Kubernetes do AlloyDB Omni retém esta cópia de segurança. Este parâmetro tem de ser um número inteiro entre 1 e 90. O valor predefinido é 14.
    • PAUSED_BOOLEAN: especifica se o plano de cópia de segurança está ou não em pausa. Indique um dos seguintes valores:
      • true: as cópias de segurança estão em pausa e não são criadas cópias de segurança agendadas.
      • false: o valor predefinido. O operador do AlloyDB Omni cria cópias de segurança de acordo com o agendamento especificado por cronSchedule. Este é o valor predefinido se não for definido explicitamente como true.
    • BUCKET_NAME: o nome do contentor de armazenamento do S3 que criou. O nome do contentor não é o URL completo do contentor. Não adicione o prefixo gs:// ao nome do contentor.
    • REGION: a região onde o contentor do S3 está armazenado.
    • S3ENDPOINT: o ponto final do contentor de armazenamento do S3.
    • BACKUP_PATH: o caminho do diretório no qual o operador do AlloyDB Omni escreve as cópias de segurança, no contentor de armazenamento do S3. O caminho tem de ser absoluto e começar com /.
    • NAMESPACE: o espaço no qual o nome do segredo tem de ser exclusivo.
    • SECRET_NAME: o nome que escolheu para o segredo do Kubernetes que criou.

    • CA_BUNDLE_SECRET_NAME: um conjunto de certificados da AC codificados em PEM que o servidor S3 usa para validar o certificado. Certifique-se de que o pacote está incluído no segredo sob uma chave denominada ca.crt.

      O exemplo seguinte mostra como criar um segredo que contém o certificado, em que PEM_FILE_PATH é o caminho para o ficheiro do pacote ca:

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

Crie manualmente uma cópia de segurança

Pode criar manualmente um recurso de cópia de segurança em qualquer altura, usando qualquer plano de cópia de segurança que já tenha aplicado a um cluster de base de dados. O operador do AlloyDB Omni aplica a localização de armazenamento e o período de retenção do plano de cópia de segurança escolhido à nova cópia de segurança manual.

Para criar manualmente uma cópia de segurança, 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 esta cópia de segurança, por exemplo, backup-1.

  • NAMESPACE: o namespace do Kubernetes desta restauração. Tem de corresponder ao espaço de nomes do cluster da base de dados.

  • BACKUP_PLAN_NAME: o nome do recurso do plano de cópia de segurança ao qual esta cópia de segurança pertence. Tem de corresponder ao nome que escolheu quando criou o plano de contingência.

  • DB_CLUSTER_NAME: o nome do cluster da base de dados, que atribuiu quando o criou.

  • BACKUP_TYPE: especifica o tipo de cópia de segurança manual que quer criar. Escolha um dos seguintes valores:

    • full: cria uma cópia de segurança completa com todos os dados.

    • diff: cria uma cópia de segurança diferencial que depende da última cópia de segurança completa. As cópias de segurança subsequentes são diferenciais, com base nas alterações entretanto feitas aos dados.

    • incr: cria uma cópia de segurança incremental que depende da cópia de segurança completa ou diferencial anterior para incluir dados que foram alterados desde a última cópia de segurança completa ou diferencial.

Monitorize e liste cópias de segurança

Os planos de cópia de segurança e as cópias de segurança são todos recursos no cluster do Kubernetes. Para ver informações sobre os mesmos, use o comando kubectl get.

Veja um resumo do plano de cópia de segurança

Para ver informações sobre os planos de cópia de segurança do cluster da base de dados, execute o seguinte comando:

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

Substitua NAMESPACE pelo espaço de nomes do cluster da base de dados.

O resultado é semelhante ao seguinte:

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

Veja uma lista de cópias de segurança

Para ver uma lista das cópias de segurança disponíveis para o cluster da base de dados, execute o seguinte comando:

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

Substitua NAMESPACE pelo espaço de nomes do cluster da base de dados.

O resultado é semelhante ao seguinte:

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 cópia de segurança, com os seguintes atributos:

  • O nome da cópia de segurança.
  • O estado da cópia de segurança, com Succeeded a marcar uma cópia de segurança pronta para restauro.
  • A data/hora de criação da cópia de segurança.

Restauro a partir de cópia de segurança

O AlloyDB permite-lhe fazer o restauro a partir de cópias de segurança individuais ou clonar um cluster através de uma cópia de segurança de um momento específico.

Restaurar a partir de uma cópia de segurança com nome

Para restaurar a partir de uma cópia de segurança, substituindo os dados no cluster da base de dados pelos dados na cópia de segurança, siga estes passos.

  1. Liste todas as cópias de segurança cuja fase seja Succeeded.

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

    Substitua NAMESPACE pelo espaço de nomes do cluster da base de dados.

    Se existir, pelo menos, um bom candidato alternativo, o resultado é semelhante ao seguinte:

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

  2. Escolha uma das cópias de segurança indicadas no passo anterior como a cópia de segurança a partir da qual restaurar. Tome nota do nome, que vai usar no passo seguinte.

  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 usar com o recurso data-restore que este manifesto cria, por exemplo, restore-1.

    • DB_CLUSTER_NAME: o nome do cluster da base de dados, que atribuiu quando o criou.

    • BACKUP_NAME: o nome da cópia de segurança que escolheu no passo anterior.

Clone um cluster a partir de um momento específico

O operador do AlloyDB Omni permite-lhe clonar os dados do cluster a partir de qualquer ponto no tempo dentro de um período de recuperação. A duração do período de recuperação é determinada diretamente pelo período de retenção.

Por exemplo, se o período de retenção estiver definido como 14 dias, não pode recuperar dados com mais de 14 dias. Pode restaurar para qualquer ponto no tempo dentro do período de recuperação. O operador do AlloyDB Omni retém as cópias de segurança e os registos durante um dia mais do que o valor especificado.

  1. Monitorize a janela de recuperação para identificar o ponto de restauro:

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

    Segue-se um exemplo de resposta:

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

    O valor da data/hora no formato de data/hora RFC 3339 é usado no recurso de restauro.

  2. Crie e aplique o seguinte manifesto de recursos de restauro:

    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 usar com o recurso data-restore que este manifesto cria, por exemplo, restore-1.

    • DB_CLUSTER_NAME: o nome do cluster da base de dados, que atribuiu quando o criou.

    • DATE_AND_TIME_STAMP: a data/hora RFC 3339 com precisão de minutos da cópia de segurança contínua a partir da qual quer fazer o restauro, por exemplo, 2024-03-05T15:32:10Z.

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

Veja o estado do restauro

  1. Veja o progresso da operação de restauro:

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

    Substitua NAMESPACE pelo espaço de nomes do cluster da base de dados.

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

    O resultado é semelhante ao seguinte:

    NAME        PHASE               COMPLETETIME   RESTOREDPOINTINTIME
restore-1   RestoreInProgress

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

  2. Veja o progresso da entrada online do cluster de base de dados restaurado ou clonado:

    kubectl get dbclusters -A -n NAMESPACE

    Substitua NAMESPACE pelo espaço de nomes do cluster da base de dados.

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

    O resultado é semelhante ao seguinte:

    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, significa que o cluster da base de dados restaurado ou clonado está pronto a ser usado.

Elimine uma cópia de segurança

Normalmente, não precisa de eliminar manualmente as cópias de segurança. O operador do AlloyDB Omni elimina automaticamente as cópias de segurança mais antigas do que o período de retenção especificado quando cria um plano de cópia de segurança.

Se quiser eliminar manualmente uma cópia de segurança, esta tem de cumprir os seguintes requisitos:

  • A cópia de segurança não é a única cópia de segurança armazenada para o respetivo plano de cópia de segurança. O operador do AlloyDB Omni requer que exista, pelo menos, uma cópia de segurança por plano de cópia de segurança.

  • A cópia de segurança não tem outras cópias de segurança dependentes dela. Por exemplo, uma cópia de segurança completa com cópias de segurança diferenciais ou incrementais que dependam dela; ou uma cópia de segurança incremental com cópias de segurança diferenciais que dependam dela.

Para eliminar uma cópia de segurança, execute o seguinte comando:

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

Substitua o seguinte:

  • BACKUP_NAME: o nome da cópia de segurança a eliminar.

  • NAMESPACE: o espaço de nomes do cluster da base de dados.

Redimensione um disco de cópia de segurança

Para redimensionar o disco local que armazena as suas cópias de segurança no cluster do Kubernetes, conclua os seguintes passos:

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

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

    Substitua BACKUP_DISK pelo nome do disco que armazena as suas cópias de segurança.

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

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

Aplicam-se as seguintes restrições à modificação do disco de cópia de segurança de um cluster de base de dados em execução:

  • Só pode aumentar o tamanho de um disco se o storageClass especificado suportar a expansão do volume.
  • Não pode diminuir o tamanho de um disco.

Atualize um plano de cópia de segurança

Cada plano de cópia de segurança é um recurso do Kubernetes. Para atualizar a respetiva configuração, faça uma das seguintes ações:

  • Edite e volte a aplicar o ficheiro de manifesto do plano de cópia de segurança.

  • Use o comando kubectl patch.

Por exemplo, para pausar um plano de cópia de segurança em execução, altere o atributo paused do respetivo manifesto para true e, em seguida, volte a aplicar o manifesto.

Elimine um plano de cópia de segurança

Para eliminar um plano de cópia de segurança e remover todos os respetivos recursos de cópia de segurança, execute o comando seguinte:

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

Substitua o seguinte:

  • BACKUP_PLAN_NAME: o nome do plano de cópia de segurança a eliminar.

  • NAMESPACE: o espaço de nomes do cluster da base de dados.

Para pausar um plano de cópia de segurança sem o eliminar, defina o atributo paused do recurso do plano de cópia de segurança como true. Um plano de cópia de segurança pausado continua a armazenar cópias de segurança e permite a criação manual de cópias de segurança.