Implementa la automatización escalable de copias de seguridad de BigQuery

Last reviewed 2024-09-17 UTC

En este documento, se describe cómo implementar la automatización escalable de copias de seguridad de BigQuery.

Este documento está dirigido a arquitectos, ingenieros y responsables de gobernanza de datos de la nube que deseen definir y automatizar políticas de datos en sus organizaciones. Es útil tener experiencia en Terraform.

Arquitectura

En el siguiente diagrama, se muestra la arquitectura de las copias de seguridad automatizadas:

Cloud Scheduler activa la ejecución. El servicio de despachador, con la API de BigQuery, enumera las tablas dentro del alcance. A través de un mensaje de Pub/Sub, el servicio de despachador envía una solicitud para cada tabla al servicio de configuración. El servicio del configurador determina las políticas de copia de seguridad para las tablas y, luego, envía una solicitud para cada tabla al servicio de Cloud Run relevante. Luego, el servicio de Cloud Run envía una solicitud a la API de BigQuery y ejecuta las operaciones de copia de seguridad. Pub/Sub activa el servicio de etiquetado, que registra los resultados y actualiza el estado de la copia de seguridad en la capa de metadatos de Cloud Storage.

Para obtener detalles sobre la arquitectura, consulta Automatización escalable de copias de seguridad de BigQuery.

Objetivos

• Compila servicios de Cloud Run.
• Configura las variables de Terraform.
• Ejecuta Terraform y las secuencias de comandos de implementación manual.
• Ejecuta la solución.

Costos

En este documento, usarás los siguientes componentes facturables de Google Cloud:

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

Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios. Es posible que los usuarios nuevos de Google Cloud califiquen para obtener una prueba gratuita.

Cuando finalices las tareas que se describen en este documento, puedes borrar los recursos que creaste para evitar que continúe la facturación. Para obtener más información, consulta Cómo realizar una limpieza.

Antes de comenzar

Si vuelves a implementar la solución, puedes omitir esta sección (por ejemplo, después de confirmaciones nuevas).

En esta sección, crearás recursos únicos.

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

   Activate Cloud Shell

2. Si deseas crear un proyecto de Google Cloud nuevo para usarlo como proyecto de host para la implementación, usa el comando gcloud projects create:

      gcloud projects create PROJECT_ID
   

   Reemplaza PROJECT_ID por el ID del proyecto que deseas crear.

3. Instala Maven:

   1. Descarga Maven.

   2. En Cloud Shell, agrega Maven a PATH:

      export PATH=/DOWNLOADED_MAVEN_DIR/bin:$PATH
      

4. En Cloud Shell, clona el repositorio de GitHub:

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

5. Configura y exporta las siguientes variables de entorno:

   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
   

   Reemplaza lo siguiente:

   • PROJECT_ID: Es el ID del proyecto de host de Google Cloud en el que deseas implementar la solución.
   • COMPUTE_REGION: La región de Google Cloud en la que deseas implementar recursos de procesamiento, como Cloud Run y Identity and Access Management (IAM).
   • DATA_REGION: Es la región de Google Cloud en la que deseas implementar los recursos de datos (como buckets y conjuntos de datos).
   • ACCOUNT_EMAIL: La dirección de correo electrónico de la cuenta de usuario.

6. Habilita las API:

   ./scripts/enable_gcp_apis.sh
   

   La secuencia de comandos habilita las siguientes APIs:

   • API de Cloud Resource Manager
   • API de IAM
   • API de Data Catalog
   • API de Artifact Registry
   • API de BigQuery
   • API de Pub/Sub
   • API de Cloud Storage
   • API de Cloud Run Admin
   • API de Cloud Build
   • API de Service Usage
   • API de App Engine Admin
   • API de acceso a VPC sin servidores
   • Cloud DNS API

7. Prepara el bucket de estado de Terraform:

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

8. Prepara la cuenta de servicio de Terraform:

   ./scripts/prepare_terraform_service_account.sh
   

9. Para publicar las imágenes que usa esta solución, prepara un repositorio de Docker:

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

Implementa la infraestructura

Asegúrate de haber completado la sección Antes de comenzar al menos una vez.

En esta sección, sigue los pasos para implementar o volver a implementar la base de código más reciente en el entorno de Google Cloud.

Activa la configuración de gcloud CLI

• En Cloud Shell, activa y autentica la configuración de gcloud CLI:

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

Compila imágenes de servicios de Cloud Run

• En Cloud Shell, compila y, luego, implementa imágenes de Docker que usará el servicio de 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 las variables de Terraform

Esta implementación usa Terraform para las configuraciones y una secuencia de comandos de implementación.

1. En Cloud Shell, crea un nuevo archivo TFVARS de Terraform en el que puedas anular las variables de esta sección:

   export VARS=FILENAME
   .tfvars
   

   Reemplaza FILENAME por el nombre del archivo de variables que creaste (por ejemplo, my-variables). Puedes usar el archivo example-variables como referencia.

2. En el archivo TFVARS, configura las variables del proyecto:

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

   Puedes usar los valores predeterminados que se definen en el archivo variables.tf o cambiarlos.

3. Configura la cuenta de servicio de Terraform, que creaste y preparaste antes en Antes de comenzar:

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

   Asegúrate de usar la dirección de correo electrónico completa de la cuenta que creaste.

4. Configura los servicios de Cloud Run para que usen las imágenes de contenedor que compilaste y, luego, implementaste:

   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"
   

   Esta secuencia de comandos le indica a Terraform que use estas imágenes publicadas en los servicios de Cloud Run, que Terraform creará más adelante.

   Terraform solo vincula un servicio de Cloud Run a una imagen existente. No compila las imágenes de la base de código, ya que eso se completó en un paso anterior.

5. En la variable schedulers, define al menos un programador. El programador enumera y verifica periódicamente las tablas en busca de copias de seguridad requeridas, según sus programaciones de cron de copia de seguridad a nivel de la tabla.

   {
   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]
       }
   }
   

   Reemplaza lo siguiente:

   • SCHEDULER_NAME: Es el nombre visible de Cloud Scheduler.
   • SCHEDULER_CRON: Es la frecuencia con la que el programador verifica si se debe crear una copia de seguridad para las tablas dentro del alcance, según sus programaciones de copia de seguridad individuales. Puede ser cualquier cadena compatible con unix-cron. Por ejemplo, 0 * * * * es una frecuencia por hora.
   • FORCE_RUN: Es un valor booleano. Establece el valor en false si quieres que el programador use los programas cron de las tablas. Si se establece en true, se crea una copia de seguridad de todas las tablas dentro del alcance, independientemente de su configuración de cron.
   • DRY_RUN: Es un valor booleano. Cuando se establece en true, no se realizan operaciones de copia de seguridad reales. Solo se generan mensajes de registro. Usa true cuando quieras probar y depurar la solución sin incurrir en costos de copia de seguridad.
   • FOLDERS_INCLUDED: Es una lista de IDs numéricos para las carpetas que contienen datos de BigQuery (por ejemplo, 1234, 456). Cuando se establece, la solución crea una copia de seguridad de las tablas en las carpetas especificadas y omite la configuración de los campos projects_include_list, datasets_include_list y tables_include_list.
   • PROJECTS_INCLUDED: Es una lista de nombres de proyectos (por ejemplo, "project1", "project2"). Cuando se configura, la solución crea una copia de seguridad de las tablas en los proyectos especificados y omite la configuración de los campos datasets_include_list y tables_include_list. Este parámetro de configuración se ignora si configuras el campo folders_include_list.
   • PROJECTS_EXCLUDED: Es una lista de nombres de proyectos o una expresión regular (por ejemplo, "project1", "regex:^test_"). Cuando se configura, la solución no crea copias de seguridad de las tablas de los proyectos especificados. Puedes usar esta configuración en combinación con el campo folders_include_list.
   • DATASETS_INCLUDED: Es una lista de conjuntos de datos (por ejemplo, "project1.dataset1", "project1.dataset2"). Cuando se configura, la solución crea una copia de seguridad de las tablas en los conjuntos de datos especificados y omite el parámetro de configuración del campo tables_include_list. Este parámetro de configuración se ignora si configuras los campos folders_include_list o projects_include_list.
   • DATASETS_EXCLUDED: Es una lista de conjuntos de datos o una expresión regular (por ejemplo, "project1.dataset1", "regex:.*\\_landing$"). Cuando se establece, la solución no crea copias de seguridad de las tablas en los conjuntos de datos especificados. Puedes usar esta configuración en combinación con los campos folders_include_list o projects_include_list.
   • TABLES_INCLUDED: Es una lista de tablas (por ejemplo, "project1.dataset1.table 1", "project1.dataset2.table2"). Cuando se configura, la solución crea una copia de seguridad de las tablas especificadas. Este parámetro de configuración se ignora si configuras los campos folders_include_list, projects_include_list o datasets_include_list.
   • TABLES_EXCLUDED: Es una lista de tablas o una expresión regular (por ejemplo, "project1.dataset1.table 1", "regex:.*\_test"). Cuando se establece, la solución no crea copias de seguridad de las tablas especificadas. Puedes usar este parámetro de configuración en combinación con los campos folders_include_list, projects_include_list o datasets_include_list.

   Todas las listas de exclusiones aceptan expresiones regulares en el formato regex:REGULAR_EXPRESSION.

   Si el nombre de la entrada completamente calificado (por ejemplo, "project.dataset.table") coincide con alguna de las expresiones regulares proporcionadas, se excluye del alcance de la copia de seguridad.

   Estos son algunos casos de uso comunes:

   • Excluye todos los nombres de conjuntos de datos que terminen con _landing: datasets_exclude_list = ["regex:.*\\_landing$"]
   • Excluye todas las tablas que terminan en _test, _tst, _bkp o _copy: tables_exclude_list = ["regex:.*\_(test|tst|bkp|copy)"]

Define políticas de resguardo

En cada ejecución, la solución debe determinar la política de copia de seguridad de cada tabla dentro del alcance. Para obtener más información sobre los tipos de políticas, consulta Políticas de copia de seguridad. En esta sección, se muestra cómo definir una política de resguardo.

Una política de resguardo se define con una variable default_policy y un conjunto de excepciones o anulaciones en diferentes niveles (carpeta, proyecto, conjunto de datos y tabla). Este enfoque proporciona flexibilidad detallada sin necesidad de una entrada para cada tabla.

Existen conjuntos adicionales de campos de políticas, según el método de copia de seguridad que decidas usar: instantáneas de BigQuery, exportaciones a Cloud Storage o ambos.

1. En el archivo TFVARS, para la variable default_policy, establece los siguientes campos comunes para la política predeterminada:

   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",
   
   

   Reemplaza lo siguiente:

   • BACKUP_CRON: Es una expresión cron para establecer la frecuencia con la que se crea una copia de seguridad de una tabla (por ejemplo, para las copias de seguridad cada 6 horas, especifica 0 0 */6 * * *). Debe ser una expresión cron compatible con Spring-Framework.
   • BACKUP_METHOD: Es el método, que especificas como BigQuery Snapshot, GCS Snapshot (para usar el método de exportación a Cloud Storage) o Both. Debes proporcionar los campos obligatorios para cada método de copia de seguridad elegido, como se muestra más adelante.
   • OFFSET_DAYS: Es la cantidad de días en el pasado que determina el momento a partir del cual se debe crear una copia de seguridad de las tablas. Los valores pueden ser un número entre 0 y 7.
   • BACKUP_STORAGE_PROJECT: Es el ID del proyecto en el que se almacenan todas las operaciones de instantáneas y exportaciones. Este es el mismo proyecto en el que residen bq_snapshot_storage_dataset y gcs_snapshot_storage_location. Las implementaciones pequeñas pueden usar el proyecto host, pero las implementaciones a gran escala deben usar un proyecto independiente.
   • BACKUP_OPERATIONS_PROJECT: Es un parámetro de configuración opcional en el que especificas el ID del proyecto en el que se ejecutan todas las operaciones de instantánea y exportación. Las cuotas y límites de los trabajos de instantáneas y exportación se aplican a este proyecto. Puede ser igual que backup_storage_project. Si no se establece, la solución usa el proyecto de la tabla fuente.

2. Si especificaste BigQuery Snapshot o Both como backup_method, agrega los siguientes campos después de los campos comunes, en la variable default_policy:

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

   Reemplaza lo siguiente:

   • SNAPSHOT_EXPIRATION: Es la cantidad de días que se conservará cada instantánea (por ejemplo, 15).
   • DATASET_NAME: Es el nombre del conjunto de datos en el que se almacenarán las instantáneas (por ejemplo, backups). El conjunto de datos ya debe existir en el proyecto especificado para backup_storage_project.

3. Si especificaste GCS Snapshot (para usar el método de exportación a Cloud Storage) o Both como backup_method, agrega los siguientes campos a la variable 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
   

   Reemplaza lo siguiente:

   • STORAGE_BUCKET: Es el bucket de Cloud Storage en el que se almacenarán los datos exportados, en el formato gs://bucket/path/. Por ejemplo, gs://bucket1/backups/.
   • FILE_FORMAT: Es el formato de archivo y la compresión que se usan para exportar una tabla de BigQuery a Cloud Storage. Los valores disponibles son CSV, CSV_GZIP, JSON, JSON_GZIP, AVRO, AVRO_DEFLATE, AVRO_SNAPPY, PARQUET, PARQUET_SNAPPY y PARQUET_GZIP.
   • AVRO_TYPE: Es un valor booleano. Si se establece en false, los tipos de BigQuery se exportan como cadenas. Si se establece en true, los tipos se exportan como su correspondiente tipo lógico de Avro. Este campo es obligatorio cuando gcs_snapshot_format es cualquier formato de tipo Avro.
   • CSV_DELIMITER: Es el delimitador que se usa para los archivos CSV exportados, y el valor puede ser cualquier carácter ISO-8859-1 de un solo byte. Puedes usar \t o tab para especificar delimitadores de tabulación. Este campo es obligatorio cuando gcs_snapshot_format es cualquier formato de tipo CSV.
   • CSV_EXPORT_HEADER: Es un valor booleano. Si se establece en true, los encabezados de las columnas se exportan a los archivos CSV. Este campo es obligatorio cuando gcs_snapshot_format es cualquier formato de tipo CSV.

   Para obtener más información y la asignación de tipos de Avro, consulta la siguiente tabla:

   Tipo de BigQuery	Tipo lógico de Avro
   TIMESTAMP	timestamp-micros (anota Avro LONG)
   DATE	date (anota Avro INT)
   TIME	timestamp-micro (anota Avro LONG)
   DATETIME	STRING (tipo lógico personalizado con nombre datetime)

4. Agrega variables de anulación para carpetas, proyectos, conjuntos de datos y tablas específicas:

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

   Reemplaza lo siguiente:

   • FOLDER_NUMBER: Especifica la carpeta para la que deseas configurar los campos de anulación.
   • PROJECT_NAME: Especifica el proyecto cuando configures campos de anulación para un proyecto, un conjunto de datos o una tabla en particular.
   • DATASET_NAME: Especifica el conjunto de datos cuando establezcas campos de reemplazo para un conjunto de datos o una tabla en particular.
   • TABLE_NAME: Especifica la tabla para la que deseas establecer los campos de anulación.

   Para cada entrada de anulación, como un proyecto específico en la variable project_overrides, agrega los campos comunes y los campos obligatorios para el método de copia de seguridad que especificaste antes en default_policy.

   Si no quieres establecer anulaciones para un nivel en particular, establece esa variable en un mapa vacío (por ejemplo, project_overrides : {}).

   En el siguiente ejemplo, se establecen campos de anulación para una tabla específica que usa el método de instantánea de 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 un ejemplo completo de una política de resguardo, consulta el archivo example-variables.

Configura proyectos adicionales de operaciones de copia de seguridad

• Si deseas especificar proyectos de copia de seguridad adicionales, como los definidos en configuraciones externas (política de copia de seguridad a nivel de la tabla) o los proyectos de fuente de la tabla, configura la siguiente variable:

  additional_backup_operation_projects = [ADDITIONAL_BACKUPS]
  

  Reemplaza ADDITIONAL_BACKUPS por una lista de nombres de proyectos separados por comas (por ejemplo, "project1", "project2"). Si solo usas la política de copia de seguridad de resguardo sin políticas externas a nivel de la tabla, puedes establecer el valor en una lista vacía.

  Si no agregas este campo, todos los proyectos que se especifiquen en el campo opcional backup_operation_project se incluirán automáticamente como proyectos de copia de seguridad.

Configura los permisos de la cuenta de servicio de Terraform

En los pasos anteriores, configuraste los proyectos de copia de seguridad en los que se ejecutan las operaciones de copia de seguridad. Terraform debe implementar recursos en esos proyectos de copia de seguridad.

La cuenta de servicio que usa Terraform debe tener los permisos necesarios para estos proyectos de copia de seguridad especificados.

• En Cloud Shell, otorga los permisos de la cuenta de servicio a todos los proyectos en los que se ejecutan las operaciones de copia de seguridad:

  ./scripts/prepare_backup_operation_projects_for_terraform.sh BACKUP_OPERATIONS_PROJECT DATA_PROJECTS ADDITIONAL_BACKUPS
  

  Reemplaza lo siguiente:

  • BACKUP_OPERATIONS_PROJECT: Cualquier proyecto definido en los campos backup_operation_project de cualquiera de las políticas de resguardo y de nivel de tabla.
  • DATA_PROJECTS: Si no se define un campo backup_operation_project en una política de resguardo o a nivel de la tabla, incluye los proyectos de esas tablas de origen.
  • ADDITIONAL_BACKUPS: Cualquier proyecto que se defina en la variable additional_backup_operation_projects de Terraform.

Ejecuta las secuencias de comandos de implementación

1. En Cloud Shell, ejecuta la secuencia de comandos de implementación de 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. Agrega las políticas de tiempo de actividad (TTL) para Firestore:

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

   La solución usa Datastore como caché en algunas situaciones. Para ahorrar costos y mejorar el rendimiento de las búsquedas, la política de TTL permite que Firestore borre automáticamente las entradas vencidas.

Configura el acceso a las fuentes y los destinos

1. En Cloud Shell, establece las siguientes variables para las cuentas de servicio que usa la solución:

   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
   

   Si cambiaste los nombres predeterminados en Terraform, actualiza los correos electrónicos de la cuenta de servicio.

2. Si configuraste el campo folders_include_list y deseas establecer el alcance del análisis de BigQuery para incluir ciertas carpetas, otorga los permisos necesarios a nivel de la carpeta:

   ./scripts/prepare_data_folders.sh FOLDERS_INCLUDED
   

3. Para permitir que la aplicación ejecute las tareas necesarias en diferentes proyectos, otorga los permisos necesarios en cada uno de estos proyectos:

   ./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
   

   Reemplaza lo siguiente:

   • DATA_PROJECTS: Los proyectos de datos (o proyectos de origen) que contienen las tablas de origen de las que deseas crear una copia de seguridad (por ejemplo, project1 project2). Incluye los siguientes proyectos:

     • Son los proyectos que se especifican en las listas de inclusión de la variable schedulers de Terraform.
     • Si deseas crear una copia de seguridad de las tablas del proyecto host, inclúyelo.

   • BACKUP_STORAGE_PROJECT: Son los proyectos de almacenamiento de copias de seguridad (o proyectos de destino) en los que la solución almacena las copias de seguridad (por ejemplo, project1 project2). Debes incluir los proyectos que se especifican en los siguientes campos:

     • Los campos backup_storage_project de todas las políticas de resguardo
     • Los campos backup_storage_project en todas las políticas a nivel de la tabla

     Incluye proyectos de almacenamiento de copias de seguridad que se usan en varios campos o que se usan como proyecto de origen y de destino.

   • BACKUP_OPERATIONS_PROJECT: Son los proyectos de operaciones de datos en los que la solución ejecuta las operaciones de copia de seguridad (por ejemplo, project1 project2). Debes incluir los proyectos que se especifican en los siguientes campos:

     • Los campos backup_operation_project de todas las políticas de resguardo
     • Todas las listas de inclusión dentro del alcance del análisis de BigQuery (si no configuras el campo backup_operation_project)
     • Los campos backup_operation_project en todas las políticas a nivel de la tabla

     Incluye proyectos de operaciones de copia de seguridad que se usan en varios campos o que se usan como proyecto de origen y de destino.

4. En el caso de las tablas que usan el control de acceso a nivel de columna, identifica todas las taxonomías de etiqueta de política que usan tus tablas (si las hay) y otorga a las cuentas de servicio de la solución acceso a los datos de la tabla:

   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'
   

   Reemplaza lo siguiente:

   • TAXONOMY_PROJECT: El ID del proyecto en la taxonomía de etiqueta de política
   • TAXONOMY_LOCATION: Es la ubicación especificada en la taxonomía de etiqueta de política.
   • TAXONOMY_ID: El ID de taxonomía de la taxonomía de etiquetas de políticas

5. Repite el paso anterior para cada taxonomía de etiqueta de política.

Ejecuta la solución

Después de implementar la solución, usa las siguientes secciones para ejecutarla y administrarla.

Establece políticas de copia de seguridad a nivel de la tabla

• En Cloud Shell, crea una política a nivel de la tabla con los campos requeridos y, luego, almacénala en el bucket de 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
  

  Reemplaza lo siguiente:

  • TABLE_PROJECT: Es el proyecto en el que reside la tabla.
  • TABLE_DATASET: Es el conjunto de datos de la tabla.
  • TABLE_NAME: El nombre de la tabla.

Activa operaciones de copia de seguridad

Los trabajos de Cloud Scheduler que configuraste antes se ejecutan automáticamente según su expresión cron.

También puedes ejecutar los trabajos de forma manual en la consola de Google Cloud. Para obtener más información, consulta Cómo ejecutar tu trabajo.

Supervisión y generación de informes

Con tu proyecto de host (PROJECT_ID) seleccionado, puedes ejecutar las siguientes consultas en BigQuery Studio para obtener informes y datos.

• Obtén estadísticas de progreso de cada ejecución (incluidas las ejecuciones en curso):

  SELECT * FROM `bq_backup_manager.v_run_summary_counts`
  

• Obtén todos los errores fatales (errores que no se pueden reintentar) de una sola ejecución:

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

  Reemplaza RUN_ID por el ID de la ejecución.

• Obtén todas las ejecuciones en una tabla y su información de ejecución:

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

  También puedes especificar una versión de grouped:

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

• Para depurar, puedes obtener información detallada de la solicitud y la respuesta para cada invocación de servicio:

  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"
  

• Obtén las políticas de copia de seguridad que el sistema agrega o asigna de forma manual según los resguardos:

  SELECT * FROM `bq_backup_manager.ext_backup_policies`
  

Limitaciones

Para obtener más información sobre los límites y las cuotas de cada proyecto que se especifican en los campos backup_operation_project, consulta Límites.

Limpia

Para evitar que se apliquen cargos a tu cuenta de Google Cloud por los recursos usados en esta implementación, borra los proyectos que contienen los recursos o conserva los proyectos y borra los recursos individuales.

Borra los proyectos

Precaución: Borrar un proyecto tiene las siguientes consecuencias:

• Se borra todo en el proyecto. Si usaste un proyecto existente para las tareas de este documento, cuando lo borres, también se borrará cualquier otro trabajo que hayas realizado en el proyecto.
• Se pierden los ID personalizados de proyectos. Cuando creaste este proyecto, es posible que hayas creado un ID del proyecto personalizado que desees utilizar en el futuro. Para conservar las URL que utilizan el ID del proyecto, como una URL appspot.com, borra los recursos seleccionados dentro del proyecto en lugar de borrar todo el proyecto.

Si planeas explorar varias infraestructuras, instructivos y guías de inicio rápido la reutilización de proyectos puede ayudarte a evitar exceder los límites de las cuotas del proyecto.

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.

Borra los recursos nuevos

Como alternativa a la eliminación de los proyectos, puedes borrar los recursos que se crearon durante este procedimiento.

• En Cloud Shell, borra los recursos de Terraform:

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

  El comando borra casi todos los recursos. Asegúrate de que se hayan quitado todos los recursos que deseas borrar.

¿Qué sigue?

• Obtén más información sobre BigQuery:
  • Instantáneas de tablas de BigQuery
  • Exportación de tablas de BigQuery a Cloud Storage
• Para obtener más información sobre las arquitecturas de referencia, los diagramas y las prácticas recomendadas, explora Cloud Architecture Center.

Colaboradores

Autor: Karim Wadie | Ingeniero estratégico de Cloud

Otros colaboradores:

• Chris DeForeest | Ingeniero de confiabilidad de sitios
• Eyal Ben Ivri | Arquitecto de Soluciones de Cloud
• Jason Davenport | Developers Advocate
• Jaliya Ekanayake | Gerente de Ingeniería
• Muhammad Zain | Ingeniero estratégico de Cloud