Implemente a automatização de cópias de segurança do BigQuery escalável

Este documento descreve como implementar a automatização de cópias de segurança do BigQuery escalável.

Este documento destina-se a arquitetos, engenheiros e responsáveis de governação de dados na nuvem que pretendem definir e automatizar políticas de dados nas respetivas organizações. A experiência com o Terraform é útil.

Arquitetura

O diagrama seguinte mostra a arquitetura de cópia de segurança automática:

O Cloud Scheduler aciona a execução. O serviço de expedição, através da API BigQuery, apresenta as tabelas no âmbito. Através de uma mensagem do Pub/Sub, o serviço de expedição envia um pedido para cada tabela ao serviço de configuração. O serviço de configuração determina as políticas de cópia de segurança das tabelas e, em seguida, envia um pedido para cada tabela ao serviço do Cloud Run relevante. Em seguida, o serviço do Cloud Run envia um pedido à API BigQuery e executa as operações de cópia de segurança. O Pub/Sub aciona o serviço de etiquetagem, que regista os resultados e atualiza o estado da cópia de segurança na camada de metadados do Cloud Storage.

Para detalhes sobre a arquitetura, consulte o artigo Automatização de cópias de segurança do BigQuery escalável.

Objetivos

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

Custos

Neste documento, usa 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 custos com base na sua utilização projetada, use a calculadora de preços.

Os novos Google Cloud utilizadores podem ser elegíveis para uma avaliação gratuita.

Quando terminar as tarefas descritas neste documento, pode evitar a faturação contínua eliminando os recursos que criou. Para mais informações, consulte Limpar.

Antes de começar

Se estiver a voltar a implementar a solução, pode ignorar esta secção (por exemplo, após novos commits).

Nesta secção, cria recursos únicos.

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

   Activate Cloud Shell

2. Se quiser criar um novo Google Cloud projeto para usar como projeto anfitrião para a implementação, use o comando gcloud projects create:

      gcloud projects create PROJECT_ID
   

   Substitua PROJECT_ID pelo ID do projeto que quer criar.

3. Instale o Maven:

   1. Transfira o 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 o seguinte:

   • PROJECT_ID: o ID do Google Cloud projeto anfitrião no qual quer implementar a solução.
   • COMPUTE_REGION: a Google Cloud região onde quer implementar recursos de computação, como o Cloud Run e o Identity and Access Management (IAM).
   • DATA_REGION: a Google Cloud região na qual quer implementar recursos de dados (como contentores e conjuntos de dados).
   • ACCOUNT_EMAIL: o endereço de email da conta de utilizador.

6. Ative as APIs:

   ./scripts/enable_gcp_apis.sh
   

   O script ativa as seguintes APIs:

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

7. Prepare o contentor de estado do Terraform:

   gcloud storage buckets create $BUCKET --project=$PROJECT_ID --location=$COMPUTE_REGION --uniform-bucket-level-access
   

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

   ./scripts/prepare_terraform_service_account.sh
   

9. Para publicar imagens que esta solução usa, prepare um repositório Docker:

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

Implemente a infraestrutura

Certifique-se de que concluiu a secção Antes de começar, pelo menos, uma vez.

Nesta secção, siga os passos para implementar ou reimplementar a base de código mais recente no ambiente Google Cloud .

Ative a configuração da CLI gcloud

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

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

Crie imagens de serviços do Cloud Run

• No Cloud Shell, crie e implemente imagens Docker a serem usadas pelo serviço 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
  

Configure variáveis do Terraform

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

1. No Cloud Shell, crie um novo ficheiro TFVARS do Terraform no qual pode substituir as variáveis nesta secção:

   export VARS=FILENAME
   .tfvars
   

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

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

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

   Pode usar os valores predefinidos definidos no ficheiro variables.tf ou alterar os valores.

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

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

   Certifique-se de que usa o endereço de email completo da conta que criou.

4. Configure os serviços do Cloud Run para usar as imagens de contentores que criou e implementou 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"
   

   Este script indica ao Terraform que use estas imagens publicadas nos serviços do Cloud Run, que o Terraform cria mais tarde.

   O Terraform associa apenas um serviço do Cloud Run a uma imagem existente. Não cria as imagens a partir da base de código, porque essa ação foi concluída num passo anterior.

5. Na variável schedulers, defina, pelo menos, um agendador. O agendador lista e verifica periodicamente as tabelas para as cópias de segurança necessárias, com base nos respetivos agendamentos cronológicos de cópias de segurança ao 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 o seguinte:

   • SCHEDULER_NAME: o nome a apresentar do Cloud Scheduler.
   • SCHEDULER_CRON: a frequência com que o agendador verifica se é necessário fazer uma cópia de segurança das tabelas no âmbito, com base nas respetivas agendas de cópias de segurança individuais. Pode ser qualquer string compatível com unix-cron. Por exemplo, 0 * * * * é uma frequência por hora.
   • FORCE_RUN: um valor booleano. Defina o valor como false se quiser que o agendador use as programações cron das tabelas. Se estiver definido como true, é feito uma cópia de segurança de todas as tabelas no âmbito, independentemente da respetiva definição de cron.
   • DRY_RUN: um valor booleano. Quando está definido como true, não são realizadas operações de cópia de segurança reais. Apenas são geradas mensagens de registo. Use true quando quiser testar e depurar a solução sem incorrer em custos de cópia de segurança.
   • 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 uma cópia de segurança das tabelas nas pastas especificadas e ignora as definições dos campos 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 uma cópia de segurança das tabelas nos projetos especificados e ignora as definições dos campos datasets_include_list e tables_include_list. Esta definição é ignorada se definir o campo folders_include_list.
   • PROJECTS_EXCLUDED: uma lista de nomes de projetos ou uma expressão regular (por exemplo, "project1", "regex:^test_"). Quando definido, a solução não faz cópias de segurança das tabelas nos projetos especificados. Pode usar esta definiçã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 uma cópia de segurança das tabelas nos conjuntos de dados especificados e ignora a definição do campo tables_include_list. Esta definição é ignorada se definir os campos folders_include_list ou projects_include_list.
   • DATASETS_EXCLUDED: uma lista de conjuntos de dados ou uma expressão regular (por exemplo, "project1.dataset1", "regex:.*\\_landing$"). Quando definido, a solução não faz cópias de segurança das tabelas nos conjuntos de dados especificados. Pode usar esta definiçã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 definida, a solução faz uma cópia de segurança das tabelas especificadas. Esta definição é ignorada se definir os campos folders_include_list, projects_include_list ou datasets_include_list.
   • TABLES_EXCLUDED: uma lista de tabelas ou uma expressão regular (por exemplo, "project1.dataset1.table 1", "regex:.*\_test"). Quando definido, a solução não faz cópias de segurança das tabelas especificadas. Pode usar esta definição em combinação com os campos folders_include_list, projects_include_list ou datasets_include_list.

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

   Se o nome de entrada totalmente qualificado (por exemplo, "project.dataset.table") corresponder a qualquer uma das expressões regulares fornecidas, é excluído do âmbito da cópia de segurança.

   Seguem-se alguns exemplos de utilização comuns:

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

Defina políticas alternativas

Em cada execução, a solução tem de determinar a política de cópia de segurança de cada tabela no âmbito. Para mais informações sobre os tipos de políticas, consulte as Políticas de cópia de segurança. Esta secção mostra como definir uma política alternativa.

Uma política alternativa é 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). Esta abordagem oferece flexibilidade detalhada sem a necessidade de uma entrada para cada tabela.

Existem conjuntos adicionais de campos de políticas, consoante o método de cópia de segurança que decidir usar: instantâneos do BigQuery, exportações para o Cloud Storage ou ambos.

1. No ficheiro TFVARS, para a variável default_policy, defina os seguintes campos comuns para a política predefinida:

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

   • BACKUP_CRON: uma expressão cron para definir a frequência com que é feito uma cópia de segurança de uma tabela (por exemplo, para cópias de segurança a cada 6 horas, especifique 0 0 */6 * * *). Tem de ser uma expressão cron compatível com o Spring-Framework.
   • BACKUP_METHOD: o método, que especifica como BigQuery Snapshot, GCS Snapshot (para usar o método de exportação para o Cloud Storage) ou Both. Tem de fornecer os campos obrigatórios para cada método alternativo escolhido, conforme mostrado mais tarde.
   • OFFSET_DAYS: o número de dias no passado que determina o ponto no tempo a partir do qual fazer uma cópia de segurança das tabelas. Os valores podem ser um número entre 0 e 7.
   • BACKUP_STORAGE_PROJECT: o ID do projeto onde todas as operações de instantâneo e exportação são armazenadas. Este é o mesmo projeto onde residem o bq_snapshot_storage_dataset e o gcs_snapshot_storage_location. As implementações pequenas podem usar o projeto de anfitrião, mas as implementações em grande escala devem usar um projeto separado.
   • BACKUP_OPERATIONS_PROJECT: uma definição opcional, onde especifica o ID do projeto onde todas as operações de instantâneo e exportação são executadas. As quotas e os limites dos trabalhos de instantâneo e exportação aplicam-se a este projeto. Pode ter o mesmo valor que backup_storage_project. Se não for definido, a solução usa o projeto da tabela de origem.

2. Se especificou BigQuery Snapshot ou Both como o backup_method, adicione os seguintes campos após os campos comuns, na variável default_policy:

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

   Substitua o seguinte:

   • SNAPSHOT_EXPIRATION: o número de dias para manter cada captura de ecrã (por exemplo, 15).
   • DATASET_NAME: o nome do conjunto de dados onde armazenar as capturas instantâneas (por exemplo, backups). O conjunto de dados já tem de existir no projeto especificado para backup_storage_project.

3. Se especificou GCS Snapshot (para usar o método de exportação para o Cloud Storage) ou Both como backup_method, adicione os seguintes campos à 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 o seguinte:

   • STORAGE_BUCKET: o contentor do Cloud Storage no qual armazenar os dados exportados, no formato gs://bucket/path/. Por exemplo, gs://bucket1/backups/.
   • FILE_FORMAT: o formato de ficheiro e a compressão 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 estiver definido como false, os tipos do BigQuery são exportados como strings. Se estiver definido como true, os tipos são exportados como o respetivo tipo lógico Avro. Este campo é obrigatório quando gcs_snapshot_format é qualquer formato do tipo Avro.
   • CSV_DELIMITER: o delimitador usado para os ficheiros CSV exportados e o valor pode ser qualquer caráter de byte único ISO-8859-1. Pode usar \t ou tab para especificar delimitadores de tabulações. Este campo é obrigatório quando gcs_snapshot_format tem qualquer formato do tipo CSV.
   • CSV_EXPORT_HEADER: um valor booleano. Se estiver definido como true, os cabeçalhos das colunas são exportados para os ficheiros CSV. Este campo é obrigatório quando o elemento gcs_snapshot_format tem qualquer formato do tipo CSV.

   Para ver detalhes e o mapeamento de tipos Avro, consulte a seguinte tabela:

   Tipo do BigQuery	Tipo lógico Avro
   TIMESTAMP	timestamp-micros (anota Avro LONG)
   DATE	date (anota Avro INT)
   TIME	timestamp-micro (anota Avro LONG)
   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íficos:

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

   Substitua o seguinte:

   • FOLDER_NUMBER: especifique a pasta para a qual quer definir campos de substituição.
   • PROJECT_NAME: especifique o projeto quando definir campos de substituição para um projeto, um conjunto de dados ou uma tabela específicos.
   • DATASET_NAME: especifique o conjunto de dados quando definir campos de substituição para um conjunto de dados ou uma tabela específicos.
   • TABLE_NAME: especifique a tabela para a qual quer definir 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 campos obrigatórios para o método de cópia de segurança que especificou anteriormente em default_policy.

   Se 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 seguinte, os campos de substituição são definidos para uma tabela específica que usa o método de instantâneo 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 ver um exemplo completo de uma política alternativa, consulte o ficheiro example-variables.

Configure projetos de operações de cópia de segurança adicionais

• Se quiser especificar projetos de cópia de segurança adicionais, como os definidos em configurações externas (política de cópia de segurança ao 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 estiver a usar apenas a política de cópia de segurança alternativa sem políticas externas ao nível da tabela, pode definir o valor como uma lista vazia.

  Se não adicionar este campo, todos os projetos especificados no campo backup_operation_project opcional são incluídos automaticamente como projetos alternativos.

Configure as autorizações da conta de serviço do Terraform

Nos passos anteriores, configurou os projetos de cópia de segurança onde as operações de cópia de segurança são executadas. O Terraform tem de implementar recursos nesses projetos de cópia de segurança.

A conta de serviço que o Terraform usa tem de ter as autorizações necessárias para estes projetos de cópia de segurança especificados.

• No Cloud Shell, conceda autorizações à conta de serviço para todos os projetos onde as operações de cópia de segurança são executadas:

  ./scripts/prepare_backup_operation_projects_for_terraform.sh BACKUP_OPERATIONS_PROJECT DATA_PROJECTS ADDITIONAL_BACKUPS
  

  Substitua o seguinte:

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

Execute os scripts de implementação

1. No Cloud Shell, execute o script de implementaçã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 tempo de vida (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 uma cache em algumas situações. Para poupar custos e melhorar o desempenho da pesquisa, a política de TTL permite que o Firestore elimine automaticamente as entradas expiradas.

Configure 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 alterou os nomes predefinidos no Terraform, atualize os emails das contas de serviço.

2. Se tiver definido o campo folders_include_list e quiser definir o âmbito da análise do BigQuery para incluir determinadas pastas, conceda as autorizações necessárias ao nível da pasta:

   ./scripts/prepare_data_folders.sh FOLDERS_INCLUDED
   

3. Para permitir que a aplicação execute as tarefas necessárias em diferentes projetos, conceda as autorizações necessárias em cada um destes projetos:

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

   • DATA_PROJECTS: os projetos de dados (ou projetos de origem) que contêm as tabelas de origem das quais quer fazer uma cópia de segurança (por exemplo, project1 project2). Inclua os seguintes projetos:

     • Projetos especificados nas listas de inclusão na variável do Terraform schedulers.
     • Se quiser fazer uma cópia de segurança das tabelas no projeto anfitrião, inclua o projeto anfitrião.

   • BACKUP_STORAGE_PROJECT: os projetos de armazenamento de cópias de segurança (ou projetos de destino) onde a solução armazena as cópias de segurança (por exemplo, project1 project2). Tem de incluir os projetos especificados nos seguintes campos:

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

     Inclua projetos de armazenamento de cópias de segurança que são usados em vários campos ou que são usados como projeto de origem e de destino

   • BACKUP_OPERATIONS_PROJECT: os projetos de operação de dados onde a solução executa as operações de cópia de segurança (por exemplo, project1 project2). Tem de incluir os projetos especificados nos seguintes campos:

     • Os campos backup_operation_project em todas as políticas de reserva.
     • Todas as listas de inclusão no âmbito da análise do BigQuery (se não definir o campo backup_operation_project).
     • Os campos backup_operation_project em todas as políticas ao nível da tabela.

     Inclua projetos de operações de cópia de segurança que são usados em vários campos ou que são usados como projeto de origem e de destino.

4. Para tabelas que usam o controlo de acesso ao nível da coluna, identifique todas as taxonomias de etiquetas de políticas usadas pelas suas tabelas (se existirem) 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 o seguinte:

   • TAXONOMY_PROJECT: o ID do projeto na taxonomia de etiquetas de políticas
   • TAXONOMY_LOCATION: a localização especificada na taxonomia das etiquetas de políticas
   • TAXONOMY_ID: o ID da taxonomia da taxonomia de etiquetas de políticas

5. Repita o passo anterior para cada taxonomia de etiquetas de políticas.

Execute a solução

Depois de implementar a solução, use as secções seguintes para executar e gerir a solução.

Defina políticas de cópia de segurança ao nível da tabela

• No Cloud Shell, crie uma política ao nível da tabela com os campos obrigatórios e, em seguida, armazene a política no contentor 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
  
  gcloud storage cp backup_policy.json gs://${POLICIES_BUCKET}/policy/project=${TABLE_PROJECT}/dataset=${TABLE_DATASET}/table=${TABLE}/backup_policy.json
  

  Substitua o seguinte:

  • TABLE_PROJECT: o projeto no qual a tabela reside
  • TABLE_DATASET: o conjunto de dados da tabela
  • TABLE_NAME: o nome da tabela

Acione operações de cópia de segurança

As tarefas do Cloud Scheduler que configurou anteriormente são executadas automaticamente com base na respetiva expressão cron.

Também pode executar manualmente as tarefas na Google Cloud consola. Para mais informações, consulte o artigo Execute a sua tarefa.

Monitorize e comunique

Com o projeto anfitrião (PROJECT_ID) selecionado, pode executar as seguintes consultas no BigQuery Studio para obter relatórios e informações.

• Aceda às estatísticas de progresso de cada execução (incluindo execuções em curso):

  SELECT * FROM `bq_backup_manager.v_run_summary_counts`
  

• Obtenha todos os erros fatais (não repetíveis) para uma única execução:

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

  Substitua RUN_ID pelo ID da publicação.

• Obtenha todas as execuções numa tabela e as respetivas informações de execução:

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

  Também pode especificar uma grouped versão:

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

• Para a depuração, pode obter informações detalhadas sobre pedidos e respostas 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"
  

• Obtenha as políticas de cópia de segurança que são adicionadas ou atribuídas manualmente pelo sistema com base em alternativas:

  SELECT * FROM `bq_backup_manager.ext_backup_policies`
  

Limitações

Para mais informações sobre os limites e as quotas de cada projeto especificado nos campos backup_operation_project, consulte a secção Limites.

Limpar

Para evitar incorrer em custos na sua Google Cloud conta pelos recursos usados nesta implementação, elimine os projetos que contêm os recursos ou mantenha os projetos e elimine os recursos individuais.

Elimine os projetos

Atenção: a eliminação de um projeto tem os seguintes efeitos:

• Tudo no projeto é eliminado. Se usou um projeto existente para as tarefas neste documento, quando o elimina, também elimina qualquer outro trabalho que tenha feito no projeto.
• Os IDs dos projetos personalizados são perdidos. Quando criou este projeto, pode ter criado um ID do projeto personalizado que quer usar no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, elimine os recursos selecionados no projeto em vez de eliminar o projeto inteiro.

Se planeia explorar várias arquiteturas, tutoriais ou inícios rápidos, a reutilização de projetos pode ajudar a evitar exceder os limites de quota de projetos.

Delete a Google Cloud project:

gcloud projects delete PROJECT_ID

Elimine os novos recursos

Em alternativa à eliminação dos projetos, pode eliminar os recursos criados durante este procedimento.

• No Cloud Shell, elimine os recursos do Terraform:

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

  O comando elimina quase todos os recursos. Verifique se todos os recursos que quer eliminar foram removidos.

O que se segue?

• Saiba mais sobre o BigQuery:
  • Instantâneos de tabelas do BigQuery
  • Exportações de tabelas do BigQuery para o Cloud Storage
• Para ver mais arquiteturas de referência, diagramas e práticas recomendadas, explore o Centro de arquitetura na nuvem.

Colaboradores

Autor: Karim Wadie | Strategic Cloud Engineer

Outros colaboradores:

• Chris DeForeest | Engenheiro de Fiabilidade de sites
• Eyal Ben Ivri | Arquiteto de soluções na nuvem
• Jason Davenport | Consultor de programadores
• Jaliya Ekanayake | Engineering Manager
• Muhammad Zain | Strategic Cloud Engineer