Implantar a automação de backup escalonável do BigQuery

Last reviewed 2024-09-17 UTC

Este documento descreve como implantar a automatização escalonável de backup do BigQuery.

Este documento é destinado a arquitetos de nuvem, engenheiros e diretores de governança de dados que querem definir e automatizar políticas de dados nas organizações. Ter experiência com o Terraform é útil.

Arquitetura

O diagrama a seguir mostra a arquitetura de backup automatizado:

O Cloud Scheduler aciona a execução. O serviço de despachante, usando a API BigQuery, lista as tabelas no escopo. Por meio de uma mensagem do Pub/Sub, o serviço de despachante envia uma solicitação para cada tabela ao serviço de configurador. O serviço de configurador determina as políticas de backup das tabelas e, em seguida, envia uma solicitação para cada tabela ao serviço relevante do Cloud Run. O serviço do Cloud Run envia uma solicitação para a API BigQuery e executa as operações de backup. O Pub/Sub aciona o serviço de inclusão de tags, que registra os resultados e atualiza o estado do backup na camada de metadados do Cloud Storage.

Para saber mais sobre a arquitetura, consulte Automatização de backup escalonável do BigQuery.

Objetivos

• Crie serviços do Cloud Run.
• Configure as variáveis do Terraform.
• Execute os scripts de implantação manual e do Terraform.
• Execute a solução.

Custos

Neste documento, você usará os seguintes componentes faturáveis do Google Cloud:

• BigQuery
• Pub/Sub
• Cloud Logging
• Cloud Run
• Cloud Storage
• Cloud Scheduler
• Firestore in Datastore mode (Datastore)

Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços. Novos usuários do Google Cloud podem estar qualificados para uma avaliação gratuita.

Ao concluir as tarefas descritas neste documento, é possível evitar o faturamento contínuo excluindo os recursos criados. Para mais informações, consulte Limpeza.

Antes de começar

Se você estiver reimplantando a solução, pule esta seção (por exemplo, após novos commits).

Nesta seção, você cria recursos únicos.

1. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

2. Se você quiser criar um novo projeto do Google Cloud para usar como projeto de host para a implantação, use o comando gcloud projects create:

      gcloud projects create PROJECT_ID
   

   Substitua PROJECT_ID pelo ID do projeto que você quer criar.

3. Instale o Maven:

   1. Faça o download do Maven.

   2. No Cloud Shell, adicione o Maven a PATH:

      export PATH=/DOWNLOADED_MAVEN_DIR/bin:$PATH
      

4. No Cloud Shell, clone o repositório do GitHub.

   git clone https://github.com/GoogleCloudPlatform/bq-backup-manager.git
   

5. Defina e exporte as seguintes variáveis de ambiente:

   export PROJECT_ID=PROJECT_ID
   export TF_SA=bq-backup-mgr-terraform
   export COMPUTE_REGION=COMPUTE_REGION
   export DATA_REGION=DATA_REGION
   export BUCKET_NAME=${PROJECT_ID}-bq-backup-mgr
   export BUCKET=gs://${BUCKET_NAME}
   export DOCKER_REPO_NAME=docker-repo
   export CONFIG=bq-backup-manager
   export ACCOUNT=ACCOUNT_EMAIL
   
   gcloud config configurations create $CONFIG
   gcloud config set project $PROJECT_ID
   gcloud config set account $ACCOUNT
   gcloud config set compute/region $COMPUTE_REGION
   
   gcloud auth login
   gcloud auth application-default login
   

   Substitua:

   • PROJECT_ID: o ID do projeto host do Google Cloud em que você quer implantar a solução.
   • COMPUTE_REGION: a região do Google Cloud em que você quer implantar recursos de computação, como o Cloud Run e o Identity and Access Management (IAM).
   • DATA_REGION: a região do Google Cloud em que você quer implantar recursos de dados (como buckets e conjuntos de dados).
   • ACCOUNT_EMAIL: o endereço de e-mail da conta do usuário.

6. Ative as APIs:

   ./scripts/enable_gcp_apis.sh
   

   O script ativa as seguintes APIs:

   • API Cloud Resource Manager
   • API IAM
   • API Data Catalog
   • API Artifact Registry
   • API BigQuery
   • API Pub/Sub
   • API Cloud Storage
   • API Cloud Run Admin
   • API Cloud Build
   • API Service Usage
   • API App Engine Admin
   • API de acesso VPC sem servidor
   • API Cloud DNS

7. Prepare o bucket de estado do Terraform:

   gsutil mb -p $PROJECT_ID -l $COMPUTE_REGION -b on $BUCKET
   

8. Prepare a conta de serviço do Terraform:

   ./scripts/prepare_terraform_service_account.sh
   

9. Para publicar as imagens usadas por essa solução, prepare um repositório do Docker:

   gcloud artifacts repositories create $DOCKER_REPO_NAME
     --repository-format=docker \
     --location=$COMPUTE_REGION \
     --description="Docker repository for backups"
   

Implante a infraestrutura

Verifique se você concluiu a seção Antes de começar pelo menos uma vez.

Nesta seção, siga as etapas para implantar ou reimplantar a base de código mais recente no ambiente do Google Cloud.

Ativar a configuração da CLI gcloud

• No Cloud Shell, ative e autentique a configuração da CLI do gcloud:

  gcloud config configurations activate $CONFIG
  
  gcloud auth login
  gcloud auth application-default login
  

Criar imagens de serviços do Cloud Run

• No Cloud Shell, crie e implante imagens do Docker para serem usadas pelo serviço do Cloud Run:

  export DISPATCHER_IMAGE=${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-dispatcher-service:latest
  export CONFIGURATOR_IMAGE=${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-configurator-service:latest
  export SNAPSHOTER_BQ_IMAGE=${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-snapshoter-bq-service:latest
  export SNAPSHOTER_GCS_IMAGE=${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-snapshoter-gcs-service:latest
  export TAGGER_IMAGE=${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-tagger-service:latest
  
  ./scripts/deploy_services.sh
  

Configurar variáveis do Terraform

Esta implantação usa o Terraform para configurações e um script de implantação.

1. No Cloud Shell, crie um novo arquivo TFVARS do Terraform em que você possa substituir as variáveis nesta seção:

   export VARS=FILENAME
   .tfvars
   

   Substitua FILENAME pelo nome do arquivo de variáveis que você criou (por exemplo, my-variables). Use o arquivo example-variables como referência.

2. No arquivo TFVARS, configure as variáveis do projeto:

   project = "PROJECT_ID"
   compute_region = "COMPUTE_REGION"
   data_region = "DATA_REGION"
   

   É possível usar os valores padrão definidos no arquivo variables.tf ou mudar os valores.

3. Configure a conta de serviço do Terraform, que você criou e preparou anteriormente em Antes de começar:

   terraform_service_account =
   "bq-backup-mgr-terraform@PROJECT_ID.iam.gserviceaccount.com"
   

   Use o endereço de e-mail completo da conta que você criou.

4. Configure os serviços do Cloud Run para usar as imagens de contêiner que você criou e implantou anteriormente:

   dispatcher_service_image     = "${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-dispatcher-service:latest"
   configurator_service_image   = "${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-configurator-service:latest"
   snapshoter_bq_service_image  = "${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-snapshoter-bq-service:latest"
   snapshoter_gcs_service_image = "${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-snapshoter-gcs-service:latest"
   tagger_service_image         = "${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-tagger-service:latest"
   

   Esse script instrui o Terraform a usar essas imagens publicadas nos serviços do Cloud Run, que o Terraform cria mais tarde.

   O Terraform vincula um serviço do Cloud Run apenas a uma imagem existente. Ele não cria as imagens da base de código, porque isso foi concluído em uma etapa anterior.

5. Na variável schedulers, defina pelo menos um programador. O agendador lista e verifica periodicamente as tabelas para backups necessários com base nos agendamentos de backup de cron no nível da tabela.

   {
   name    = "SCHEDULER_NAME"
   cron    = "SCHEDULER_CRON"
   payload = {
       is_force_run = FORCE_RUN
       is_dry_run   = DRY_RUN
   
       folders_include_list  = [FOLDERS_INCLUDED]
       projects_include_list = [PROJECTS_INCLUDED]
       projects_exclude_list = [PROJECTS_EXCLUDED]
       datasets_include_list =  [DATASETS_INCLUDED]
       datasets_exclude_list =  [DATASETS_EXCLUDED]
       tables_include_list   =  [TABLES_INCLUDED]
       tables_exclude_list   =  [TABLES_EXCLUDED]
       }
   }
   

   Substitua:

   • SCHEDULER_NAME: o nome de exibição do Cloud Scheduler.
   • SCHEDULER_CRON: a frequência com que o programador verifica se um backup é necessário para as tabelas no escopo com base nas programações de backup individuais. Ela pode ser qualquer string compatível com o unix-cron. Por exemplo, 0 * * * * é uma frequência de uma hora.
   • FORCE_RUN: um valor booleano Defina o valor como false se quiser que o programador use as programações cron das tabelas. Se definido como true, todos os backups de tabelas no escopo são feitos, independentemente da configuração do cron.
   • DRY_RUN: um valor booleano Quando definido como true, nenhuma operação de backup real é realizada. Somente mensagens de registro são geradas. Use true quando quiser testar e depurar a solução sem incorrer em custos de backup.
   • FOLDERS_INCLUDED: uma lista de IDs numéricos para pastas que contêm dados do BigQuery (por exemplo, 1234, 456). Quando definido, a solução faz backup das tabelas nas pastas especificadas e ignora as configurações de campo projects_include_list, datasets_include_list e tables_include_list.
   • PROJECTS_INCLUDED: uma lista de nomes de projetos (por exemplo, "project1", "project2"). Quando definido, a solução faz backup das tabelas nos projetos especificados e ignora as configurações de campo datasets_include_list e tables_include_list. Essa configuração será ignorada se você definir o campo folders_include_list.
   • PROJECTS_EXCLUDED: uma lista de nomes de projetos ou expressões regulares (por exemplo, "project1", "regex:^test_"). Quando definido, a solução não faz backups das tabelas nos projetos especificados. É possível usar essa configuração em combinação com o campo folders_include_list.
   • DATASETS_INCLUDED: uma lista de conjuntos de dados (por exemplo, "project1.dataset1", "project1.dataset2"). Quando definido, a solução faz backup das tabelas nos conjuntos de dados especificados e ignora a configuração do campo tables_include_list. Essa configuração será ignorada se você definir os campos folders_include_list ou projects_include_list.
   • DATASETS_EXCLUDED: uma lista de conjuntos de dados ou expressões regulares (por exemplo, "project1.dataset1", "regex:.*\\_landing$"). Quando definido, a solução não faz backups das tabelas nos conjuntos de dados especificados. É possível usar essa configuração em combinação com os campos folders_include_list ou projects_include_list.
   • TABLES_INCLUDED: uma lista de tabelas (por exemplo, "project1.dataset1.table 1", "project1.dataset2.table2"). Quando definido, a solução faz backup das tabelas especificadas. Essa configuração será ignorada se você definir os campos folders_include_list, projects_include_list ou datasets_include_list.
   • TABLES_EXCLUDED: uma lista de tabelas ou expressões regulares (por exemplo, "project1.dataset1.table 1", "regex:.*\_test"). Quando definido, a solução não faz backups das tabelas especificadas. É possível usar essa configuração em combinação com os campos folders_include_list, projects_include_list ou datasets_include_list.

   Todas as listas de exclusão aceitam expressões regulares no formato regex:REGULAR_EXPRESSION.

   Se o nome da entrada totalmente qualificado (por exemplo, "project.dataset.table") corresponder a qualquer uma das expressões regulares fornecidas, ele será excluído do escopo do backup.

   Veja alguns casos de uso comuns:

   • Excluir todos os nomes de conjuntos de dados que terminam com _landing: datasets_exclude_list = ["regex:.*\\_landing$"]
   • Excluir todas as tabelas que terminam com _test, _tst, _bkp ou _copy: tables_exclude_list = ["regex:.*\_(test|tst|bkp|copy)"]

Definir políticas de fallback

Em cada execução, a solução precisa determinar a política de backup de cada tabela no escopo. Para mais informações sobre os tipos de políticas, consulte Políticas de backup. Esta seção mostra como definir uma política de substituição.

Uma política de fallback é definida com uma variável default_policy e um conjunto de exceções ou substituições em diferentes níveis (pasta, projeto, conjunto de dados e tabela). Essa abordagem oferece flexibilidade granular sem a necessidade de uma entrada para cada tabela.

Há outros conjuntos de campos de política, dependendo do método de backup que você decidir usar: snapshots do BigQuery, exportações para o Cloud Storage ou ambos.

1. No arquivo TFVARS, para a variável default_policy, defina os seguintes campos comuns para a política padrão:

   fallback_policy = {
     "default_policy" : {
       "backup_cron" : "BACKUP_CRON"
       "backup_method" : "BACKUP_METHOD",
       "backup_time_travel_offset_days" : "OFFSET_DAYS",
       "backup_storage_project" : "BACKUP_STORAGE_PROJECT",
       "backup_operation_project" : "BACKUP_OPERATIONS_PROJECT",
   
   

   Substitua:

   • BACKUP_CRON: uma expressão cron para definir a frequência com que uma tabela é salva (por exemplo, para backups a cada 6 horas, especifique 0 0 */6 * * *). Essa precisa ser uma expressão cron compatível com o Spring-Framework.
   • BACKUP_METHOD: o método, especificado como BigQuery Snapshot, GCS Snapshot (para usar o método de exportação para o Cloud Storage) ou Both. Você precisa fornecer os campos obrigatórios para cada método de backup escolhido, conforme mostrado mais adiante.
   • OFFSET_DAYS: o número de dias no passado que determina o ponto no tempo em que fazer o backup das tabelas. Os valores podem ser um número entre 0 e 7.
   • BACKUP_STORAGE_PROJECT: o ID do projeto em que todas as operações de snapshot e exportação são armazenadas. Esse é o mesmo projeto em que bq_snapshot_storage_dataset e gcs_snapshot_storage_location estão. Implantações pequenas podem usar o projeto host, mas implantações em grande escala precisam usar um projeto separado.
   • BACKUP_OPERATIONS_PROJECT: uma configuração opcional em que você especifica o ID do projeto em que todas as operações de snapshot e exportação são executadas. As cotas e limites de jobs de snapshot e exportação se aplicam a este projeto. Pode ser o mesmo que backup_storage_project. Se não for definido, a solução vai usar o projeto da tabela de origem.

2. Se você especificou BigQuery Snapshot ou Both como o backup_method, adicione os campos a seguir depois dos campos comuns, na variável default_policy:

     "bq_snapshot_expiration_days" : "SNAPSHOT_EXPIRATION",
     "bq_snapshot_storage_dataset" : "DATASET_NAME",
   

   Substitua:

   • SNAPSHOT_EXPIRATION: o número de dias para manter cada snapshot (por exemplo, 15).
   • DATASET_NAME: o nome do conjunto de dados em que os snapshots serão armazenados (por exemplo, backups). O conjunto de dados já precisa existir no projeto especificado para backup_storage_project.

3. Se você especificou GCS Snapshot (para usar o método de exportação para o Cloud Storage) ou Both como backup_method, adicione os campos a seguir à variável default_policy:

     "gcs_snapshot_storage_location" : "STORAGE_BUCKET",
     "gcs_snapshot_format" : "FILE_FORMAT",
     "gcs_avro_use_logical_types" : AVRO_TYPE,
     "gcs_csv_delimiter" : "CSV_DELIMITER",
     "gcs_csv_export_header" : CSV_EXPORT_HEADER
   

   Substitua:

   • STORAGE_BUCKET: o bucket do Cloud Storage em que armazenar os dados exportados, no formato gs://bucket/path/. Por exemplo, gs://bucket1/backups/.
   • FILE_FORMAT: o formato e a compactação de arquivo usados para exportar uma tabela do BigQuery para o Cloud Storage. Os valores disponíveis são CSV, CSV_GZIP, JSON, JSON_GZIP, AVRO, AVRO_DEFLATE, AVRO_SNAPPY, PARQUET, PARQUET_SNAPPY e PARQUET_GZIP.
   • AVRO_TYPE: um valor booleano Se definido como false, os tipos do BigQuery são exportados como strings. Se definido como true, os tipos são exportados como o tipo lógico Avro correspondente. Este campo é obrigatório quando o gcs_snapshot_format é qualquer formato de tipo Avro.
   • CSV_DELIMITER: o delimitador usado para os arquivos CSV exportados, e o valor pode ser qualquer caractere ISO-8859-1 de um byte. É possível usar \t ou tab para especificar delimitadores de tabulação. Este campo é obrigatório quando o gcs_snapshot_format é qualquer formato do tipo CSV.
   • CSV_EXPORT_HEADER: um valor booleano Se definido como true, os cabeçalhos de coluna são exportados para os arquivos CSV. Este campo é obrigatório quando o gcs_snapshot_format é qualquer formato do tipo CSV.

   Para detalhes e mapeamento de tipo Avro, consulte a tabela a seguir:

   Tipo do BigQuery	Tipo lógico Avro
   TIMESTAMP	timestamp-micros (anota LONG do Avro)
   DATE	date (anota o INT do Avro)
   TIME	timestamp-micro (anota o LONG do Avro)
   DATETIME	STRING (tipo lógico com nome personalizado datetime)

4. Adicione variáveis de substituição para pastas, projetos, conjuntos de dados e tabelas específicas:

     },
     "folder_overrides" : {
      "FOLDER_NUMBER" : {
      },
     },
   
     "project_overrides" : {
      "PROJECT_NAME" : {
      }
     },
   
     "dataset_overrides" : {
      "PROJECT_NAME.DATASET_NAME" : {
      }
     },
   
     "table_overrides" : {
      "PROJECT_NAME.DATASET_NAME.TABLE_NAME" : {
      }
     }
   }
   

   Substitua:

   • FOLDER_NUMBER: especifica a pasta para a qual você quer definir os campos de substituição.
   • PROJECT_NAME: especifica o projeto quando você define campos de substituição para um projeto, conjunto de dados ou tabela específico.
   • DATASET_NAME: especifica o conjunto de dados quando você define campos de substituição para um conjunto de dados ou uma tabela específica.
   • TABLE_NAME: especifica a tabela para a qual você quer definir os campos de substituição.

   Para cada entrada de substituição, como um projeto específico na variável project_overrides, adicione os campos comuns e os obrigatórios para o método de backup especificado anteriormente em default_policy.

   Se você não quiser definir substituições para um nível específico, defina essa variável como um mapa vazio (por exemplo, project_overrides : {}).

   No exemplo abaixo, os campos de substituição são definidos para uma tabela específica que usa o método de snapshot do BigQuery:

     },
     "project_overrides" : {},
   
     "table_overrides" : {
      "example_project1.dataset1.table1" : {
       "backup_cron" : "0 0 */5 * * *", # every 5 hours each day
       "backup_method" : "BigQuery Snapshot",
       "backup_time_travel_offset_days" : "7",
       "backup_storage_project" : "project name",
       "backup_operation_project" : "project name",
       # bq settings
       "bq_snapshot_expiration_days" : "14",
       "bq_snapshot_storage_dataset" : "backups2"
       },
      }
   }
   

Para conferir um exemplo completo de uma política de fallback, consulte o arquivo example-variables.

Configurar outros projetos de operação de backup

• Se você quiser especificar outros projetos de backup, como aqueles definidos em configurações externas (política de backup no nível da tabela) ou os projetos de origem da tabela, configure a seguinte variável:

  additional_backup_operation_projects = [ADDITIONAL_BACKUPS]
  

  Substitua ADDITIONAL_BACKUPS por uma lista separada por vírgulas de nomes de projetos (por exemplo, "project1", "project2"). Se você estiver usando apenas a política de backup padrão sem políticas externas no nível da tabela, poderá definir o valor como uma lista vazia.

  Se você não adicionar esse campo, todos os projetos especificados no campo opcional backup_operation_project serão incluídos automaticamente como projetos de backup.

Configurar permissões da conta de serviço do Terraform

Nas etapas anteriores, você configurou os projetos de backup em que as operações de backup são executadas. O Terraform precisa implantar recursos nesses projetos de backup.

A conta de serviço usada pelo Terraform precisa ter as permissões necessárias para esses projetos de backup especificados.

• No Cloud Shell, conceda as permissões da conta de serviço para todos os projetos em que as operações de backup são executadas:

  ./scripts/prepare_backup_operation_projects_for_terraform.sh BACKUP_OPERATIONS_PROJECT DATA_PROJECTS ADDITIONAL_BACKUPS
  

  Substitua:

  • BACKUP_OPERATIONS_PROJECT: todos os projetos definidos nos campos backup_operation_project em qualquer uma das políticas padrão e das políticas no nível da tabela.
  • DATA_PROJECTS: se nenhum campo backup_operation_project for definido em uma política de fallback ou de nível de tabela, inclua os projetos para essas tabelas de origem.
  • ADDITIONAL_BACKUPS: todos os projetos definidos na variável additional_backup_operation_projects do Terraform.

Executar os scripts de implantação

1. No Cloud Shell, execute o script de implantação do Terraform:

   cd terraform
   
   terraform init \
       -backend-config="bucket=${BUCKET_NAME}" \
       -backend-config="prefix=terraform-state" \
       -backend-config="impersonate_service_account=$TF_SA@$PROJECT_ID.iam.gserviceaccount.com"
   
   terraform plan -var-file=$VARS
   
   terraform apply -var-file=$VARS
   

2. Adicione as políticas de time to live (TTL) para o Firestore:

   
   gcloud firestore fields ttls update expires_at \
       --collection-group=project_folder_cache \
       --enable-ttl \
       --async \
       --project=$PROJECT_ID
   

   A solução usa o Datastore como um cache em algumas situações. Para economizar custos e melhorar a performance da pesquisa, a política de TTL permite que o Firestore exclua automaticamente as entradas expiradas.

Configurar o acesso a origens e destinos

1. No Cloud Shell, defina as seguintes variáveis para as contas de serviço usadas pela solução:

   export SA_DISPATCHER_EMAIL=dispatcher@${PROJECT_ID}.iam.gserviceaccount.com
   export SA_CONFIGURATOR_EMAIL=configurator@${PROJECT_ID}.iam.gserviceaccount.com
   export SA_SNAPSHOTER_BQ_EMAIL=snapshoter-bq@${PROJECT_ID}.iam.gserviceaccount.com
   export SA_SNAPSHOTER_GCS_EMAIL=snapshoter-gcs@${PROJECT_ID}.iam.gserviceaccount.com
   export SA_TAGGER_EMAIL=tagger@${PROJECT_ID}.iam.gserviceaccount.com
   

   Se você tiver mudado os nomes padrão no Terraform, atualize os e-mails da conta de serviço.

2. Se você tiver definido o campo folders_include_list e quiser definir o escopo da verificação do BigQuery para incluir determinadas pastas, conceda as permissões necessárias no nível da pasta:

   ./scripts/prepare_data_folders.sh FOLDERS_INCLUDED
   

3. Para permitir que o aplicativo execute as tarefas necessárias em diferentes projetos, conceda as permissões necessárias em cada um deles:

   ./scripts/prepare_data_projects.sh DATA_PROJECTS
   ./scripts/prepare_backup_storage_projects.sh BACKUP_STORAGE_PROJECT
   ./scripts/prepare_backup_operation_projects.sh BACKUP_OPERATIONS_PROJECT
   

   Substitua:

   • DATA_PROJECTS: os projetos de dados (ou projetos de origem) que contêm as tabelas de origem que você quer fazer backup (por exemplo, project1 project2). Inclua os seguintes projetos:

     • Projetos especificados nas listas de inclusão na variável schedulers do Terraform.
     • Se você quiser fazer backup de tabelas no projeto host, inclua o projeto host.

   • BACKUP_STORAGE_PROJECT: os projetos de armazenamento de backup (ou projetos de destino) em que a solução armazena os backups (por exemplo, project1 project2). É necessário incluir os projetos especificados nos seguintes campos:

     • Os campos backup_storage_project em todas as políticas de fallback.
     • Os campos backup_storage_project em todas as políticas no nível da tabela.

     Incluir projetos de armazenamento de backup usados em vários campos ou que são usados como projeto de origem e destino

   • BACKUP_OPERATIONS_PROJECT: os projetos de operação de dados em que a solução executa as operações de backup (por exemplo, project1 project2). É necessário incluir os projetos especificados nos seguintes campos:

     • Os campos backup_operation_project em todas as políticas de fallback.
     • Todas as listas de inclusão no escopo da verificação do BigQuery (se você não definir o campo backup_operation_project).
     • Os campos backup_operation_project em todas as políticas no nível da tabela.

     Inclua projetos de operações de backup usados em vários campos ou como projeto de origem e de destino.

4. Para tabelas que usam o controle de acesso no nível da coluna, identifique todas as taxonomias de tags de política usadas pelas tabelas (se houver) e conceda às contas de serviço da solução acesso aos dados da tabela:

   TAXONOMY="projects/TAXONOMY_PROJECT/locations/TAXONOMY_LOCATION/taxonomies/TAXONOMY_ID"
   
   gcloud data-catalog taxonomies add-iam-policy-binding \
   $TAXONOMY \
   --member="serviceAccount:${SA_SNAPSHOTER_BQ_EMAIL}" \
   --role='roles/datacatalog.categoryFineGrainedReader'
   
   gcloud data-catalog taxonomies add-iam-policy-binding \
   $TAXONOMY \
   --member="serviceAccount:${SA_SNAPSHOTER_GCS_EMAIL}" \
   --role='roles/datacatalog.categoryFineGrainedReader'
   

   Substitua:

   • TAXONOMY_PROJECT: o ID do projeto na taxonomia de tags de políticas
   • TAXONOMY_LOCATION: o local especificado na taxonomia de tags da política
   • TAXONOMY_ID: o ID da taxonomia de tags da política

5. Repita a etapa anterior para cada taxonomia de tag de política.

Executar a solução

Depois de implantar a solução, use as seções a seguir para executar e gerenciar a solução.

Definir políticas de backup no nível da tabela

• No Cloud Shell, crie uma política no nível da tabela com os campos necessários e armazene-a no bucket do Cloud Storage para políticas:

  # Use the default backup policies bucket unless overwritten in the .tfvars
  export POLICIES_BUCKET=${PROJECT_ID}-bq-backup-manager-policies
  
  # set target table info
  export TABLE_PROJECT='TABLE_PROJECT'
  export TABLE_DATASET='TABLE_DATASET'
  export TABLE='TABLE_NAME'
  
  # Config Source must be 'MANUAL' when assigned this way
  export BACKUP_POLICY="{
  'config_source' : 'MANUAL',
  'backup_cron' : 'BACKUP_CRON',
  'backup_method' : 'BACKUP_METHOD',
  'backup_time_travel_offset_days' : 'OFFSET_DAYS',
  'backup_storage_project' : 'BACKUP_STORAGE_PROJECT',
  'backup_operation_project' : 'BACKUP_OPERATION_PROJECT',
  'gcs_snapshot_storage_location' : 'STORAGE_BUCKET',
  'gcs_snapshot_format' : 'FILE_FORMAT',
  'gcs_avro_use_logical_types' : 'AVRO_TYPE',
  'bq_snapshot_storage_dataset' : 'DATASET_NAME',
  'bq_snapshot_expiration_days' : 'SNAPSHOT_EXPIRATION'
  }"
  
  # File name MUST BE backup_policy.json
  echo $BACKUP_POLICY >> backup_policy.json
  
  gsutil cp backup_policy.json gs://${POLICIES_BUCKET}/policy/project=${TABLE_PROJECT}/dataset=${TABLE_DATASET}/table=${TABLE}/backup_policy.json
  

  Substitua:

  • TABLE_PROJECT: o projeto em que a tabela está
  • TABLE_DATASET: o conjunto de dados da tabela
  • TABLE_NAME: o nome da tabela

Acionar operações de backup

Os jobs do Cloud Scheduler que você configurou anteriormente são executados automaticamente com base na expressão cron.

Também é possível executar os jobs manualmente no console do Google Cloud. Para mais informações, consulte Executar seu job.

Monitorar e relatar

Com o projeto de host (PROJECT_ID) selecionado, você pode executar as consultas a seguir no BigQuery Studio para receber relatórios e informações.

• Conferir as estatísticas de progresso de cada corrida (incluindo as em andamento):

  SELECT * FROM `bq_backup_manager.v_run_summary_counts`
  

• Receba todos os erros fatais (não revogáveis) de uma única execução:

  SELECT * FROM `bq_backup_manager.v_errors_non_retryable`
  WHERE run_id = 'RUN_ID'
  

  Substitua RUN_ID pelo ID da execução.

• Receber todas as execuções em uma tabela e as informações de execução:

  SELECT * FROM `bq_backup_manager.v_errors_non_retryable`
  WHERE tablespec = 'project.dataset.table'
  

  Também é possível especificar uma versão grouped:

  SELECT * FROM `bq_backup_manager.v_audit_log_by_table_grouped`, UNNEST(runs) r
  WHERE r.run_has_retryable_error = FALSE
  

• Para depuração, é possível receber informações detalhadas de solicitação e resposta para cada invocação de serviço:

  SELECT
  jsonPayload.unified_target_table AS tablespec,
  jsonPayload.unified_run_id AS run_id,
  jsonPayload.unified_tracking_id AS tracking_id,
  CAST(jsonPayload.unified_is_successful AS BOOL) AS configurator_is_successful,
  jsonPayload.unified_error AS configurator_error,
  CAST(jsonPayload.unified_is_retryable_error AS BOOL) AS configurator_is_retryable_error,
  CAST(JSON_VALUE(jsonPayload.unified_input_json, '$.isForceRun') AS BOOL) AS is_force_run,
  CAST(JSON_VALUE(jsonPayload.unified_output_json, '$.isBackupTime') AS BOOL) AS is_backup_time,
  JSON_VALUE(jsonPayload.unified_output_json, '$.backupPolicy.method') AS backup_method,
  CAST(JSON_VALUE(jsonPayload.unified_input_json, '$.isDryRun') AS BOOL) AS is_dry_run,
  jsonPayload.unified_input_json AS request_json,
  jsonPayload.unified_output_json AS response_json
  FROM `bq_backup_manager.run_googleapis_com_stdout`
  WHERE jsonPayload.global_app_log = 'UNIFIED_LOG'
  -- 1= dispatcher, 2= configurator, 3=bq snapshoter, -3=gcs snapshoter and 4=tagger
  AND jsonPayload.unified_component = "2"
  

• Receba as políticas de backup que são adicionadas ou atribuídas manualmente pelo sistema com base em substitutos:

  SELECT * FROM `bq_backup_manager.ext_backup_policies`
  

Limitações

Para mais informações sobre limites e cotas de cada projeto especificado nos campos backup_operation_project, consulte Limites.

Limpar

Para evitar cobranças na sua conta do Google Cloud pelos recursos usados na implantação, exclua os projetos que contenham os recursos ou mantenha os projetos e exclua cada um dos recursos.

Excluir os projetos

Cuidado: excluir um projeto tem os seguintes efeitos:

• Tudo no projeto é excluído. Se você tiver usado um projeto existente para as tarefas neste documento, a exclusão dele incluirá a exclusão de quaisquer outros trabalhos feitos no projeto.
• Os IDs do projeto personalizados são perdidos. Ao criar o projeto, você pode ter criado um código do projeto personalizado para ser usado no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, exclua recursos específicos do projeto, em vez de excluir o projeto inteiro.

Se você planeja passar por várias arquiteturas, tutoriais ou guias de início rápido, a reutilização de projetos pode evitar que você exceda os limites da cota do projeto.

1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

Excluir os novos recursos

Como alternativa à exclusão dos projetos, é possível excluir os recursos criados durante esse procedimento.

• No Cloud Shell, exclua os recursos Terraform:

  terraform destroy -var-file="${VARS}"
  

  O comando exclui quase todos os recursos. Verifique se todos os recursos que você quer excluir foram removidos.

A seguir

• Saiba mais sobre o BigQuery:
  • Snapshots de tabelas do BigQuery
  • Exportações de tabelas do BigQuery para o Cloud Storage
• Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.

Colaboradores

Autor: Karim Wadie | Engenheiro estratégico do Cloud

Outros colaboradores:

• Chris DeForeest | Engenheiro de confiabilidade do site
• Eyal Ben Ivri | Arquiteto de soluções em nuvem
• Jason Davenport | Mediador de desenvolvedores
• Jaliya Ekanayake | Gerente de engenharia
• Muhammad Zain | Engenheiro estratégico do Cloud