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 oficiales 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 la copia de seguridad automatizada:

Arquitectura de la solución de copias de seguridad automatizadas.

Cloud Scheduler activa la ejecución. El servicio de envío, que usa la API de BigQuery, enumera las tablas dentro del alcance. A través de un mensaje de Pub/Sub, el servicio de dispatcher envía una solicitud para cada tabla al servicio de configurador. El servicio de configuración 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 pertinente. 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

  • Crea servicios de Cloud Run.
  • Configura 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:

Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios.

Es posible que los usuarios de Google Cloud nuevos 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 únicos.

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

    Activate Cloud Shell

  2. Si deseas crear un proyecto Google Cloud nuevo para usarlo como 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 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 Google Cloud proyecto host en el que deseas implementar la solución.
    • COMPUTE_REGION: La Google Cloud región en la que deseas implementar recursos de procesamiento, como Cloud Run y Identity and Access Management (IAM).
    • DATA_REGION: La Google Cloud región en la que deseas implementar 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:

    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"

    10. 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 las configuraciones 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 cambiar los valores.

    3. Configura la cuenta de servicio de Terraform que creaste y preparaste anteriormente 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 a partir 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 para las copias de seguridad requeridas, según sus programas 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 incluidas en el alcance, según sus programaciones de copias de seguridad individuales. Puede ser cualquier cadena compatible con unix-cron. Por ejemplo, 0 * * * * es una frecuencia horaria.
      • 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 configura como true, se crea una copia de seguridad de todas las tablas incluidas en el alcance, independientemente de su configuración de cron.
      • DRY_RUN: Es un valor booleano. Cuando se configura 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 configura, la solución crea copias de seguridad de las tablas en las carpetas especificadas y, luego, 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 configura, la solución crea copias de seguridad de las tablas en los proyectos especificados y, luego, 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 configura, la solución no realiza copias de seguridad de las tablas en los proyectos especificados. Puedes usar este parámetro de 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 copias de seguridad de las tablas en los conjuntos de datos especificados y omite la 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 crea copias de seguridad de las tablas en los conjuntos de datos especificados. Puedes usar este parámetro de 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 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 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 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.

      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 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 copias de seguridad de cada tabla incluida en el alcance. Para obtener más información sobre los tipos de políticas, consulta Políticas de copias de seguridad. En esta sección, se muestra cómo definir una política de resguardo.

    Se define una política de resguardo 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 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 se especifica 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 punto en el tiempo desde el cual se deben crear 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áneas 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áneas y exportación. Las cuotas y los 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 configura, 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 configura como false, los tipos de BigQuery se exportan como cadenas. Si se configura como true, los tipos se exportan como su tipo lógico de Avro correspondiente. Este campo es obligatorio cuando gcs_snapshot_format tiene cualquier formato de tipo Avro.
      • CSV_DELIMITER: Es el delimitador que se usa para los archivos CSV exportados. El valor puede ser cualquier carácter de un solo byte ISO-8859-1. Puedes usar \t o tab para especificar delimitadores de tabulaciones. Este campo es obligatorio cuando gcs_snapshot_format tiene cualquier formato de tipo CSV.
      • CSV_EXPORT_HEADER: Es un valor booleano. Si se configura como true, los encabezados de columna se exportan a los archivos CSV. Este campo es obligatorio cuando gcs_snapshot_format tiene 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 Avro LONG)
      DATE date (anota Avro INT)
      TIME timestamp-micro (anota Avro LONG)
      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 configurar campos de anulación.
      • PROJECT_NAME: Especifica el proyecto cuando configuras campos de anulación para un proyecto, un conjunto de datos o una tabla en particular.
      • DATASET_NAME: Especifica el conjunto de datos cuando configuras 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 anteriormente en default_policy.

      Si no quieres establecer anulaciones para un nivel en particular, configura esa variable como 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 copias de seguridad adicionales

    • Si deseas especificar proyectos de copia de seguridad adicionales, como los que se definen en configuraciones externas (política de copia de seguridad a nivel de la tabla) o los proyectos fuente 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 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 permisos a la cuenta de servicio para todos los proyectos en los que se ejecutan 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: Son los proyectos definidos en los campos backup_operation_project de cualquiera de las políticas de resguardo y de nivel de la 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: Son los proyectos definidos 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

      En algunas situaciones, la solución usa Datastore como caché. 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 las cuentas 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 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 especificados en las listas de inclusión de la variable schedulers de Terraform
        • Si deseas crear copias 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:

        • Son 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 usan en varios campos o que se usan como proyecto de origen y de destino.

      • BACKUP_OPERATIONS_PROJECT: Son los proyectos de operación 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:

        • Son 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 la tabla.

        Incluye los proyectos de operaciones de copias 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: Es 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 taxonomía de etiquetas 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 la 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: 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 host (PROJECT_ID) seleccionado, puedes ejecutar las siguientes consultas en BigQuery Studio para obtener informes e información.

    • 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 (no reintentables) para 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 la depuración, puedes obtener información detallada sobre las solicitudes y respuestas 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 copias de seguridad que se agregan o asignan manualmente por el sistema en función de las copias de seguridad:

      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 especificado en los campos backup_operation_project, consulta Límites.

    Limpia

    Para evitar que se apliquen cargos a tu Google Cloud cuenta 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

      Delete a Google Cloud project:

      gcloud projects delete PROJECT_ID

    Borra los recursos nuevos

    Como alternativa a la eliminación de los proyectos, puedes borrar los recursos que creaste 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?

    Colaboradores

    Autor: Karim Wadie | Ingeniero estratégico de Cloud

    Otros colaboradores: