Implementar una automatización de copias de seguridad de BigQuery escalable

Last reviewed 2024-09-17 UTC

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

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

Arquitectura

En el siguiente diagrama se muestra la arquitectura de las copias de seguridad automáticas:

Arquitectura de la solución de copia de seguridad automatizada.

Cloud Scheduler activa la ejecución. El servicio de distribución, que usa la API de BigQuery, muestra las tablas incluidas en el ámbito. A través de un mensaje de Pub/Sub, el servicio de distribuidor envía una solicitud por cada tabla al servicio de configuración. El servicio de configuración determina las políticas de copia de seguridad de las tablas y, a continuación, envía una solicitud por cada tabla al servicio de Cloud Run correspondiente. A continuación, 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 información sobre la arquitectura, consulta Automatización de copias de seguridad de BigQuery escalable.

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.

Costes

En este documento, se utilizan los siguientes componentes facturables de Google Cloud:

Para generar una estimación de costes basada en el uso previsto, utiliza la calculadora de precios.

Los usuarios nuevos Google Cloud pueden disfrutar de una prueba gratuita.

Cuando termines las tareas que se describen en este documento, puedes evitar que se te siga facturando eliminando los recursos que has creado. Para obtener más información, consulta Limpiar.

Antes de empezar

Si vas a volver a implementar la solución, puedes saltarte 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 quieres crear un proyecto de Google Cloud para usarlo como proyecto host de la implementación, usa el comando gcloud projects create:

       gcloud projects create PROJECT_ID

    Sustituye PROJECT_ID por el ID del proyecto que quieras crear.

  3. Instala Maven:

    1. Descarga Maven.

    2. En Cloud Shell, añade 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. Define 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

    Haz los cambios siguientes:

    • PROJECT_ID: el ID del Google Cloud proyecto host en el que quieres implementar la solución.
    • COMPUTE_REGION: la Google Cloud región en la que quieras desplegar recursos de computación, como Cloud Run y Gestión de Identidades y Accesos (IAM).
    • DATA_REGION: la región en la que quieres implementar recursos de datos (como cubos y conjuntos de datos). Google Cloud
    • ACCOUNT_EMAIL: la dirección de correo de la cuenta de usuario.

  6. Habilita las APIs:

    ./scripts/enable_gcp_apis.sh

    La secuencia de comandos habilita las siguientes APIs:

    • API Cloud Resource Manager
    • API de IAM
    • API de Data Catalog
    • API de Artifact Registry
    • API de BigQuery
    • Pub/Sub API
    • API de Cloud Storage
    • API Admin de Cloud Run
    • API de Cloud Build
    • API de Uso de Servicio
    • API Admin de App Engine
    • API de Acceso a VPC sin servidor
    • Cloud DNS API

  7. Prepara el segmento 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 Docker:

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

    10. Desplegar la infraestructura

    Asegúrate de haber completado la sección Antes de empezar 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 Google Cloud .

    Activar la configuración de la CLI de gcloud

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

      gcloud config configurations activate $CONFIG

gcloud auth login
gcloud auth application-default login

    Crear imágenes de servicios de Cloud Run

    • En Cloud Shell, crea y despliega 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

    Configurar 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 en el que puedas anular las variables de esta sección:

      export VARS=FILENAME
.tfvars

      Sustituye FILENAME por el nombre del archivo de variables que has creado (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"

      Puede usar los valores predeterminados definidos en el archivo variables.tf o cambiar los valores.

    3. Configura la cuenta de servicio de Terraform que has creado y preparado anteriormente en la sección Antes de empezar:

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

      Asegúrate de usar la dirección de correo completa de la cuenta que has creado.

    4. Configura los servicios de Cloud Run para que usen las imágenes de contenedor que has creado y desplegado anteriormente:

      dispatcher_service_image     = "${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-dispatcher-service:latest"
configurator_service_image   = "${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-configurator-service:latest"
snapshoter_bq_service_image  = "${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-snapshoter-bq-service:latest"
snapshoter_gcs_service_image = "${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-snapshoter-gcs-service:latest"
tagger_service_image         = "${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-tagger-service:latest"

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

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

    5. En la variable schedulers, define al menos un programador. El programador muestra y comprueba periódicamente las tablas para ver si tienen copias de seguridad obligatorias, en función de sus programaciones cron de copias de seguridad a nivel de 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]
    }
}

      Haz los cambios siguientes:

      • SCHEDULER_NAME: el nombre visible de Cloud Scheduler.
      • SCHEDULER_CRON: la frecuencia con la que el programador comprueba si se debe crear una copia de seguridad de las tablas incluidas en el ámbito, en función de sus programaciones de copias de seguridad individuales. Puede ser cualquier cadena compatible con cron de Unix. Por ejemplo, 0 * * * * es una frecuencia horaria.
      • FORCE_RUN: valor booleano. Asigne el valor false si quiere que el programador use las programaciones cron de las tablas. Si se define como true, se creará una copia de seguridad de todas las tablas incluidas en el ámbito, independientemente de su ajuste cron.
      • DRY_RUN: valor booleano. Si se define como true, no se realizan operaciones de copia de seguridad. Solo se generan mensajes de registro. Usa true cuando quieras probar y depurar la solución sin incurrir en costes de copia de seguridad.
      • FOLDERS_INCLUDED: lista de IDs numéricos de las carpetas que contienen datos de BigQuery (por ejemplo, 1234, 456). Si se define, la solución crea copias de seguridad de las tablas de las carpetas especificadas e ignora los ajustes de los campos projects_include_list, datasets_include_list y tables_include_list.
      • PROJECTS_INCLUDED: una lista de nombres de proyectos (por ejemplo, "project1", "project2"). Cuando se define, la solución crea copias de seguridad de las tablas de los proyectos especificados e ignora los ajustes de los campos datasets_include_list y tables_include_list. Este ajuste se ignora si define el campo folders_include_list.
      • PROJECTS_EXCLUDED: una lista de nombres de proyectos o una expresión regular (por ejemplo, "project1", "regex:^test_"). Si se define, la solución no hará copias de seguridad de las tablas de los proyectos especificados. Puede usar este ajuste junto con el campo folders_include_list.
      • DATASETS_INCLUDED: una lista de conjuntos de datos (por ejemplo, "project1.dataset1", "project1.dataset2"). Cuando se define, la solución crea copias de seguridad de las tablas de los conjuntos de datos especificados e ignora el valor del campo tables_include_list. Este ajuste se ignora si define los campos folders_include_list o projects_include_list.
      • DATASETS_EXCLUDED: lista de conjuntos de datos o expresión regular (por ejemplo, "project1.dataset1", "regex:.*\\_landing$"). Si se define, la solución no crea copias de seguridad de las tablas de los conjuntos de datos especificados. Puedes usar este ajuste en combinación con los campos folders_include_list o projects_include_list.
      • TABLES_INCLUDED: una lista de tablas (por ejemplo, "project1.dataset1.table 1", "project1.dataset2.table2"). Cuando se define, la solución crea una copia de seguridad de las tablas especificadas. Este ajuste se ignora si defines los campos folders_include_list, projects_include_list o datasets_include_list.
      • TABLES_EXCLUDED: una lista de tablas o una expresión regular (por ejemplo, "project1.dataset1.table 1", "regex:.*\_test"). Si se define, la solución no crea copias de seguridad de las tablas especificadas. Puedes usar este ajuste junto 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 completo (por ejemplo, "project.dataset.table") coincide con alguna de las expresiones regulares proporcionadas, se excluye del ámbito de la copia de seguridad.

      A continuación se indican algunos de los usos más habituales.

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

    Definir políticas de respaldo

    En cada ejecución, la solución debe determinar la política de copia de seguridad de cada tabla incluida en el ámbito. 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 respaldo.

    Una política alternativa 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 ofrece flexibilidad granular sin necesidad de incluir una entrada para cada tabla.

    Hay conjuntos adicionales de campos de política, en función del método de copia de seguridad que decidas usar: instantáneas de BigQuery, exportaciones a Cloud Storage o ambos.

    1. En el archivo TFVARS, en la variable default_policy, define los siguientes campos comunes de 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",

      Haz los cambios siguientes:

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

    2. Si ha especificado BigQuery Snapshot o Both como backup_method, añada 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",

      Haz los cambios siguientes:

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

    3. Si has especificado GCS Snapshot (para usar el método de exportación a Cloud Storage) o Both como backup_method, añade 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

      Haz los cambios siguientes:

      • STORAGE_BUCKET: el bucket de Cloud Storage en el que se almacenarán los datos exportados, con el formato gs://bucket/path/. Por ejemplo, gs://bucket1/backups/.
      • FILE_FORMAT: formato de archivo y 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: valor booleano. Si se define como false, los tipos de BigQuery se exportan como cadenas. Si se define como true, los tipos se exportan como su tipo lógico Avro correspondiente. Este campo es obligatorio cuando gcs_snapshot_format tiene cualquier formato de tipo Avro.
      • CSV_DELIMITER: el delimitador que se usa en 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 tabulación. Este campo es obligatorio cuando gcs_snapshot_format tiene un formato de tipo CSV.
      • CSV_EXPORT_HEADER: valor booleano. Si se define como true, los encabezados de las columnas se exportan a los archivos CSV. Este campo es obligatorio cuando gcs_snapshot_format tiene un formato de tipo CSV.

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

      Tipo 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. Añade 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" : {
   }
  }
}

      Haz los cambios siguientes:

      • FOLDER_NUMBER: especifica la carpeta para la que quieres definir campos de anulación.
      • PROJECT_NAME: especifica el proyecto cuando definas campos de anulación para un proyecto, un conjunto de datos o una tabla concretos.
      • DATASET_NAME: especifica el conjunto de datos cuando definas campos de anulación para un conjunto de datos o una tabla concretos.
      • TABLE_NAME: especifica la tabla para la que quieres definir campos de anulación.

      Para cada entrada de anulación, como un proyecto específico en la variable project_overrides, añade los campos comunes y los campos obligatorios del método de copia de seguridad que hayas especificado anteriormente en default_policy.

      Si no quieres definir anulaciones para un nivel concreto, asigna a esa variable un mapa vacío (por ejemplo, project_overrides : {}).

      En el siguiente ejemplo, se definen 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 alternativa, consulta el archivo example-variables.

    Configurar proyectos de operaciones de copia de seguridad adicionales

    • Si quiere 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, configure la siguiente variable:

      additional_backup_operation_projects = [ADDITIONAL_BACKUPS]

      Sustituye 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 alternativa sin políticas externas a nivel de tabla, puedes asignar a este valor una lista vacía.

      Si no añade 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.

    Configurar los permisos de la cuenta de servicio de Terraform

    En los pasos anteriores, ha configurado los proyectos de copia de seguridad en los que se ejecutan las operaciones de copia de seguridad. Terraform necesita desplegar 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, concede permisos a la cuenta de servicio para todos los proyectos en los que se ejecuten operaciones de copia de seguridad:

      ./scripts/prepare_backup_operation_projects_for_terraform.sh BACKUP_OPERATIONS_PROJECT DATA_PROJECTS ADDITIONAL_BACKUPS

      Haz los cambios siguientes:

      • BACKUP_OPERATIONS_PROJECT: cualquier proyecto definido en los campos backup_operation_project de cualquiera de las políticas alternativas y de las políticas a nivel de tabla.
      • DATA_PROJECTS: si no se define ningún campo backup_operation_project en una política de reserva o de nivel de tabla, incluye los proyectos de esas tablas de origen.
      • ADDITIONAL_BACKUPS: cualquier proyecto que se defina en la variable de Terraform additional_backup_operation_projects.

    Ejecutar las secuencias de comandos de implementación

    1. En Cloud Shell, ejecuta la secuencia de comandos de despliegue 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. Añade las políticas de tiempo de vida (TTL) de 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 costes y mejorar el rendimiento de las búsquedas, la política de TTL permite que Firestore elimine automáticamente las entradas caducadas.

    Configurar el acceso a fuentes y destinos

    1. En Cloud Shell, define 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 has cambiado los nombres predeterminados en Terraform, actualiza los correos de las cuentas de servicio.

    2. Si has definido el campo folders_include_list y quieres que el análisis de BigQuery incluya determinadas carpetas, concede los permisos necesarios a nivel de carpeta:

      ./scripts/prepare_data_folders.sh FOLDERS_INCLUDED

    3. Para permitir que la aplicación ejecute las tareas necesarias en diferentes proyectos, concede 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

      Haz los cambios siguientes:

      • DATA_PROJECTS: los proyectos de datos (o proyectos de origen) que contienen las tablas de origen de las que quieres 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 quieres crear copias de seguridad de las tablas del proyecto host, incluye el proyecto host.

      • BACKUP_STORAGE_PROJECT: 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). Debe incluir los proyectos que se especifican en los siguientes campos:

        • Los campos backup_storage_project de todas las políticas alternativas.
        • Los campos backup_storage_project de todas las políticas a nivel de 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: 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:

        • Los campos backup_operation_project de todas las políticas alternativas.
        • Todas las listas de inclusión del ámbito del análisis de BigQuery (si no define el campo backup_operation_project).
        • Los campos backup_operation_project de todas las políticas a nivel de tabla.

        Incluye los 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, identifique todas las taxonomías de etiquetas de políticas que usan sus tablas (si las hay) y conceda 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'

      Haz los cambios siguientes:

      • TAXONOMY_PROJECT: el ID del proyecto en la taxonomía de etiquetas de política
      • TAXONOMY_LOCATION: la ubicación especificada en la taxonomía de etiquetas de política
      • TAXONOMY_ID: el ID de la taxonomía de etiquetas de política

    5. Repita el paso anterior para cada taxonomía de etiquetas de políticas.

    Ejecutar la solución

    Una vez que hayas implementado la solución, consulta las siguientes secciones para ejecutarla y gestionarla.

    Definir políticas de copia de seguridad a nivel de tabla

    • En Cloud Shell, crea una política a nivel de tabla con los campos obligatorios y, a continuación, almacena la política en el segmento de Cloud Storage de 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

      Haz los cambios siguientes:

      • 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

    Activar operaciones de copia de seguridad

    Las tareas de Cloud Scheduler que has configurado anteriormente se ejecutan automáticamente según su expresión cron.

    También puedes ejecutar los trabajos manualmente en la Google Cloud consola. Para obtener más información, consulta Ejecutar un trabajo.

    Monitorizar y generar informes

    Con el proyecto anfitrión (PROJECT_ID) seleccionado, puedes ejecutar las siguientes consultas en BigQuery Studio para obtener informes e información.

    • Obtener estadísticas de progreso de cada carrera (incluidas las carreras en curso):

      SELECT * FROM `bq_backup_manager.v_run_summary_counts`

    • Obtener todos los errores críticos (no se pueden volver a intentar) de una sola ejecución:

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

      Sustituye RUN_ID por el ID de la ejecución.

    • Obtener 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 grouped:

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

    • Para depurar, puede obtener información detallada sobre las solicitudes y las 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 copia de seguridad que se han añadido o asignado manualmente por el sistema en función de las alternativas:

      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.

    Limpieza

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

    Eliminar los proyectos

      Delete a Google Cloud project:

      gcloud projects delete PROJECT_ID

    Eliminar los nuevos recursos

    Como alternativa a la eliminación de los proyectos, puedes eliminar los recursos creados durante este procedimiento.

    • En Cloud Shell, elimina los recursos de Terraform:

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

      El comando elimina casi todos los recursos. Comprueba que se hayan eliminado todos los recursos que quieras eliminar.

    Siguientes pasos

    Colaboradores

    Autor: Karim Wadie | Ingeniero estratégico de Cloud

    Otros colaboradores: