Déployer une automatisation de sauvegarde BigQuery évolutive

Last reviewed 2024-09-17 UTC

Ce document explique comment déployer l'automatisation de la sauvegarde BigQuery évolutive.

Ce document s'adresse aux architectes cloud, aux ingénieurs et aux responsables de la gouvernance des données qui souhaitent définir et automatiser des règles de données dans leurs organisations. L'expérience de Terraform est utile.

Architecture

Le schéma suivant illustre l'architecture de la sauvegarde automatisée :

Architecture de la solution de sauvegarde automatisée.

Cloud Scheduler déclenche l'exécution. Le service de répartiteur, à l'aide de l'API BigQuery, liste les tables concernées. Par le biais d'un message Pub/Sub, le service de répartition envoie une requête pour chaque tableau au service de configuration. Le service de configuration détermine les règles de sauvegarde pour les tables, puis envoie une requête pour chaque table au service Cloud Run concerné. Le service Cloud Run envoie ensuite une requête à l'API BigQuery et exécute les opérations de sauvegarde. Pub/Sub déclenche le service de taggage, qui enregistre les résultats et met à jour l'état de la sauvegarde dans la couche de métadonnées Cloud Storage.

Pour en savoir plus sur l'architecture, consultez Automatisation évolutive de la sauvegarde BigQuery.

Objectifs

  • Créez des services Cloud Run.
  • Configurez les variables Terraform.
  • Exécutez les scripts de déploiement Terraform et manuel.
  • Exécutez la solution.

Coûts

Dans ce document, vous utilisez les composants facturables de Google Cloudsuivants :

Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût.

Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai gratuit.

Une fois que vous avez terminé les tâches décrites dans ce document, vous pouvez éviter de continuer à payer des frais en supprimant les ressources que vous avez créées. Pour en savoir plus, consultez la section Effectuer un nettoyage.

Avant de commencer

Si vous redéployez la solution, vous pouvez ignorer cette section (par exemple, après de nouveaux commits).

Dans cette section, vous allez créer des ressources ponctuelles.

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

    Activate Cloud Shell

  2. Si vous souhaitez créer un projet Google Cloud à utiliser comme projet hôte pour le déploiement, utilisez la commande gcloud projects create :

       gcloud projects create PROJECT_ID

    Remplacez PROJECT_ID par l'ID du projet que vous souhaitez créer.

  3. Installez Maven :

    1. Téléchargez Maven.

    2. Dans Cloud Shell, ajoutez Maven à PATH :

      export PATH=/DOWNLOADED_MAVEN_DIR/bin:$PATH

  4. Dans Cloud Shell, clonez le dépôt GitHub.

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

  5. Définissez et exportez les variables d'environnement suivantes :

    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

    Remplacez les éléments suivants :

    • PROJECT_ID : ID du Google Cloud projet hôte Google Cloud dans lequel vous souhaitez déployer la solution.
    • COMPUTE_REGION : Google Cloud région dans laquelle vous souhaitez déployer des ressources de calcul telles que Cloud Run et Identity and Access Management (IAM).
    • DATA_REGION : région Google Cloud dans laquelle vous souhaitez déployer des ressources de données (telles que des buckets et des ensembles de données).
    • ACCOUNT_EMAIL : adresse e-mail du compte utilisateur.

  6. Activer les API :

    ./scripts/enable_gcp_apis.sh

    Le script active les API suivantes :

    • API Cloud Resource Manager
    • API IAM
    • API Data Catalog
    • API Artifact Registry
    • API BigQuery
    • API Pub/Sub
    • API Cloud Storage
    • API Cloud Run Admin
    • API Cloud Build
    • API Service Usage
    • API App Engine Admin
    • API Serverless VPC Access
    • API Cloud DNS

  7. Préparez le bucket d'état Terraform :

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

  8. Préparez le compte de service Terraform :

    ./scripts/prepare_terraform_service_account.sh

  9. Pour publier les images utilisées par cette solution, préparez un dépôt Docker :

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

    10. Déployer l'infrastructure

    Assurez-vous d'avoir suivi la section Avant de commencer au moins une fois.

    Dans cette section, suivez les étapes pour déployer ou redéployer la dernière base de code dans l'environnement Google Cloud .

    Activer la configuration gcloud CLI

    • Dans Cloud Shell, activez et authentifiez la configuration de la gcloud CLI :

      gcloud config configurations activate $CONFIG

gcloud auth login
gcloud auth application-default login

    Créer des images de services Cloud Run

    • Dans Cloud Shell, créez et déployez les images Docker à utiliser par le service 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

    Configurer les variables Terraform

    Ce déploiement utilise Terraform pour les configurations et un script de déploiement.

    1. Dans Cloud Shell, créez un fichier TFVARS Terraform dans lequel vous pouvez remplacer les variables de cette section :

      export VARS=FILENAME
.tfvars

      Remplacez FILENAME par le nom du fichier de variables que vous avez créé (par exemple, my-variables). Vous pouvez utiliser le fichier example-variables comme référence.

    2. Dans le fichier TFVARS, configurez les variables du projet :

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

      Vous pouvez utiliser les valeurs par défaut définies dans le fichier variables.tf ou les modifier.

    3. Configurez le compte de service Terraform que vous avez créé et préparé précédemment dans Avant de commencer :

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

      Assurez-vous d'utiliser l'adresse e-mail complète du compte que vous avez créé.

    4. Configurez les services Cloud Run pour qu'ils utilisent les images de conteneur que vous avez créées et déployées précédemment :

      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"

      Ce script indique à Terraform d'utiliser ces images publiées dans les services Cloud Run, que Terraform créera ultérieurement.

      Terraform n'associe un service Cloud Run qu'à une image existante. Il ne crée pas les images à partir du code de base, car cela a été fait lors d'une étape précédente.

    5. Dans la variable schedulers, définissez au moins un planificateur. Le planificateur liste et vérifie périodiquement les tables pour les sauvegardes requises, en fonction de leurs planifications Cron de sauvegarde au niveau des tables.

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

      Remplacez les éléments suivants :

      • SCHEDULER_NAME : nom à afficher pour Cloud Scheduler.
      • SCHEDULER_CRON : fréquence à laquelle le planificateur vérifie si une sauvegarde est due pour les tables concernées, en fonction de leurs plannings de sauvegarde individuels. Il peut s'agir de n'importe quelle chaîne compatible avec unix-cron. Par exemple, 0 * * * * est une fréquence horaire.
      • FORCE_RUN : valeur booléenne. Définissez la valeur sur false si vous souhaitez que le planificateur utilise les planifications cron des tables. Si la valeur est définie sur true, toutes les tables concernées sont sauvegardées, quel que soit leur paramètre cron.
      • DRY_RUN : valeur booléenne. Lorsque la valeur est définie sur true, aucune opération de sauvegarde réelle n'a lieu. Seuls les messages de journal sont générés. Utilisez true lorsque vous souhaitez tester et déboguer la solution sans engendrer de frais de sauvegarde.
      • FOLDERS_INCLUDED : liste des ID numériques des dossiers contenant des données BigQuery (par exemple, 1234, 456). Lorsque cette option est définie, la solution sauvegarde les tables des dossiers spécifiés et ignore les paramètres des champs projects_include_list, datasets_include_list et tables_include_list.
      • PROJECTS_INCLUDED : liste des noms de projets (par exemple, "project1", "project2"). Lorsque cette option est définie, la solution sauvegarde les tables des projets spécifiés et ignore les paramètres des champs datasets_include_list et tables_include_list. Ce paramètre est ignoré si vous définissez le champ folders_include_list.
      • PROJECTS_EXCLUDED : liste de noms de projets ou expression régulière (par exemple, "project1", "regex:^test_"). Lorsque cette option est définie, la solution ne sauvegarde pas les tables des projets spécifiés. Vous pouvez utiliser ce paramètre en combinaison avec le champ folders_include_list.
      • DATASETS_INCLUDED : liste des ensembles de données (par exemple, "project1.dataset1", "project1.dataset2"). Lorsque cette option est définie, la solution sauvegarde les tables des ensembles de données spécifiés et ignore le paramètre du champ tables_include_list. Ce paramètre est ignoré si vous définissez les champs folders_include_list ou projects_include_list.
      • DATASETS_EXCLUDED : liste d'ensembles de données ou expression régulière (par exemple, "project1.dataset1", "regex:.*\\_landing$"). Lorsque cette option est définie, la solution ne sauvegarde pas les tables des ensembles de données spécifiés. Vous pouvez utiliser ce paramètre en combinaison avec les champs folders_include_list ou projects_include_list.
      • TABLES_INCLUDED : liste de tables (par exemple, "project1.dataset1.table 1", "project1.dataset2.table2"). Lorsque cette option est définie, la solution sauvegarde les tables spécifiées. Ce paramètre est ignoré si vous définissez les champs folders_include_list, projects_include_list ou datasets_include_list.
      • TABLES_EXCLUDED : liste de tables ou expression régulière (par exemple, "project1.dataset1.table 1", "regex:.*\_test"). Lorsque cette option est définie, la solution ne sauvegarde pas les tables spécifiées. Vous pouvez utiliser ce paramètre en combinaison avec les champs folders_include_list, projects_include_list ou datasets_include_list.

      Toutes les listes d'exclusion acceptent les expressions régulières au format regex:REGULAR_EXPRESSION.

      Si le nom complet de l'entrée (par exemple, "project.dataset.table") correspond à l'une des expressions régulières fournies, il est exclu du champ d'application de la sauvegarde.

      Voici quelques cas d'utilisation courants :

      • Excluez tous les noms d'ensembles de données qui se terminent par _landing : datasets_exclude_list = ["regex:.*\\_landing$"]
      • Excluez tous les tableaux se terminant par _test, _tst, _bkp ou _copy : tables_exclude_list = ["regex:.*\_(test|tst|bkp|copy)"]

    Définir des règles de remplacement

    À chaque exécution, la solution doit déterminer la règle de sauvegarde de chaque table concernée. Pour en savoir plus sur les types de règles, consultez Règles de sauvegarde. Cette section vous explique comment définir une règle de remplacement.

    Une règle de remplacement est définie avec une variable default_policy et un ensemble d'exceptions ou de remplacements à différents niveaux (dossier, projet, ensemble de données et tableau). Cette approche offre une flexibilité précise sans nécessiter d'entrée pour chaque table.

    Il existe des ensembles supplémentaires de champs de stratégie, en fonction de la méthode de sauvegarde que vous décidez d'utiliser : les instantanés BigQuery, les exportations vers Cloud Storage ou les deux.

    1. Dans le fichier TFVARS, pour la variable default_policy, définissez les champs courants suivants pour la règle par défaut :

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

      Remplacez les éléments suivants :

      • BACKUP_CRON : expression Cron permettant de définir la fréquence de sauvegarde d'une table (par exemple, pour des sauvegardes toutes les six heures, spécifiez 0 0 */6 * * *). Il doit s'agir d'une expression Cron compatible avec Spring-Framework.
      • BACKUP_METHOD : méthode que vous spécifiez comme BigQuery Snapshot, GCS Snapshot (pour utiliser la méthode d'exportation vers Cloud Storage) ou Both. Vous devez fournir les champs requis pour chaque méthode de sauvegarde choisie, comme indiqué plus loin.
      • OFFSET_DAYS : nombre de jours dans le passé qui détermine le point dans le temps à partir duquel sauvegarder les tables. Les valeurs peuvent être un nombre compris entre 0 et 7.
      • BACKUP_STORAGE_PROJECT : ID du projet dans lequel toutes les opérations d'instantané et d'exportation sont stockées. Il s'agit du même projet dans lequel résident bq_snapshot_storage_dataset et gcs_snapshot_storage_location. Les petits déploiements peuvent utiliser le projet hôte, mais les déploiements à grande échelle doivent utiliser un projet distinct.
      • BACKUP_OPERATIONS_PROJECT : paramètre facultatif permettant de spécifier l'ID du projet dans lequel toutes les opérations d'instantané et d'exportation sont exécutées. Les quotas et limites des tâches d'instantané et d'exportation s'appliquent à ce projet. Il peut s'agir de la même valeur que backup_storage_project. Si ce paramètre n'est pas défini, la solution utilise le projet de la table source.

    2. Si vous avez spécifié BigQuery Snapshot ou Both comme backup_method, ajoutez les champs suivants après les champs communs, dans la variable default_policy :

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

      Remplacez les éléments suivants :

      • SNAPSHOT_EXPIRATION : nombre de jours pendant lesquels conserver chaque instantané (par exemple, 15).
      • DATASET_NAME : nom de l'ensemble de données dans lequel stocker les instantanés (par exemple, backups). L'ensemble de données doit déjà exister dans le projet spécifié pour backup_storage_project.

    3. Si vous avez spécifié GCS Snapshot (pour utiliser la méthode d'exportation vers Cloud Storage) ou Both comme backup_method, ajoutez les champs suivants à 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

      Remplacez les éléments suivants :

      • STORAGE_BUCKET : bucket Cloud Storage dans lequel stocker les données exportées, au format gs://bucket/path/. Exemple : gs://bucket1/backups/.
      • FILE_FORMAT : format de fichier et compression utilisés pour exporter une table BigQuery vers Cloud Storage. Les valeurs disponibles sont CSV, CSV_GZIP, JSON, JSON_GZIP, AVRO, AVRO_DEFLATE, AVRO_SNAPPY, PARQUET, PARQUET_SNAPPY et PARQUET_GZIP.
      • AVRO_TYPE : valeur booléenne. Si la valeur est définie sur false, les types BigQuery sont exportés en tant que chaînes. Si la valeur est définie sur true, les types sont exportés en tant que types logiques Avro correspondants. Ce champ est obligatoire lorsque gcs_snapshot_format est un format de type Avro.
      • CSV_DELIMITER : délimiteur utilisé pour les fichiers CSV exportés. La valeur peut être n'importe quel caractère mono-octet ISO-8859-1. Vous pouvez utiliser \t ou tab pour spécifier des délimiteurs de tabulation. Ce champ est obligatoire lorsque le gcs_snapshot_format est un format de type CSV.
      • CSV_EXPORT_HEADER : valeur booléenne. Si la valeur est true, les en-têtes de colonne sont exportés vers les fichiers CSV. Ce champ est obligatoire lorsque le gcs_snapshot_format est un format CSV.

      Pour en savoir plus et connaître le mappage des types Avro, consultez le tableau suivant :

      Type BigQuery Type logique Avro
      TIMESTAMP timestamp-micros (annotation Avro LONG)
      DATE date (annotation Avro INT)
      TIME timestamp-micro (annotation Avro LONG)
      DATETIME STRING (type logique personnalisé nommé datetime)

    4. Ajoutez des variables de remplacement pour des dossiers, projets, ensembles de données et tables spécifiques :

        },
  "folder_overrides" : {
   "FOLDER_NUMBER" : {
   },
  },

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

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

  "table_overrides" : {
   "PROJECT_NAME.DATASET_NAME.TABLE_NAME" : {
   }
  }
}

      Remplacez les éléments suivants :

      • FOLDER_NUMBER : spécifiez le dossier pour lequel vous souhaitez définir des champs de remplacement.
      • PROJECT_NAME : spécifiez le projet lorsque vous définissez des champs de remplacement pour un projet, un ensemble de données ou une table spécifiques.
      • DATASET_NAME : spécifiez l'ensemble de données lorsque vous définissez des champs de remplacement pour un ensemble de données ou une table spécifiques.
      • TABLE_NAME : spécifiez la table pour laquelle vous souhaitez définir des champs de remplacement.

      Pour chaque entrée de remplacement, telle qu'un projet spécifique dans la variable project_overrides, ajoutez les champs communs et les champs obligatoires pour la méthode de sauvegarde que vous avez spécifiée précédemment dans default_policy.

      Si vous ne souhaitez pas définir de remplacement pour un niveau particulier, définissez cette variable sur une carte vide (par exemple, project_overrides : {}).

      Dans l'exemple suivant, les champs de remplacement sont définis pour une table spécifique qui utilise la méthode d'instantané 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"
    },
   }
}

    Pour obtenir un exemple complet de stratégie de secours, consultez le fichier example-variables.

    Configurer des projets d'opération de sauvegarde supplémentaires

    • Si vous souhaitez spécifier des projets de sauvegarde supplémentaires, tels que ceux définis dans des configurations externes (règle de sauvegarde au niveau de la table) ou les projets sources de la table, configurez la variable suivante :

      additional_backup_operation_projects = [ADDITIONAL_BACKUPS]

      Remplacez ADDITIONAL_BACKUPS par une liste de noms de projets séparés par une virgule (par exemple, "project1", "project2"). Si vous n'utilisez que la règle de sauvegarde de secours sans règles externes au niveau des tables, vous pouvez définir la valeur sur une liste vide.

      Si vous n'ajoutez pas ce champ, tous les projets spécifiés dans le champ facultatif backup_operation_project sont automatiquement inclus en tant que projets de sauvegarde.

    Configurer les autorisations du compte de service Terraform

    Au cours des étapes précédentes, vous avez configuré les projets de sauvegarde dans lesquels les opérations de sauvegarde s'exécutent. Terraform doit déployer des ressources dans ces projets de sauvegarde.

    Le compte de service utilisé par Terraform doit disposer des autorisations requises pour ces projets de sauvegarde spécifiés.

    • Dans Cloud Shell, accordez au compte de service les autorisations pour tous les projets dans lesquels les opérations de sauvegarde sont exécutées :

      ./scripts/prepare_backup_operation_projects_for_terraform.sh BACKUP_OPERATIONS_PROJECT DATA_PROJECTS ADDITIONAL_BACKUPS

      Remplacez les éléments suivants :

      • BACKUP_OPERATIONS_PROJECT : tous les projets définis dans les champs backup_operation_project de l'une des règles de remplacement et des règles au niveau des tables.
      • DATA_PROJECTS : si aucun champ backup_operation_project n'est défini dans une règle de remplacement ou au niveau de la table, incluez les projets pour ces tables sources.
      • ADDITIONAL_BACKUPS : tous les projets définis dans la variable Terraform additional_backup_operation_projects.

    Exécuter les scripts de déploiement

    1. Dans Cloud Shell, exécutez le script de déploiement 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. Ajoutez les règles de durée de vie (TTL) pour Firestore :

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

      La solution utilise Datastore comme cache dans certaines situations. Pour réduire les coûts et améliorer les performances de recherche, la règle TTL permet à Firestore de supprimer automatiquement les entrées expirées.

    Configurer l'accès aux sources et aux destinations

    1. Dans Cloud Shell, définissez les variables suivantes pour les comptes de service utilisés par la solution :

      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 vous avez modifié les noms par défaut dans Terraform, mettez à jour les adresses e-mail des comptes de service.

    2. Si vous avez défini le champ folders_include_list et que vous souhaitez définir le champ d'application de l'analyse BigQuery pour inclure certains dossiers, accordez les autorisations requises au niveau du dossier :

      ./scripts/prepare_data_folders.sh FOLDERS_INCLUDED

    3. Pour permettre à l'application d'exécuter les tâches nécessaires dans différents projets, accordez les autorisations requises sur chacun de ces projets :

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

      Remplacez les éléments suivants :

      • DATA_PROJECTS : projets de données (ou projets sources) contenant les tables sources que vous souhaitez sauvegarder (par exemple, project1 project2). Incluez les projets suivants :

        • Projets spécifiés dans les listes d'inclusion de la variable Terraform schedulers.
        • Si vous souhaitez sauvegarder des tables dans le projet hôte, incluez-le.

      • BACKUP_STORAGE_PROJECT : projets de stockage des sauvegardes (ou projets de destination) dans lesquels la solution stocke les sauvegardes (par exemple, project1 project2). Vous devez inclure les projets spécifiés dans les champs suivants :

        • Les champs backup_storage_project de toutes les règles de remplacement.
        • Les champs backup_storage_project de toutes les règles au niveau de la table.

        Incluez les projets de stockage de sauvegarde utilisés dans plusieurs champs ou qui sont utilisés à la fois comme projet source et de destination.

      • BACKUP_OPERATIONS_PROJECT : projets d'opération de données dans lesquels la solution exécute les opérations de sauvegarde (par exemple, project1 project2). Vous devez inclure les projets spécifiés dans les champs suivants :

        • Les champs backup_operation_project de toutes les règles de remplacement.
        • Toutes les listes d'inclusion dans le champ d'application de l'analyse BigQuery (si vous ne définissez pas le champ backup_operation_project).
        • Les champs backup_operation_project dans toutes les règles au niveau de la table.

        Incluez les projets d'opérations de sauvegarde utilisés dans plusieurs champs ou à la fois comme projet source et de destination.

    4. Pour les tables qui utilisent le contrôle des accès au niveau des colonnes, identifiez toutes les taxonomies de tags avec stratégie utilisées par vos tables (le cas échéant), puis accordez aux comptes de service de la solution l'accès aux données des tables :

      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'

      Remplacez les éléments suivants :

      • TAXONOMY_PROJECT : ID du projet dans la taxonomie des tags de règles
      • TAXONOMY_LOCATION : emplacement spécifié dans la taxonomie des balises de règles
      • TAXONOMY_ID : ID de taxonomie de la taxonomie des tags de règle

    5. Répétez l'étape précédente pour chaque taxonomie de tags de règles.

    Exécuter la solution

    Après avoir déployé la solution, utilisez les sections suivantes pour l'exécuter et la gérer.

    Définir des règles de sauvegarde au niveau des tables

    • Dans Cloud Shell, créez une règle au niveau de la table avec les champs requis, puis stockez-la dans le bucket Cloud Storage pour les règles :

      # 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

      Remplacez les éléments suivants :

      • TABLE_PROJECT : projet dans lequel se trouve la table
      • TABLE_DATASET : ensemble de données de la table
      • TABLE_NAME : nom de la table

    Déclencher des opérations de sauvegarde

    Les tâches Cloud Scheduler que vous avez configurées précédemment s'exécutent automatiquement en fonction de leur expression cron.

    Vous pouvez également exécuter manuellement les jobs dans la console Google Cloud . Pour en savoir plus, consultez Exécuter votre job.

    Surveiller et signaler

    Une fois votre projet hôte (PROJECT_ID) sélectionné, vous pouvez exécuter les requêtes suivantes dans BigQuery Studio pour obtenir des rapports et des informations.

    • Obtenez des statistiques de progression pour chaque exécution (y compris celles en cours) :

      SELECT * FROM `bq_backup_manager.v_run_summary_counts`

    • Obtenir toutes les erreurs fatales (non réessayables) pour une seule exécution :

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

      Remplacez RUN_ID par l'ID de l'exécution.

    • Obtenez toutes les exécutions d'un tableau et leurs informations d'exécution :

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

      Vous pouvez également spécifier une version grouped :

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

    • Pour le débogage, vous pouvez obtenir des informations détaillées sur les requêtes et les réponses pour chaque appel de service :

      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"

    • Obtenez les règles de sauvegarde ajoutées manuellement ou attribuées par le système en fonction des solutions de repli :

      SELECT * FROM `bq_backup_manager.ext_backup_policies`

    Limites

    Pour en savoir plus sur les limites et les quotas de chaque projet spécifié dans les champs backup_operation_project, consultez Limites.

    Effectuer un nettoyage

    Pour éviter que les ressources utilisées dans le cadre de ce déploiement soient facturées sur votre compte Google Cloud , supprimez les projets contenant les ressources, ou conservez les projets et supprimez les ressources individuelles.

    Supprimer les projets

      Delete a Google Cloud project:

      gcloud projects delete PROJECT_ID

    Supprimer les nouvelles ressources

    Au lieu de supprimer les projets, vous pouvez supprimer les ressources créées au cours de cette procédure.

    • Dans Cloud Shell, supprimez les ressources Terraform :

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

      La commande supprime la quasi-totalité des ressources. Vérifiez que toutes les ressources que vous souhaitez supprimer ont bien été supprimées.

    Étapes suivantes

    Contributeurs

    Auteur : Karim Wadie | Ingénieur stratégique Cloud

    Autres contributeurs :