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, ingénieurs et responsables de la gouvernance des données cloud qui souhaitent définir et automatiser des règles de données dans leur organisation. L'expérience de Terraform est utile.

Architecture

Le diagramme suivant illustre l'architecture de sauvegarde automatique:

Architecture de la solution de sauvegarde automatisée.

Cloud Scheduler déclenche l'exécution. Le service de distribution, à l'aide de l'API BigQuery, répertorie les tables concernées. Via un message Pub/Sub, le service de distribution envoie une requête pour chaque table 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 approprié. 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 consigne 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 de la sauvegarde BigQuery évolutive.

Objectifs

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

Coûts

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

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 projet hôte Google Cloud sur lequel vous souhaitez déployer la solution.
    • COMPUTE_REGION: région Google Cloud 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:

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

  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"

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 le dernier codebase dans l'environnement Google Cloud.

Activer la configuration de gcloud CLI

  • Dans Cloud Shell, activez et authentifiez la configuration de 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 des 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 la section 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ée ultérieurement.

    Terraform n'associe un service Cloud Run qu'à une image existante. Il ne compile pas les images à partir du codebase, car cela a été effectué à 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 de sauvegarde Cron au niveau de la table.

    {
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 de 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 calendriers de sauvegarde individuels. Il peut s'agir de n'importe quelle chaîne compatible avec unix-cron. Par exemple, 0 * * * * correspond à 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. Si la valeur est true, aucune opération de sauvegarde n'est effectuée. Seuls les messages de journal sont générés. Utilisez true lorsque vous souhaitez tester et déboguer la solution sans avoir à supporter les coûts de sauvegarde.
    • FOLDERS_INCLUDED: liste d'ID numériques pour les dossiers contenant des données BigQuery (par exemple, 1234, 456). Lorsqu'elle est définie, la solution sauvegarde les tables dans les 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"). Une fois 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 d'expressions régulières (par exemple, "project1", "regex:^test_"). Lorsque cette valeur est définie, la solution ne crée pas de sauvegardes des tables des projets spécifiés. Vous pouvez utiliser ce paramètre avec le champ folders_include_list.
    • DATASETS_INCLUDED: liste d'ensembles de données (par exemple, "project1.dataset1", "project1.dataset2"). Lorsqu'elle 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 valeur est définie, la solution ne crée pas de sauvegardes des 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"). Lorsqu'elle 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"). Lorsqu'elle est définie, la solution ne crée pas de sauvegardes des 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 d'entrée complet (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 se terminant par _landing: datasets_exclude_list = ["regex:.*\\_landing$"]
    • Excluez toutes les tables 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 stratégie de sauvegarde de chaque table concernée. Pour en savoir plus sur les types de règles, consultez la page Règles de sauvegarde. Cette section vous explique comment définir une stratégie de remplacement.

Une stratégie de remplacement est définie avec une variable default_policy et un ensemble d'exceptions ou de forçages à différents niveaux (dossier, projet, ensemble de données et table). Cette approche offre une flexibilité précise sans avoir à saisir une entrée pour chaque table.

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

  1. Dans le fichier TFVARS, pour la variable default_policy, définissez les champs communs suivants pour la stratégie 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 les sauvegardes toutes les six heures, spécifiez 0 0 */6 * * *). Il doit s'agir d'une expression cron compatible avec Spring-Framework.
    • BACKUP_METHOD: la 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 renseigner les champs obligatoires pour chaque méthode de sauvegarde choisie, comme indiqué plus loin.
    • OFFSET_DAYS: nombre de jours dans le passé qui détermine le point de départ de la sauvegarde des 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 que 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 dans lequel vous spécifiez l'ID du projet dans lequel toutes les opérations d'instantané et d'exportation s'exécutent. Les quotas et limites des tâches d'exportation et d'instantané 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 à 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 false, les types BigQuery sont exportés sous forme de chaînes. Si la valeur est true, les types sont exportés en tant que type logique Avro correspondant. 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 ISO-8859-1 à un octet. Vous pouvez utiliser \t ou tab pour spécifier des délimiteurs de tabulation. Ce champ est obligatoire lorsque 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 gcs_snapshot_format est un format de type 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 (annote LONG Avro)
    DATE date (annote INT Avro)
    TIME timestamp-micro (annote LONG Avro)
    DATETIME STRING (type logique nommé personnalisé datetime)

  4. Ajoutez des variables de forçage pour des dossiers, des projets, des ensembles de données et des 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 forçage.
    • PROJECT_NAME: spécifiez le projet lorsque vous définissez des champs de forçage 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 forçage pour un ensemble de données ou une table spécifique.
    • TABLE_NAME: spécifiez la table pour laquelle vous souhaitez définir des champs de forçage.

    Pour chaque entrée de forçage, comme 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 forçages pour un niveau particulier, définissez cette variable sur une carte vide (par exemple, project_overrides : {}).

    Dans l'exemple suivant, des champs de forçage 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 d'une stratégie de remplacement, consultez le fichier example-variables.

Configurer des projets d'opérations 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 de source de 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 des virgules (par exemple, "project1", "project2"). Si vous n'utilisez que la stratégie de sauvegarde de remplacement sans stratégies externes au niveau de la table, 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 backup_operation_project facultatif 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 les autorisations au compte de service pour tous les projets dans lesquels les opérations de sauvegarde s'exécutent:

    ./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 de la table.
    • DATA_PROJECTS: si aucun champ backup_operation_project n'est défini dans une stratégie 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 valeur TTL (Time To Live) 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 arrivées à expiration.

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 e-mails du compte de service.

  2. Si vous avez défini le champ folders_include_list et que vous souhaitez définir la portée 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: les 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 projet hôte.

    • BACKUP_STORAGE_PROJECT: projets de stockage de sauvegarde (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 utilisés à la fois comme projet source et de destination.

    • BACKUP_OPERATIONS_PROJECT: projets d'opérations 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 de toutes les règles au niveau de la table.

      Incluez les projets d'opérations de sauvegarde utilisés dans plusieurs champs ou utilisés à 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) et accordez aux comptes de service de la solution l'accès aux données de la table:

    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 balises de règles
    • TAXONOMY_LOCATION: emplacement spécifié dans la taxonomie des balises de stratégie
    • TAXONOMY_ID: ID de taxonomie de la taxonomie de tags avec stratégie

  5. Répétez l'étape précédente pour chaque taxonomie de balise 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 stratégie au niveau de la table avec les champs requis, puis stockez-la dans le bucket Cloud Storage pour les stratégies:

    # Use the default backup policies bucket unless overwritten in the .tfvars
export POLICIES_BUCKET=${PROJECT_ID}-bq-backup-manager-policies

# set target table info
export TABLE_PROJECT='TABLE_PROJECT'
export TABLE_DATASET='TABLE_DATASET'
export TABLE='TABLE_NAME'

# Config Source must be 'MANUAL' when assigned this way
export BACKUP_POLICY="{
'config_source' : 'MANUAL',
'backup_cron' : 'BACKUP_CRON',
'backup_method' : 'BACKUP_METHOD',
'backup_time_travel_offset_days' : 'OFFSET_DAYS',
'backup_storage_project' : 'BACKUP_STORAGE_PROJECT',
'backup_operation_project' : 'BACKUP_OPERATION_PROJECT',
'gcs_snapshot_storage_location' : 'STORAGE_BUCKET',
'gcs_snapshot_format' : 'FILE_FORMAT',
'gcs_avro_use_logical_types' : 'AVRO_TYPE',
'bq_snapshot_storage_dataset' : 'DATASET_NAME',
'bq_snapshot_expiration_days' : 'SNAPSHOT_EXPIRATION'
}"

# File name MUST BE backup_policy.json
echo $BACKUP_POLICY >> backup_policy.json

gsutil cp backup_policy.json gs://${POLICIES_BUCKET}/policy/project=${TABLE_PROJECT}/dataset=${TABLE_DATASET}/table=${TABLE}/backup_policy.json

    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 la section Exécuter votre tâche.

Surveillance et création de rapports

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 les statistiques de progression de chaque exécution (y compris les exécutions en cours):

    SELECT * FROM `bq_backup_manager.v_run_summary_counts`

  • Obtenir toutes les erreurs fatales (erreurs non répétables) 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'une table 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 qui sont ajoutées manuellement ou attribuées par le système en fonction des solutions de remplacement:

    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 la section Limites.

Effectuer un nettoyage

Pour éviter que les ressources utilisées dans 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

  1. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. In the dialog, type the project ID, and then click Shut down to delete the project.

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 presque toutes les ressources. Vérifiez que toutes les ressources que vous souhaitez supprimer ont été supprimées.

Étape suivante

Contributeurs

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

Autres contributeurs :