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 de copias de seguridad escalables de BigQuery.

Este documento está dirigido a arquitectos, ingenieros y responsables de administración de datos de la nube que deseen definir y automatizar las 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 configurador. El servicio de configuración determina las políticas de copia de seguridad de las tablas y, luego, envía una solicitud para cada tabla al servicio de Cloud Run correspondiente. 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

• Compilar servicios de Cloud Run
• Configurar las variables de Terraform
• Ejecuta las secuencias de comandos de Terraform y 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 cumplan con los requisitos para acceder a 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 nuevas confirmaciones).

En esta sección, crearás recursos de un solo uso.

1. En la consola de Google Cloud , activa Cloud Shell.

   Activa Cloud Shell

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

      gcloud projects create PROJECT_ID
   

   Reemplaza PROJECT_ID por el ID del proyecto que quieres 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 host de Google Cloud en el que deseas implementar la solución.
   • COMPUTE_REGION: Es la región de Google Cloud en la que quieres 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 recursos de datos (como buckets y conjuntos de datos).
   • ACCOUNT_EMAIL: Es 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:

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

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 e implementa imágenes de Docker para que las use 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 los parámetros de configuración y una secuencia de comandos de implementación.

1. En Cloud Shell, crea un archivo TFVARS de Terraform nuevo 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 e implementaste antes:

   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 desde 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 para las copias de seguridad requeridas, según sus programaciones de cron de copias 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 realizar una copia de seguridad de las tablas dentro del alcance, según sus programas 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 deseas 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 de 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, además, ignora 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 establece, la solución crea copias de seguridad de las tablas en los proyectos especificados y, además, ignora la configuración de los campos datasets_include_list y tables_include_list. Este parámetro de configuración se ignora si estableces el campo folders_include_list.
   • PROJECTS_EXCLUDED: Es una lista de nombres de proyectos o expresiones regulares (por ejemplo, "project1", "regex:^test_"). Cuando se establece, la solución no crea copias de seguridad de las tablas en los proyectos especificados. Puedes usar este parámetro de configuración junto 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, además, ignora el parámetro de configuración del campo tables_include_list. Este parámetro de configuración se ignora si estableces 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 configura, la solución no realiza copias de seguridad de las tablas en los conjuntos de datos especificados. Puedes combinar este parámetro de configuració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 estableces 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 configura, la solución no realiza 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 exclusión aceptan expresiones regulares con el formato regex:REGULAR_EXPRESSION.

   Si el nombre de 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.

   A continuación, se muestran 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 terminen con _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ítica, 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 crear copias de seguridad cada 6 horas, especifica 0 0 */6 * * *). Esta 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 crearán copias 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ánea y exportación. 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 los límites de los trabajos de instantánea 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 de origen.

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 tipo lógico de Avro correspondiente. Este campo es obligatorio cuando el gcs_snapshot_format tiene 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 de un solo byte ISO-8859-1. Puedes usar \t o tab para especificar delimitadores de tabulación. Este campo es obligatorio cuando el gcs_snapshot_format es cualquier formato de tipo CSV.
   • CSV_EXPORT_HEADER: Es un valor booleano. Si se establece en true, los encabezados de columna se exportan a los archivos CSV. Este campo es obligatorio cuando el gcs_snapshot_format es cualquier formato de tipo CSV.

   Para obtener detalles y la asignación de tipos de Avro, consulta la siguiente tabla:

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

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

     },
     "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 establecer 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 configures campos de anulación para un conjunto de datos o una tabla en particular.
   • TABLE_NAME: Especifica la tabla para la que deseas establecer 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 configuran 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 de operaciones de copia de seguridad adicionales

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

  additional_backup_operation_projects = [ADDITIONAL_BACKUPS]
  

  Reemplaza ADDITIONAL_BACKUPS por una lista separada por comas de nombres de proyectos (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, 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 necesita 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 para 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 en cualquiera de las políticas de resguardo y las políticas a nivel de tabla.
  • DATA_PROJECTS: Si no se define ningún campo backup_operation_project en una política de resguardo o a nivel de la tabla, incluye los proyectos para esas tablas de origen.
  • ADDITIONAL_BACKUPS: cualquier proyecto que se defina en la variable de Terraform additional_backup_operation_projects.

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 que vencieron.

Configura el acceso a las fuentes y los destinos

1. En Cloud Shell, configura 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 quieres establecer el alcance del análisis de BigQuery para que incluya 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 requeridos 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: Son 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:

     • Proyectos que se especifican en las listas de inclusión en la variable de Terraform schedulers.
     • Si quieres crear una copia de seguridad de las tablas en el proyecto host, incluye el proyecto host.

   • 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 en 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 usen en varios campos o que se usen 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 en todas las políticas de resguardo.
     • Todas las listas de inclusión en el 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 tabla.

     Incluye proyectos de operaciones de copia de seguridad que se usen en varios campos o que se usen 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: Es el ID de la taxonomía de la etiqueta de política.

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 tabla con los campos obligatorios y, luego, almacena la política en el bucket de Cloud Storage para las 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
  

  Reemplaza lo siguiente:

  • TABLE_PROJECT: el proyecto en el que reside la tabla
  • TABLE_DATASET: 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 Ejecuta tu trabajo.

Supervisa y genera informes

Con el proyecto 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 irrecuperables (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 de 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 de 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 en función de 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 especifica en los campos backup_operation_project, consulta Límites.

Realiza una limpieza

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 su contenido. 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 de proyecto personalizados. Cuando creaste este proyecto, es posible que hayas creado un ID del proyecto personalizado que desees utilizar en el futuro. Para conservar las URLs que usan el ID del proyecto, como una URL appspot.com, borra los recursos seleccionados dentro del proyecto, en lugar de todo el proyecto.

Si planeas explorar varios instructivos, arquitecturas o guías de inicio rápido, reutilizar proyectos puede ser útil para no exceder los límites de cuota de los proyectos.

1. En la Google Cloud consola, ve a la página Administrar recursos.

   Ir a Administrar recursos

2. En la lista de proyectos, elige el proyecto que quieres borrar y haz clic en Borrar.
3. En el diálogo, escribe el ID del proyecto y, luego, haz clic en Cerrar para borrar el proyecto.

Borra los recursos nuevos

Como alternativa a borrar los proyectos, puedes borrar los recursos creados durante este procedimiento.

• En Cloud Shell, borra los recursos de Terraform:

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

  El comando borra casi todos los recursos. Verifica 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
  • Exportaciones 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 la nube