Questa pagina è stata tradotta dall'API Cloud Translation.

Esegui il deployment dell'automazione del backup di BigQuery scalabile

Last reviewed 2024-09-17 UTC

Questo documento descrive come eseguire il deployment dell'automazione scalabile del backup BigQuery.

Questo documento è destinato ad architetti, ingegneri e responsabili della governance dei dati cloud che vogliono definire e automatizzare i criteri per i dati nelle loro organizzazioni. L'esperienza con Terraform è utile.

Architettura

Il seguente diagramma mostra l'architettura del backup automatico:

Architettura della soluzione di backup automatizzato.

Cloud Scheduler attiva l'esecuzione. Il servizio dispatcher, utilizzando l'API BigQuery, elenca le tabelle incluse nell'ambito. Tramite un messaggio Pub/Sub, il servizio dispatcher invia una richiesta per ogni tabella al servizio configuratore. Il servizio di configurazione determina i criteri di backup per le tabelle, quindi invia una richiesta per ogni tabella al servizio Cloud Run pertinente. Il servizio Cloud Run invia quindi una richiesta all'API BigQuery ed esegue le operazioni di backup. Pub/Sub attiva il servizio di tagging, che registra i risultati e aggiorna lo stato del backup nel livello di metadati di Cloud Storage.

Per informazioni dettagliate sull'architettura, vedi Automazione scalabile del backup di BigQuery.

Obiettivi

Crea servizi Cloud Run.
Configura le variabili Terraform.
Esegui gli script di deployment Terraform e manuale.
Esegui la soluzione.

Costi

In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il calcolatore prezzi.

I nuovi utenti di Google Cloud potrebbero avere diritto a una prova senza costi.

Al termine delle attività descritte in questo documento, puoi evitare l'addebito di ulteriori costi eliminando le risorse che hai creato. Per ulteriori informazioni, vedi Pulizia.

Prima di iniziare

Se stai eseguendo nuovamente il deployment della soluzione, puoi saltare questa sezione (ad esempio dopo nuovi commit).

In questa sezione, creerai risorse una tantum.

In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell
Se vuoi creare un nuovo progetto Google Cloud da utilizzare come progetto host per il deployment, utilizza il comando gcloud projects create:
```
   gcloud projects create PROJECT_ID
```
Sostituisci PROJECT_ID con l'ID del progetto che vuoi creare.
Installa Maven:
1. Scarica Maven.
2. In Cloud Shell, aggiungi Maven a PATH:
```
export PATH=/DOWNLOADED_MAVEN_DIR/bin:$PATH
```

In Cloud Shell, clona il repository GitHub:

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

Imposta ed esporta le seguenti variabili di 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

Sostituisci quanto segue:

PROJECT_ID: l'ID del Google Cloud progetto host in cui vuoi eseguire il deployment della soluzione.
COMPUTE_REGION: la Google Cloud regione in cui vuoi eseguire il deployment di risorse di calcolo come Cloud Run e Identity and Access Management (IAM).
DATA_REGION: la regione Google Cloud in cui vuoi eseguire il deployment delle risorse di dati (come bucket e set di dati).
ACCOUNT_EMAIL: l'indirizzo email dell'account utente.

Abilita le API:
```
./scripts/enable_gcp_apis.sh
```
Lo script abilita le seguenti API:
- 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 Serverless VPC Access
- API del cloud DNS

Prepara il bucket di stato Terraform:

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

Prepara il account di servizio Terraform:

./scripts/prepare_terraform_service_account.sh

Per pubblicare le immagini utilizzate da questa soluzione, prepara un repository Docker:

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

Esegui il deployment dell'infrastruttura

Assicurati di aver completato la sezione Prima di iniziare almeno una volta.

In questa sezione, segui i passaggi per eseguire il deployment o il redeploy dell'ultima base di codice nell'ambiente Google Cloud .

Attiva la configurazione di gcloud CLI

In Cloud Shell, attiva e autentica la configurazione di gcloud CLI:

gcloud config configurations activate $CONFIG

gcloud auth login
gcloud auth application-default login

Crea immagini dei servizi Cloud Run

In Cloud Shell, crea ed esegui il deployment delle immagini Docker da utilizzare dal servizio 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

Configura le variabili Terraform

Questo deployment utilizza Terraform per le configurazioni e uno script di deployment.

In Cloud Shell, crea un nuovo file TFVARS Terraform in cui puoi sostituire le variabili in questa sezione:
```
export VARS=FILENAME
.tfvars
```
Sostituisci FILENAME con il nome del file di variabili che hai creato (ad esempio, my-variables). Puoi utilizzare il file example-variables come riferimento.
Nel file TFVARS, configura le variabili del progetto:
```
project = "PROJECT_ID"
compute_region = "COMPUTE_REGION"
data_region = "DATA_REGION"
```
Puoi utilizzare i valori predefiniti definiti nel file variables.tf o modificarli.
Configura il account di servizio Terraform, che hai creato e preparato in precedenza in Prima di iniziare:
```
terraform_service_account =
"bq-backup-mgr-terraform@PROJECT_ID.iam.gserviceaccount.com"
```
Assicurati di utilizzare l'indirizzo email completo dell'account che hai creato.

Configura i servizi Cloud Run in modo da utilizzare le immagini container che hai creato e di cui hai eseguito il deployment in precedenza:

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"

Questo script indica a Terraform di utilizzare queste immagini pubblicate nei servizi Cloud Run, che Terraform crea in un secondo momento.

Terraform collega un servizio Cloud Run solo a un'immagine esistente. Non crea le immagini dal codebase, perché questa operazione è stata completata in un passaggio precedente.

Nella variabile schedulers, definisci almeno uno scheduler. Lo scheduler elenca e controlla periodicamente le tabelle per i backup richiesti, in base alle pianificazioni cron di backup a livello di tabella.
```
{
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]
    }
}
```
Sostituisci quanto segue:
- SCHEDULER_NAME: il nome visualizzato di Cloud Scheduler.
- SCHEDULER_CRON: la frequenza con cui lo scheduler controlla se è dovuto un backup per le tabelle incluse nell'ambito, in base alle singole pianificazioni di backup. Può essere qualsiasi stringa compatibile con unix-cron. Ad esempio, 0 * * * * è una frequenza oraria.
- FORCE_RUN: un valore booleano. Imposta il valore su false se vuoi che lo scheduler utilizzi le pianificazioni cron delle tabelle. Se impostato su true, viene eseguito il backup di tutte le tabelle incluse nell'ambito, indipendentemente dall'impostazione cron.
- DRY_RUN: un valore booleano. Se impostato su true, non vengono eseguite operazioni di backup effettive. Vengono generati solo messaggi di log. Utilizza true quando vuoi testare ed eseguire il debug della soluzione senza sostenere costi di backup.
- FOLDERS_INCLUDED: un elenco di ID numerici per le cartelle che contengono dati BigQuery (ad esempio 1234, 456). Se impostata, la soluzione esegue il backup delle tabelle nelle cartelle specificate e ignora le impostazioni dei campi projects_include_list, datasets_include_list e tables_include_list.
- PROJECTS_INCLUDED: un elenco di nomi di progetti (ad esempio, "project1", "project2"). Se impostata, la soluzione esegue il backup delle tabelle nei progetti specificati e ignora le impostazioni dei campi datasets_include_list e tables_include_list. Questa impostazione viene ignorata se imposti il campo folders_include_list.
- PROJECTS_EXCLUDED: un elenco di nomi di progetti o un'espressione regolare (ad esempio, "project1", "regex:^test_"). Se impostata, la soluzione non esegue backup delle tabelle nei progetti specificati. Puoi utilizzare questa impostazione in combinazione con il campo folders_include_list.
- DATASETS_INCLUDED: un elenco di set di dati (ad esempio, "project1.dataset1", "project1.dataset2"). Se impostata, la soluzione esegue il backup delle tabelle nei set di dati specificati e ignora l'impostazione del campo tables_include_list. Questa impostazione viene ignorata se imposti i campi folders_include_list o projects_include_list.
- DATASETS_EXCLUDED: un elenco di set di dati o un'espressione regolare (ad esempio, "project1.dataset1", "regex:.*\\_landing$"). Se impostata, la soluzione non esegue backup delle tabelle nei set di dati specificati. Puoi utilizzare questa impostazione in combinazione con i campi folders_include_list o projects_include_list.
- TABLES_INCLUDED: un elenco di tabelle (ad esempio, "project1.dataset1.table 1", "project1.dataset2.table2"). Se impostato, la soluzione esegue il backup delle tabelle specificate. Questa impostazione viene ignorata se imposti i campi folders_include_list, projects_include_list o datasets_include_list.
- TABLES_EXCLUDED: un elenco di tabelle o un'espressione regolare (ad esempio, "project1.dataset1.table 1", "regex:.*\_test"). Se impostata, la soluzione non esegue backup delle tabelle specificate. Puoi utilizzare questa impostazione in combinazione con i campi folders_include_list, projects_include_list o datasets_include_list.
Tutti gli elenchi di esclusione accettano espressioni regolari nel formato regex:REGULAR_EXPRESSION.

Se il nome completo della voce (ad esempio "project.dataset.table") corrisponde a una delle espressioni regolari fornite, viene escluso dall'ambito del backup.

Di seguito sono riportati alcuni casi d'uso comuni:
- Escludi tutti i nomi dei set di dati che terminano con _landing: datasets_exclude_list = ["regex:.*\\_landing$"]
- Escludi tutte le tabelle che terminano con _test, _tst, _bkp o _copy: tables_exclude_list = ["regex:.*\_(test|tst|bkp|copy)"]

Definisci le policy di riserva

A ogni esecuzione, la soluzione deve determinare la norma di backup di ogni tabella inclusa nell'ambito. Per saperne di più sui tipi di policy, consulta Policy di backup. Questa sezione mostra come definire un criterio di riserva.

Un criterio di riserva è definito con una variabile default_policy e un insieme di eccezioni o override a diversi livelli (cartella, progetto, set di dati e tabella). Questo approccio offre una flessibilità granulare senza la necessità di una voce per ogni tabella.

Esistono ulteriori set di campi dei criteri, a seconda del metodo di backup che decidi di utilizzare: snapshot BigQuery, esportazioni in Cloud Storage o entrambi.

Nel file TFVARS, per la variabile default_policy, imposta i seguenti campi comuni per le norme predefinite:
```
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",
```
Sostituisci quanto segue:
- BACKUP_CRON: un'espressione cron per impostare la frequenza con cui viene eseguito il backup di una tabella (ad esempio, per i backup ogni 6 ore, specifica 0 0 */6 * * *). Deve essere un'espressione cron compatibile con Spring-Framework.
- BACKUP_METHOD: il metodo, che specifichi come BigQuery Snapshot, GCS Snapshot (per utilizzare il metodo di esportazione in Cloud Storage) o Both. Devi fornire i campi obbligatori per ogni metodo di backup scelto, come mostrato in seguito.
- OFFSET_DAYS: il numero di giorni nel passato che determina il punto nel tempo da cui eseguire il backup delle tabelle. I valori possono essere un numero compreso tra 0 e 7.
- BACKUP_STORAGE_PROJECT: l'ID del progetto in cui sono archiviate tutte le operazioni di snapshot ed esportazione. Si tratta dello stesso progetto in cui risiedono bq_snapshot_storage_dataset e gcs_snapshot_storage_location. I deployment di piccole dimensioni possono utilizzare il progetto host, ma i deployment su larga scala devono utilizzare un progetto separato.
- BACKUP_OPERATIONS_PROJECT: un'impostazione facoltativa in cui specifichi l'ID del progetto in cui vengono eseguite tutte le operazioni di snapshot ed esportazione. A questo progetto si applicano le quote e i limiti dei job di snapshot ed esportazione. Può avere lo stesso valore di backup_storage_project. Se non viene impostato, la soluzione utilizza il progetto della tabella di origine.
Se hai specificato BigQuery Snapshot o Both come backup_method, aggiungi i seguenti campi dopo i campi comuni nella variabile default_policy:
```
  "bq_snapshot_expiration_days" : "SNAPSHOT_EXPIRATION",
  "bq_snapshot_storage_dataset" : "DATASET_NAME",
```
Sostituisci quanto segue:
- SNAPSHOT_EXPIRATION: il numero di giorni per cui conservare ogni snapshot (ad esempio, 15).
- DATASET_NAME: il nome del set di dati in cui archiviare gli snapshot (ad esempio backups). Il set di dati deve già esistere nel progetto specificato per backup_storage_project.

Se hai specificato GCS Snapshot (per utilizzare il metodo di esportazione in Cloud Storage) o Both come backup_method, aggiungi i seguenti campi alla variabile 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

Sostituisci quanto segue:

STORAGE_BUCKET: il bucket Cloud Storage in cui archiviare i dati esportati, nel formato gs://bucket/path/. Ad esempio gs://bucket1/backups/.
FILE_FORMAT: il formato del file e la compressione utilizzati per esportare una tabella BigQuery in Cloud Storage. I valori disponibili sono CSV, CSV_GZIP, JSON, JSON_GZIP, AVRO, AVRO_DEFLATE, AVRO_SNAPPY, PARQUET, PARQUET_SNAPPY e PARQUET_GZIP.
AVRO_TYPE: un valore booleano. Se impostato su false, i tipi BigQuery vengono esportati come stringhe. Se impostato su true, i tipi vengono esportati come tipi logici Avro corrispondenti. Questo campo è obbligatorio quando gcs_snapshot_format è un formato di tipo Avro.
CSV_DELIMITER: il delimitatore utilizzato per i file CSV esportati e il valore può essere qualsiasi carattere a byte singolo ISO-8859-1. Puoi utilizzare \t o tab per specificare i delimitatori di tabulazione. Questo campo è obbligatorio quando gcs_snapshot_format è un formato di tipo CSV.
CSV_EXPORT_HEADER: un valore booleano. Se impostato su true, le intestazioni delle colonne vengono esportate nei file CSV. Questo campo è obbligatorio quando gcs_snapshot_format è un formato di tipo CSV.

Per i dettagli e la mappatura dei tipi Avro, consulta la tabella seguente:

Tipo BigQuery	Tipo logico Avro
`TIMESTAMP`	`timestamp-micros` (annotates Avro `LONG`)
`DATE`	`date` (annotates Avro `INT`)
`TIME`	`timestamp-micro` (annotates Avro `LONG`)
`DATETIME`	`STRING` (tipo logico denominato personalizzato `datetime`)

Aggiungi variabili di override per cartelle, progetti, set di dati e tabelle specifici:
```
  },
  "folder_overrides" : {
   "FOLDER_NUMBER" : {
   },
  },

  "project_overrides" : {
   "PROJECT_NAME" : {
   }
  },

  "dataset_overrides" : {
   "PROJECT_NAME.DATASET_NAME" : {
   }
  },

  "table_overrides" : {
   "PROJECT_NAME.DATASET_NAME.TABLE_NAME" : {
   }
  }
}
```
Sostituisci quanto segue:
- FOLDER_NUMBER: specifica la cartella per cui vuoi impostare i campi di override.
- PROJECT_NAME: specifica il progetto quando imposti i campi di override per un progetto, un set di dati o una tabella specifici.
- DATASET_NAME: specifica il set di dati quando imposti i campi di override per un determinato set di dati o tabella.
- TABLE_NAME: specifica la tabella per la quale vuoi impostare i campi di override.
Per ogni voce di override, ad esempio un progetto specifico nella variabile project_overrides, aggiungi i campi comuni e i campi obbligatori per il metodo di backup specificato in precedenza in default_policy.

Se non vuoi impostare override per un determinato livello, imposta la variabile su una mappa vuota (ad esempio, project_overrides : {}).

Nell'esempio seguente, i campi di override sono impostati per una tabella specifica che utilizza il metodo di snapshot 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"
    },
   }
}
```

Per un esempio completo di una policy di riserva, consulta il file example-variables.

Configura progetti di operazioni di backup aggiuntivi

Se vuoi specificare progetti di backup aggiuntivi, ad esempio quelli definiti nelle configurazioni esterne (policy di backup a livello di tabella) o nei progetti di origine della tabella, configura la seguente variabile:
```
additional_backup_operation_projects = [ADDITIONAL_BACKUPS]
```
Sostituisci ADDITIONAL_BACKUPS con un elenco separato da virgole di nomi di progetti (ad esempio, "project1", "project2"). Se utilizzi solo il criterio di backup di riserva senza criteri esterni a livello di tabella, puoi impostare il valore su un elenco vuoto.

Se non aggiungi questo campo, tutti i progetti specificati nel campo facoltativo backup_operation_project vengono inclusi automaticamente come progetti di backup.

Configura le autorizzazioni dell'account di servizio Terraform

Nei passaggi precedenti, hai configurato i progetti di backup in cui vengono eseguite le operazioni di backup. Terraform deve eseguire il deployment delle risorse in questi progetti di backup.

Il account di servizio utilizzato da Terraform deve disporre delle autorizzazioni richieste per questi progetti di backup specificati.

In Cloud Shell, concedi al account di servizio le autorizzazioni per tutti i progetti in cui vengono eseguite le operazioni di backup:
```
./scripts/prepare_backup_operation_projects_for_terraform.sh BACKUP_OPERATIONS_PROJECT DATA_PROJECTS ADDITIONAL_BACKUPS
```
Sostituisci quanto segue:
- BACKUP_OPERATIONS_PROJECT: tutti i progetti definiti nei campi backup_operation_project in una qualsiasi delle policy di fallback e delle policy a livello di tabella.
- DATA_PROJECTS: se in una policy di riserva o a livello di tabella non è definito alcun campo backup_operation_project, includi i progetti per queste tabelle di origine.
- ADDITIONAL_BACKUPS: tutti i progetti definiti nella variabile Terraform additional_backup_operation_projects.

Esegui gli script di deployment

In Cloud Shell, esegui lo script di deployment di 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

Aggiungi le policy di durata (TTL) per Firestore:
```
gcloud firestore fields ttls update expires_at \
    --collection-group=project_folder_cache \
    --enable-ttl \
    --async \
    --project=$PROJECT_ID
```
La soluzione utilizza Datastore come cache in alcune situazioni. Per risparmiare sui costi e migliorare le prestazioni di ricerca, la norma TTL consente a Firestore di eliminare automaticamente le voci scadute.

Configurare l'accesso a origini e destinazioni

In Cloud Shell, imposta le seguenti variabili per gli account di servizio utilizzati dalla soluzione:

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 hai modificato i nomi predefiniti in Terraform, aggiorna le email dell'account di servizio.

Se hai impostato il campo folders_include_list e vuoi impostare l'ambito della scansione BigQuery in modo da includere determinate cartelle, concedi le autorizzazioni richieste a livello di cartella:
```
./scripts/prepare_data_folders.sh FOLDERS_INCLUDED
```
Per consentire all'applicazione di eseguire le attività necessarie in progetti diversi, concedi le autorizzazioni richieste in ciascuno di questi progetti:
```
./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
```
Sostituisci quanto segue:
- DATA_PROJECTS: i progetti di dati (o progetti di origine) che contengono le tabelle di origine di cui vuoi eseguire il backup (ad esempio project1 project2). Includi i seguenti progetti:
  - Progetti specificati negli elenchi di inclusione nella variabile Terraform schedulers.
  - Se vuoi eseguire il backup delle tabelle nel progetto host, includi il progetto host.
- BACKUP_STORAGE_PROJECT: i progetti di archiviazione dei backup (o progetti di destinazione) in cui la soluzione archivia i backup (ad esempio, project1 project2). Devi includere i progetti specificati nei seguenti campi:
  - I campi backup_storage_project in tutte le norme di riserva.
  - I campi backup_storage_project in tutte le policy a livello di tabella.
  Includi i progetti di archiviazione dei backup utilizzati in più campi o utilizzati sia come progetto di origine che di destinazione
- BACKUP_OPERATIONS_PROJECT: i progetti di operazioni sui dati in cui la soluzione esegue le operazioni di backup (ad esempio, project1 project2). Devi includere i progetti specificati nei seguenti campi:
  - I campi backup_operation_project in tutte le norme di riserva.
  - Tutti gli elenchi di inclusione nell'ambito della scansione BigQuery (se non imposti il campo backup_operation_project).
  - I campi backup_operation_project in tutte le norme a livello di tabella.
  Includi i progetti delle operazioni di backup utilizzati in più campi o utilizzati sia come progetto di origine sia come progetto di destinazione.
Per le tabelle che utilizzano il controllo dell'accesso a livello di colonna, identifica tutte le tassonomie dei tag di criteri utilizzate dalle tabelle (se presenti) e concedi l'accesso ai dati delle tabelle agli account di servizio della soluzione:
```
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'
```
Sostituisci quanto segue:
- TAXONOMY_PROJECT: l'ID progetto nella tassonomia dei tag di criteri
- TAXONOMY_LOCATION: la posizione specificata nella tassonomia deitag di criteriy
- TAXONOMY_ID: l'ID tassonomia della tassonomia dei tag policy
Ripeti il passaggio precedente per ogni tassonomia dei tag di criteri.

Esegui la soluzione

Dopo aver eseguito il deployment della soluzione, utilizza le sezioni seguenti per eseguirla e gestirla.

Imposta policy di backup a livello di tabella

In Cloud Shell, crea una policy a livello di tabella con i campi obbligatori, quindi archiviala nel bucket Cloud Storage per le policy:

# 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

Sostituisci quanto segue:

TABLE_PROJECT: il progetto in cui si trova la tabella
TABLE_DATASET: il set di dati della tabella
TABLE_NAME: il nome della tabella

Attivare le operazioni di backup

I job Cloud Scheduler che hai configurato in precedenza vengono eseguiti automaticamente in base alla relativa espressione cron.

Puoi anche eseguire manualmente i job nella console Google Cloud . Per ulteriori informazioni, vedi Eseguire il job.

Monitoraggio e report

Con il progetto host (PROJECT_ID) selezionato, puoi eseguire le seguenti query in BigQuery Studio per ottenere report e informazioni.

Visualizza le statistiche di avanzamento di ogni corsa (incluse quelle in corso):
```
SELECT * FROM `bq_backup_manager.v_run_summary_counts`
```
Ottieni tutti gli errori irreversibili (non riproducibili) per una singola esecuzione:
```
SELECT * FROM `bq_backup_manager.v_errors_non_retryable`
WHERE run_id = 'RUN_ID'
```
Sostituisci RUN_ID con l'ID dell'esecuzione.

Visualizza tutte le esecuzioni in una tabella e le relative informazioni:

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

Puoi anche specificare una versione di grouped:

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

Per il debug, puoi ottenere informazioni dettagliate su richieste e risposte per ogni chiamata di servizio:

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"

Recupera i criteri di backup aggiunti o assegnati manualmente dal sistema in base ai fallback:
```
SELECT * FROM `bq_backup_manager.ext_backup_policies`
```

Limitazioni

Per ulteriori informazioni sui limiti e sulle quote per ogni progetto specificato nei campi backup_operation_project, consulta Limiti.

Esegui la pulizia

Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo deployment, elimina i progetti che contengono le risorse oppure mantieni i progetti ed elimina le singole risorse.

Elimina i progetti

Attenzione: l'eliminazione di un progetto ha i seguenti effetti:

L'intero contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per le attività descritte in questo documento, quando lo elimini, elimini anche tutto il lavoro che hai svolto nel progetto.
Gli ID progetto personalizzati non sono più disponibili. Quando hai creato questo progetto, potresti aver creato un ID progetto personalizzato che vuoi utilizzare in futuro. Per conservare gli URL che utilizzano l'ID progetto, ad esempio un URL appspot.com, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.

Se intendi esplorare più architetture, tutorial o guide rapide, puoi riutilizzare i progetti ed evitare così di superare i limiti di quota.

Delete a Google Cloud project:

gcloud projects delete PROJECT_ID

Elimina le nuove risorse

In alternativa all'eliminazione dei progetti, puoi eliminare le risorse create durante questa procedura.

In Cloud Shell, elimina le risorse Terraform:
```
terraform destroy -var-file="${VARS}"
```
Il comando elimina quasi tutte le risorse. Verifica che tutte le risorse che vuoi eliminare siano state rimosse.

Passaggi successivi

Scopri di più su BigQuery:
- Snapshot delle tabelle BigQuery
- Esportazioni di tabelle BigQuery in Cloud Storage
Per ulteriori architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.

Collaboratori

Autore: Karim Wadie | Strategic Cloud Engineer

Altri collaboratori:

Chris DeForeest | Site Reliability Engineer
Eyal Ben Ivri | Cloud Solutions Architect
Jason Davenport | Developer Advocate
Jaliya Ekanayake | Engineering Manager
Muhammad Zain | Strategic Cloud Engineer

Esegui il deployment dell'automazione del backup di BigQuery scalabile Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Architettura

Obiettivi

Costi

Prima di iniziare

Esegui il deployment dell'infrastruttura

Attiva la configurazione di gcloud CLI

Crea immagini dei servizi Cloud Run

Configura le variabili Terraform

Definisci le policy di riserva

Configura progetti di operazioni di backup aggiuntivi

Configura le autorizzazioni dell'account di servizio Terraform

Esegui gli script di deployment

Configurare l'accesso a origini e destinazioni

Esegui la soluzione

Imposta policy di backup a livello di tabella

Attivare le operazioni di backup

Monitoraggio e report

Limitazioni

Esegui la pulizia

Elimina i progetti

Elimina le nuove risorse

Passaggi successivi

Collaboratori

Esegui il deployment dell'automazione del backup di BigQuery scalabile