Criar um repositório de backup para o serviço de banco de dados

Neste documento, descrevemos as etapas para configurar o BackupRepository necessário para o Database Service (DBS) do Google Distributed Cloud (GDC) com isolamento físico. Esse repositório, que precisa ser chamado de dbs-backup-repository, é um recurso personalizado no Kubernetes que direciona o serviço de backup do GDC para um bucket de repositório de objetos compatível com S3 para armazenar backups de banco de dados.

Importante: a configuração do repositório de backup para o GDC DBS precisa ser feita uma vez pelo administrador da plataforma para cada organização. Depois que ele for criado e estiver pronto, não tente atualizá-lo. Caso contrário, isso vai causar um comportamento inesperado de backup e restauração do DBS.

A configuração adequada é crucial para ativar as funcionalidades de backup e restauração para instâncias de DBS, como PostgreSQL, Oracle e AlloyDB Omni.

Observação: todos os recursos descritos neste documento são criados no servidor da API Management.

Antes de começar

Antes de começar, verifique se você tem os seguintes pré-requisitos:

• Projeto:um projeto para hospedar o bucket, normalmente chamado de backups, com acesso apenas à conta de serviço.
• Acesso:permissões suficientes para interagir com o servidor da API de gerenciamento.
  • O usuário precisa ter os seguintes papéis no nível da organização para criar o repositório de backup:
    • Administrador de bucket (bucket-admin)
    • project-creatorCriador do projeto
    • Administrador de backup da organização (organization-backup-admin)
  • Dentro do projeto de destino:
    • Administrador de IAM do projeto (project-iam-admin)
    • Leitor de projetos de objetos de bucket (project-bucket-object-viewer)
    • Administrador de projetos de objetos de bucket (project-bucket-object-admin)
    • Administrador de projetos de bucket (project-bucket-admin)
    • Leitor de secrets (secret-viewer)
    • Administrador de namespace (namespace-admin)
    • Criador de backup (backup-creator)
• Ferramentas:
  • O console do GDC.
  • CLI kubectl configurada para acessar o servidor da API de gerenciamento.

Criar um bucket de repositório de objetos

Todas as etapas seguintes são realizadas no servidor de API Management. Defina e crie um recurso Bucket. O nome recomendado dbs-backups para esse bucket de armazenamento é usado no restante deste documento, localizado no namespace do projeto backups. Verifique se o bucket não tem uma política de retenção.

Console

1. Faça login no console do GDC da organização.
2. Verifique se você está no projeto backups.
3. Acesse Repositório de objetos > Buckets.
4. Clique em Criar bucket.
5. Defina o nome do bucket como dbs-backups.
6. defina a descrição como Bucket for DBS backups;
7. Configure a classe de armazenamento conforme necessário. Por exemplo, Standard
8. Em Segurança, não defina uma política de retenção, porque isso vai fazer com que os bancos de dados e os backups deles sejam retidos de forma incorreta.
9. Clique em Criar.

API

• Aplique o seguinte manifesto ao servidor da API de gerenciamento:

kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f -
<<EOF
apiVersion: object.gdc.goog/v1
kind: Bucket
metadata:
  name: dbs-backups
  namespace: backups
spec:
  description: "Bucket for DBS backups"
  storageClass: "Standard"
EOF

Criar conta de serviço e definir permissões

Crie uma ProjectServiceAccount e conceda a ela permissões para acessar o bucket.

Console

1. No projeto backups, acesse Identidade e acesso > Identidades de serviço.
2. Clique em Criar identidade de serviço. A página Detalhes da identidade do serviço é aberta.
3. No campo Nome da identidade de serviço, insira dbs-backup-sa.
4. Clique em Criar.
5. Acesse Identidade e acesso > Acesso.
6. Na lista Membro, clique em Adicionar membro. A página Usuários e papéis será exibida.
7. Selecione Identidade de serviço na lista Tipo de membro.
8. Na lista Identidade de serviço, selecione dbs-backup-sa para atribuir uma vinculação de papel.
9. Na lista Papel, selecione Administrador de projetos de objetos do bucket para atribuir à identidade de serviço.
10. Clique em Adicionar.

API

• Aplique esses manifestos ao servidor da API de gerenciamento:

kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f -
<<EOF
apiVersion: resourcemanager.gdc.goog/v1
kind: ProjectServiceAccount
metadata:
  name: dbs-backup-sa
  namespace: backups
spec: {}
EOF

kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f -
<<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dbs-backups-readwrite-rolebinding
  namespace: backups
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: project-bucket-object-admin
subjects:
- kind: ServiceAccount
  name: dbs-backup-sa
  namespace: backups
EOF

Identificar o secret de credencial da conta de serviço e os detalhes do bucket

Ao conceder acesso ao bucket para o dbs-backup-sa, o GDC cria automaticamente um secret no mesmo namespace, backups, que contém as credenciais de acesso do S3. Você precisa encontrar o nome desse secret e os detalhes do bucket usando a CLI (API) kubectl.

1. Defina as variáveis de ambiente:

   export SA_NAMESPACE="backups"
   export SA_NAME="dbs-backup-sa"
   export KUBECONFIG=MANAGEMENT_API_SERVER
   

2. Encontre o nome do secret:

   export BUCKET_CRED_SECRET_NAME=$(kubectl --kubeconfig=${KUBECONFIG} get secret \
       -n "${SA_NAMESPACE}" -l object.gdc.goog/subject-type=ServiceAccount -o json | \
       jq -r --arg SA_NAME "${SA_NAME}" \
       '.items[] | select(.metadata.annotations["object.gdc.goog/subject"] == $SA_NAME and (.metadata.name |startswith("object-storage-key-std-sa-"))) | .metadata.name')
   echo "Bucket Credential Secret Name: ${BUCKET_CRED_SECRET_NAME}"
   

   Esse comando filtra os secrets no namespace backups para encontrar aquele anotado para a conta de serviço dbs-backup-sa e que corresponde à convenção de nomenclatura padrão. Para executar esse comando, você precisa ter o papel de Leitor de Secrets (secret-viewer) no projeto backups ou pedir ao administrador da plataforma que criou a conta de serviço para fornecer o nome do secret.

3. Receba detalhes do endpoint e da região do bucket:

   export BUCKET_NAME=dbs-backups
   export FULL_BUCKET_NAME=$(kubectl --kubeconfig=${KUBECONFIG} get bucket -n ${SA_NAMESPACE} ${BUCKET_NAME} -o jsonpath='{.status.fullyQualifiedName}')
   export ENDPOINT=$(kubectl --kubeconfig=${KUBECONFIG} get bucket -n ${SA_NAMESPACE} ${BUCKET_NAME} -o jsonpath='{.status.endpoint}')
   export REGION=$(kubectl --kubeconfig=${KUBECONFIG} get bucket -n ${SA_NAMESPACE} ${BUCKET_NAME} -o jsonpath='{.status.region}')
   
   echo "FULL_BUCKET_NAME: ${FULL_BUCKET_NAME}"
   echo "ENDPOINT: ${ENDPOINT}"
   echo "REGION: ${REGION}"
   

Criar o BackupRepository

Crie o recurso BackupRepository, referenciando o secret identificado na seção anterior, Identificar o secret de credencial da conta de serviço e os detalhes do bucket. Essa etapa precisa ser concluída usando a CLI (API) kubectl.

• Crie o arquivo YAML, como backup-repo.yaml, substituindo as variáveis encontradas na seção anterior:

  kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f -
  <<EOF
  apiVersion: backup.gdc.goog/v1
  kind: BackupRepository
  metadata:
    name: dbs-backup-repository # This specific name is required for DBS
  spec:
    secretReference:
      namespace: "backups" # Namespace of the Service Account and the auto-generated secret
      name: BUCKET_CRED_SECRET_NAME
    endpoint: ENDPOINT
    type: "S3"
    s3Options:
      bucket: FULL_BUCKET_NAME
      region: REGION
      forcePathStyle: true
    importPolicy: "ReadWrite"
    force: true
    EOF
  

  Substitua:

  • BUCKET_CRED_SECRET_NAME: o nome do secret.
  • ENDPOINT: o endpoint do bucket.
  • FULL_BUCKET_NAME: o nome totalmente qualificado do bucket.
  • REGION: a região do bucket.

Verificar o repositório de backup

Verifique o status do repositório para garantir que ele foi configurado corretamente.

1. Imprima as informações do repositório de backup:

   kubectl --kubeconfig MANAGEMENT_API_SERVER get backuprepository dbs-backup-repository -ojson | jq .status
   

2. Verifique se a saída é semelhante a esta. Uma mensagem NoError é o sinal de que o repositório foi configurado como esperado:

   NAME                    TYPE   POLICY      ERROR
   dbs-backup-repository   S3     ReadWrite   NoError
   status:
     conditions:
     - lastTransitionTime: "2025-11-13T00:36:09Z"
       message: Backup Repository reconciled successfully
       reason: Ready
       status: "True"
       type: Ready
     initialImportDone: true
     reconciliationError: NoError
     sentinelEtag: 9b82fbb7-6ea2-444d-8878-ab91397ae961