Diese Seite wurde von der Cloud Translation API übersetzt.

Skalierbare BigQuery-Sicherungsautomatisierung bereitstellen

Last reviewed 2024-09-17 UTC

In diesem Dokument wird beschrieben, wie Sie eine skalierbare BigQuery-Sicherungsautomatisierung bereitstellen.

Dieses Dokument richtet sich an Cloud-Architekten, Entwickler und Datengovernance-Beauftragte, die Datenrichtlinien in ihren Organisationen definieren und automatisieren möchten. Erfahrung mit Terraform ist hilfreich.

Architektur

Das folgende Diagramm zeigt die Architektur der automatischen Sicherung:

Architektur für die automatisierte Sicherungslösung.

Cloud Scheduler löst die Ausführung aus. Der Dispatcherdienst listet mithilfe der BigQuery API die entsprechenden Tabellen auf. Über eine Pub/Sub-Nachricht sendet der Dispatcherdienst eine Anfrage für jede Tabelle an den Konfigurationsservice. Der Konfigurations-Dienst ermittelt die Sicherungsrichtlinien für die Tabellen und sendet dann eine Anfrage für jede Tabelle an den entsprechenden Cloud Run-Dienst. Der Cloud Run-Dienst sendet dann eine Anfrage an die BigQuery API und führt die Sicherungsvorgänge aus. Pub/Sub löst den Tagging-Dienst aus, der die Ergebnisse protokolliert und den Sicherungsstatus in der Cloud Storage-Metadatenebene aktualisiert.

Weitere Informationen zur Architektur finden Sie unter Skalierbare BigQuery-Sicherungsautomatisierung.

Lernziele

Cloud Run-Dienste erstellen
Konfigurieren Sie Terraform-Variablen.
Führen Sie die Terraform- und manuellen Bereitstellungsscripts aus.
Führen Sie die Lösung aus.

Kosten

In diesem Dokument verwenden Sie die folgenden kostenpflichtigen Komponenten von Google Cloud:

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen. Neuen Google Cloud-Nutzern steht möglicherweise eine kostenlose Testversion zur Verfügung.

Nach Abschluss der in diesem Dokument beschriebenen Aufgaben können Sie weitere Kosten vermeiden, indem Sie die erstellten Ressourcen löschen. Weitere Informationen finden Sie unter Bereinigen.

Hinweise

Wenn Sie die Lösung neu bereitstellen, können Sie diesen Abschnitt überspringen (z. B. nach neuen Commits).

In diesem Abschnitt erstellen Sie einmalige Ressourcen.

In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell
Wenn Sie ein neues Google Cloud-Projekt als Hostprojekt für die Bereitstellung erstellen möchten, verwenden Sie den Befehl gcloud projects create:
```
   gcloud projects create PROJECT_ID
```
Ersetzen Sie PROJECT_ID durch die ID des Projekts, das Sie erstellen möchten.
Installieren Sie Maven:
1. Laden Sie Maven herunter.
2. Fügen Sie in Cloud Shell Maven zu PATH hinzu:
```
export PATH=/DOWNLOADED_MAVEN_DIR/bin:$PATH
```

Klonen Sie in Cloud Shell das GitHub-Repository:

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

Legen Sie die folgenden Umgebungsvariablen fest und exportieren Sie sie:

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

Ersetzen Sie Folgendes:

PROJECT_ID: die ID des Google Cloud-Hostprojekts, in dem Sie die Lösung bereitstellen möchten.
COMPUTE_REGION: die Google Cloud-Region, in der Sie Compute-Ressourcen wie Cloud Run und Identity and Access Management (IAM) bereitstellen möchten.
DATA_REGION: Die Google Cloud-Region, in der Sie Datenressourcen wie Buckets und Datensätze bereitstellen möchten.
ACCOUNT_EMAIL: die E-Mail-Adresse des Nutzerkontos.

APIs aktivieren:
```
./scripts/enable_gcp_apis.sh
```
Das Script aktiviert die folgenden APIs:
- 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 API

Bucket für den Terraform-Zustand vorbereiten:

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

Bereiten Sie das Terraform-Dienstkonto vor:

./scripts/prepare_terraform_service_account.sh

Um Images zu veröffentlichen, die von dieser Lösung verwendet werden, müssen Sie ein Docker-Repository vorbereiten:

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

Stellen Sie die Infrastruktur bereit:

Sie müssen den Abschnitt Vorbereitung mindestens einmal durchlaufen haben.

Folgen Sie in diesem Abschnitt der Anleitung, um die neueste Codebasis in der Google Cloud-Umgebung bereitzustellen oder neu bereitzustellen.

gcloud CLI-Konfiguration aktivieren

Aktivieren und authentifizieren Sie in Cloud Shell die gcloud-Befehlszeilenkonfiguration:

gcloud config configurations activate $CONFIG

gcloud auth login
gcloud auth application-default login

Cloud Run-Dienst-Images erstellen

Erstellen und stellen Sie in Cloud Shell Docker-Images bereit, die vom Cloud Run-Dienst verwendet werden sollen:

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

Terraform-Variablen konfigurieren

Bei dieser Bereitstellung wird Terraform für Konfigurationen und ein Bereitstellungsskript verwendet.

Erstellen Sie in Cloud Shell eine neue Terraform-TFVARS-Datei, in der Sie die Variablen in diesem Abschnitt überschreiben können:
```
export VARS=FILENAME
.tfvars
```
Ersetzen Sie FILENAME durch den Namen der von Ihnen erstellten Variablendatei, z. B. my-variables. Sie können die Datei example-variables als Referenz verwenden.
Konfigurieren Sie in der TFVARS-Datei die Projektvariablen:
```
project = "PROJECT_ID"
compute_region = "COMPUTE_REGION"
data_region = "DATA_REGION"
```
Sie können die in der Datei variables.tf definierten Standardwerte verwenden oder die Werte ändern.
Konfigurieren Sie das Terraform-Dienstkonto, das Sie zuvor unter Vorbereitung erstellt und vorbereitet haben:
```
terraform_service_account =
"bq-backup-mgr-terraform@PROJECT_ID.iam.gserviceaccount.com"
```
Verwenden Sie die vollständige E-Mail-Adresse des Kontos, das Sie erstellt haben.

Konfigurieren Sie die Cloud Run-Dienste so, dass die Container-Images verwendet werden, die Sie zuvor erstellt und bereitgestellt haben:

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"

Dieses Script weist Terraform an, diese veröffentlichten Images in den Cloud Run-Diensten zu verwenden, die Terraform später erstellt.

Terraform verknüpft einen Cloud Run-Dienst nur mit einem vorhandenen Image. Die Images werden nicht aus der Codebasis erstellt, da dies in einem vorherigen Schritt geschehen ist.

Definieren Sie in der Variablen schedulers mindestens einen Scheduler. Der Scheduler listet Tabellen basierend auf ihren Cron-Sicherungszeitplänen auf Tabellenebene regelmäßig auf und prüft sie auf erforderliche Sicherungen.
```
{
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]
    }
}
```
Ersetzen Sie Folgendes:
- SCHEDULER_NAME: Der Anzeigename des Cloud Scheduler.
- SCHEDULER_CRON: die Häufigkeit, mit der der Planer basierend auf den individuellen Sicherungszeitplänen prüft, ob für die betroffenen Tabellen eine Sicherung ansteht. Dies kann ein beliebiger Unix-Cron-kompatibler String sein. 0 * * * * ist beispielsweise eine stündliche Häufigkeit.
- FORCE_RUN: ein boolescher Wert. Legen Sie den Wert auf false fest, wenn der Scheduler die Cron-Zeitpläne der Tabellen verwenden soll. Wenn diese Einstellung auf true festgelegt ist, werden alle betroffenen Tabellen unabhängig von ihrer Cron-Einstellung gesichert.
- DRY_RUN: ein boolescher Wert. Wenn dieser Wert auf true gesetzt ist, werden keine Sicherungsvorgänge ausgeführt. Es werden nur Protokollmeldungen generiert. Verwenden Sie true, wenn Sie die Lösung testen und beheben möchten, ohne Sicherungskosten zu verursachen.
- FOLDERS_INCLUDED: Eine Liste mit numerischen IDs für Ordner, die BigQuery-Daten enthalten (z. B. 1234, 456). Wenn diese Option festgelegt ist, werden die Tabellen in den angegebenen Ordnern gesichert und die Feldeinstellungen projects_include_list, datasets_include_list und tables_include_list werden ignoriert.
- PROJECTS_INCLUDED: eine Liste von Projektnamen (z. B. "project1", "project2"). Wenn diese Option festgelegt ist, werden die Tabellen in den angegebenen Projekten gesichert und die Feldeinstellungen datasets_include_list und tables_include_list werden ignoriert. Diese Einstellung wird ignoriert, wenn Sie das Feld folders_include_list festlegen.
- PROJECTS_EXCLUDED: eine Liste von Projektnamen oder regulären Ausdrücken (z. B. "project1", "regex:^test_"). Wenn diese Option festgelegt ist, werden von der Lösung keine Sicherungen der Tabellen in den angegebenen Projekten erstellt. Sie können diese Einstellung in Kombination mit dem Feld folders_include_list verwenden.
- DATASETS_INCLUDED: eine Liste von Datasets (z. B. "project1.dataset1", "project1.dataset2"). Wenn diese Option festgelegt ist, werden die Tabellen in den angegebenen Datasets gesichert und die Feldeinstellung tables_include_list wird ignoriert. Diese Einstellung wird ignoriert, wenn Sie die Felder folders_include_list oder projects_include_list festlegen.
- DATASETS_EXCLUDED: Eine Liste von Datasets oder ein regulärer Ausdruck (z. B. "project1.dataset1", "regex:.*\\_landing$"). Wenn diese Option festgelegt ist, werden von der Lösung keine Sicherungen der Tabellen in den angegebenen Datasets erstellt. Sie können diese Einstellung in Kombination mit den Feldern folders_include_list oder projects_include_list verwenden.
- TABLES_INCLUDED: eine Liste von Tabellen (z. B. "project1.dataset1.table 1", "project1.dataset2.table2"). Wenn diese Option festgelegt ist, werden die angegebenen Tabellen von der Lösung gesichert. Diese Einstellung wird ignoriert, wenn Sie die Felder folders_include_list, projects_include_list oder datasets_include_list festlegen.
- TABLES_EXCLUDED: Liste von Tabellen oder regulärer Ausdruck (z. B. "project1.dataset1.table 1", "regex:.*\_test"). Wenn diese Option festgelegt ist, werden von der Lösung keine Sicherungen der angegebenen Tabellen erstellt. Sie können diese Einstellung in Kombination mit den Feldern folders_include_list, projects_include_list oder datasets_include_list verwenden.
Für alle Ausschlusslisten sind reguläre Ausdrücke vom Typ regex:REGULAR_EXPRESSION zulässig.

Wenn der voll qualifizierte Name des Eintrags (z. B. "project.dataset.table") mit einem der angegebenen regulären Ausdrücke übereinstimmt, wird er vom Sicherungsbereich ausgeschlossen.

Im Folgenden sind einige gängige Anwendungsfälle aufgeführt:
- Alle Datensatznamen ausschließen, die auf _landing enden: datasets_exclude_list = ["regex:.*\\_landing$"]
- Alle Tabellen ausschließen, die auf _test, _tst, _bkp oder _copy enden: tables_exclude_list = ["regex:.*\_(test|tst|bkp|copy)"]

Fallback-Richtlinien definieren

Bei jedem Durchlauf muss die Lösung die Sicherungsrichtlinie für jede infrage kommende Tabelle ermitteln. Weitere Informationen zu den verschiedenen Arten von Richtlinien finden Sie unter Sicherungsrichtlinien. In diesem Abschnitt erfahren Sie, wie Sie eine Fallback-Richtlinie definieren.

Eine Fallback-Richtlinie wird mit einer default_policy-Variablen und einer Reihe von Ausnahmen oder Überschreibungen auf verschiedenen Ebenen (Ordner, Projekt, Datensatz und Tabelle) definiert. Dieser Ansatz bietet eine detaillierte Flexibilität, ohne dass für jede Tabelle ein Eintrag erforderlich ist.

Je nach gewählter Sicherungsmethode (BigQuery-Snapshots, Exporte in Cloud Storage oder beides) gibt es zusätzliche Richtlinienfelder.

Legen Sie in der TFVARS-Datei für die Variable default_policy die folgenden allgemeinen Felder für die Standardrichtlinie fest:
```
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",
```
Ersetzen Sie Folgendes:
- BACKUP_CRON: Ein Cron-Ausdruck, mit dem die Häufigkeit festgelegt wird, mit der eine Tabelle gesichert wird. Geben Sie beispielsweise 0 0 */6 * * * für Sicherungen alle 6 Stunden an. Dies muss ein mit dem Spring-Framework kompatibler Cron-Ausdruck sein.
- BACKUP_METHOD: die Methode, die Sie als BigQuery Snapshot, GCS Snapshot (für den Export in Cloud Storage) oder Both angeben. Sie müssen die erforderlichen Felder für jede ausgewählte Sicherungsmethode angeben, wie unten gezeigt.
- OFFSET_DAYS: Die Anzahl der Tage in der Vergangenheit, die den Zeitpunkt bestimmt, ab dem die Tabellen gesichert werden. Die Werte können eine Zahl zwischen 0 und 7 sein.
- BACKUP_STORAGE_PROJECT: die ID des Projekts, in dem alle Snapshot- und Exportvorgänge gespeichert sind. Das ist dasselbe Projekt, in dem sich bq_snapshot_storage_dataset und gcs_snapshot_storage_location befinden. Für kleine Bereitstellungen kann das Hostprojekt verwendet werden, für große Bereitstellungen sollte jedoch ein separates Projekt verwendet werden.
- BACKUP_OPERATIONS_PROJECT: Optionale Einstellung, mit der Sie die ID des Projekts angeben, in dem alle Snapshot- und Exportvorgänge ausgeführt werden. Für dieses Projekt gelten die Kontingente und Limits für Snapshot- und Exportjobs. Dieser kann mit backup_storage_project identisch sein. Wenn nicht festgelegt, verwendet die Lösung das Projekt der Quelltabelle.
Wenn Sie BigQuery Snapshot oder Both als backup_method angegeben haben, fügen Sie in der Variablen default_policy nach den gemeinsamen Feldern die folgenden Felder hinzu:
```
  "bq_snapshot_expiration_days" : "SNAPSHOT_EXPIRATION",
  "bq_snapshot_storage_dataset" : "DATASET_NAME",
```
Ersetzen Sie Folgendes:
- SNAPSHOT_EXPIRATION: die Anzahl der Tage, für die jeder Snapshot aufbewahrt werden soll (z. B. 15).
- DATASET_NAME: der Name des Datasets, in dem Snapshots gespeichert werden sollen (z. B. backups). Das Dataset muss bereits im für backup_storage_project angegebenen Projekt vorhanden sein.

Wenn Sie GCS Snapshot (für die Methode „Nach Cloud Storage exportieren“) oder Both als backup_method angegeben haben, fügen Sie der Variablen default_policy die folgenden Felder hinzu:

  "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

Ersetzen Sie Folgendes:

STORAGE_BUCKET: Der Cloud Storage-Bucket, in dem die exportierten Daten gespeichert werden sollen, im Format gs://bucket/path/. Beispiel: gs://bucket1/backups/.
FILE_FORMAT: Dateiformat und Komprimierung, die zum Exportieren einer BigQuery-Tabelle in Cloud Storage verwendet werden. Verfügbare Werte sind CSV, CSV_GZIP, JSON, JSON_GZIP, AVRO, AVRO_DEFLATE, AVRO_SNAPPY, PARQUET, PARQUET_SNAPPY und PARQUET_GZIP.
AVRO_TYPE: ein boolescher Wert. Wenn „false“ festgelegt ist, werden die BigQuery-Typen als Strings exportiert. Wenn true festgelegt ist, werden die Typen als entsprechender logischer Avro-Typ exportiert. Dieses Feld ist erforderlich, wenn gcs_snapshot_format ein Avro-Typformat ist.
CSV_DELIMITER: Das Trennzeichen, das für die exportierten CSV-Dateien verwendet wird. Der Wert kann ein beliebiges ISO-8859-1-Einzelbytezeichen sein. Sie können \t oder tab verwenden, um Tabulatortrennzeichen anzugeben. Dieses Feld ist erforderlich, wenn gcs_snapshot_format ein CSV-Format ist.
CSV_EXPORT_HEADER: ein boolescher Wert. Wenn true festgelegt ist, werden die Spaltenüberschriften in die CSV-Dateien exportiert. Dieses Feld ist erforderlich, wenn gcs_snapshot_format ein CSV-Format ist.

Weitere Informationen und die Zuordnung von Avro-Typen finden Sie in der folgenden Tabelle:

BigQuery-Typ	Logischer Avro-Typ
`TIMESTAMP`	`timestamp-micros` (Avro-Anmerkungen `LONG`)
`DATE`	`date` (Avro-Anmerkungen `INT`)
`TIME`	`timestamp-micro` (Avro-Anmerkungen `LONG`)
`DATETIME`	`STRING` (benutzerdefinierter logischer Typ `datetime`)

Fügen Sie Überschreibungsvariablen für bestimmte Ordner, Projekte, Datensätze und Tabellen hinzu:
```
  },
  "folder_overrides" : {
   "FOLDER_NUMBER" : {
   },
  },

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

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

  "table_overrides" : {
   "PROJECT_NAME.DATASET_NAME.TABLE_NAME" : {
   }
  }
}
```
Ersetzen Sie Folgendes:
- FOLDER_NUMBER: Geben Sie den Ordner an, für den Sie Überschreibungsfelder festlegen möchten.
- PROJECT_NAME: Geben Sie das Projekt an, wenn Sie Überschreibungsfelder für ein bestimmtes Projekt, Dataset oder eine bestimmte Tabelle festlegen.
- DATASET_NAME: Geben Sie das Dataset an, wenn Sie Überschreibungsfelder für ein bestimmtes Dataset oder eine bestimmte Tabelle festlegen.
- TABLE_NAME: Geben Sie die Tabelle an, für die Sie Überschreibungsfelder festlegen möchten.
Fügen Sie für jeden Überschreibungseintrag, z. B. ein bestimmtes Projekt in der Variablen project_overrides, die allgemeinen Felder und die erforderlichen Felder für die Sicherungsmethode hinzu, die Sie zuvor in default_policy angegeben haben.

Wenn Sie keine Überschreibungen für eine bestimmte Ebene festlegen möchten, setzen Sie diese Variable auf eine leere Map (z. B. project_overrides : {}).

Im folgenden Beispiel werden Überschreibungsfelder für eine bestimmte Tabelle festgelegt, für die die BigQuery-Snapshot-Methode verwendet wird:
```
  },
  "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"
    },
   }
}
```

Ein vollständiges Beispiel für eine Fallback-Richtlinie finden Sie in der Datei example-variables.

Zusätzliche Projekte für Sicherungsvorgänge konfigurieren

Wenn Sie zusätzliche Sicherungsprojekte angeben möchten, z. B. solche, die in externen Konfigurationen (Sicherungsrichtlinie auf Tabellenebene) oder in den Tabellenquellenprojekten definiert sind, konfigurieren Sie die folgende Variable:
```
additional_backup_operation_projects = [ADDITIONAL_BACKUPS]
```
Ersetzen Sie ADDITIONAL_BACKUPS durch eine durch Kommas getrennte Liste von Projektnamen (z. B. "project1", "project2"). Wenn Sie nur die Fallback-Sicherungsrichtlinie ohne externe Richtlinien auf Tabellenebene verwenden, können Sie den Wert auf eine leere Liste festlegen.

Wenn Sie dieses Feld nicht hinzufügen, werden alle Projekte, die im optionalen Feld backup_operation_project angegeben sind, automatisch als Sicherungsprojekte hinzugefügt.

Berechtigungen für das Terraform-Dienstkonto konfigurieren

In den vorherigen Schritten haben Sie die Sicherungsprojekte konfiguriert, in denen die Sicherungsvorgänge ausgeführt werden. Terraform muss Ressourcen in diesen Sicherungsprojekten bereitstellen.

Das von Terraform verwendete Dienstkonto muss die erforderlichen Berechtigungen für diese angegebenen Sicherungsprojekte haben.

Gewähren Sie dem Dienstkonto in Cloud Shell Berechtigungen für alle Projekte, in denen Sicherungsvorgänge ausgeführt werden:
```
./scripts/prepare_backup_operation_projects_for_terraform.sh BACKUP_OPERATIONS_PROJECT DATA_PROJECTS ADDITIONAL_BACKUPS
```
Ersetzen Sie Folgendes:
- BACKUP_OPERATIONS_PROJECT: Alle Projekte, die in den backup_operation_project-Feldern in den Fallback-Richtlinien und den Richtlinien auf Tabellenebene definiert sind.
- DATA_PROJECTS: Wenn in einer Fallback-Richtlinie oder einer Richtlinie auf Tabellenebene kein backup_operation_project-Feld definiert ist, fügen Sie die Projekte für diese Quelltabellen hinzu.
- ADDITIONAL_BACKUPS: Alle Projekte, die in der Terraform-Variablen additional_backup_operation_projects definiert sind.

Bereitstellungsscripts ausführen

Führen Sie in Cloud Shell das Terraform-Bereitstellungsskript aus:

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

Fügen Sie die Richtlinien zur Gültigkeitsdauer (TTL) für Firestore hinzu:
```
gcloud firestore fields ttls update expires_at \
    --collection-group=project_folder_cache \
    --enable-ttl \
    --async \
    --project=$PROJECT_ID
```
In einigen Fällen wird der Datastore als Cache verwendet. Um Kosten zu sparen und die Suchleistung zu verbessern, kann Firestore mithilfe der TTL-Richtlinie Einträge automatisch löschen, die abgelaufen sind.

Zugriff auf Quellen und Ziele einrichten

Legen Sie in Cloud Shell die folgenden Variablen für die von der Lösung verwendeten Dienstkonten fest:

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

Wenn Sie die Standardnamen in Terraform geändert haben, aktualisieren Sie die E-Mail-Adressen des Dienstkontos.

Wenn Sie das Feld folders_include_list festgelegt haben und den Umfang der BigQuery-Suche auf bestimmte Ordner beschränken möchten, gewähren Sie die erforderlichen Berechtigungen auf Ordnerebene:
```
./scripts/prepare_data_folders.sh FOLDERS_INCLUDED
```
Damit die Anwendung die erforderlichen Aufgaben in verschiedenen Projekten ausführen kann, gewähren Sie für jedes dieser Projekte die erforderlichen Berechtigungen:
```
./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
```
Ersetzen Sie Folgendes:
- DATA_PROJECTS: die Datenprojekte (oder Quellprojekte), die die Quelltabellen enthalten, die Sie sichern möchten (z. B. project1 project2). Geben Sie die folgenden Projekte an:
  - Projekte, die in den Einschlusslisten in der Terraform-Variablen schedulers angegeben sind.
  - Wenn Sie Tabellen im Hostprojekt sichern möchten, müssen Sie das Hostprojekt angeben.
- BACKUP_STORAGE_PROJECT: die Sicherungsspeicherprojekte (oder Zielprojekte), in denen die Lösung die Sicherungen speichert (z. B. project1 project2). Sie müssen die Projekte angeben, die in den folgenden Feldern angegeben sind:
  - Die backup_storage_project-Felder in allen Fallback-Richtlinien.
  - Die backup_storage_project-Felder in allen Richtlinien auf Tabellenebene.
  Fügen Sie Sicherungsspeicherprojekte hinzu, die in mehreren Feldern verwendet werden oder sowohl als Quell- als auch als Zielprojekt verwendet werden.
- BACKUP_OPERATIONS_PROJECT: Die Datenoperationen-Projekte, in denen die Lösung die Sicherungsvorgänge ausführt (z. B. project1 project2). Sie müssen die Projekte angeben, die in den folgenden Feldern angegeben sind:
  - Die backup_operation_project-Felder in allen Fallback-Richtlinien.
  - Alle Einschlusslisten im Umfang des BigQuery-Scans (wenn Sie das Feld backup_operation_project nicht festlegen)
  - Die backup_operation_project-Felder in allen Richtlinien auf Tabellenebene.
  Fügen Sie Projekte für Sicherungsvorgänge hinzu, die in mehreren Feldern verwendet werden oder sowohl als Quell- als auch als Zielprojekt verwendet werden.
Ermitteln Sie für Tabellen, für die die Zugriffssteuerung auf Spaltenebene verwendet wird, alle Richtlinien-Tag-Taxonomien, die von Ihren Tabellen verwendet werden (falls vorhanden), und gewähren Sie den Dienstkonten der Lösung Zugriff auf die Tabellendaten:
```
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'
```
Ersetzen Sie Folgendes:
- TAXONOMY_PROJECT: die Projekt-ID in der Taxonomie für Richtlinien-Tags
- TAXONOMY_LOCATION: der in der Taxonomie für Richtlinien-Tags angegebene Speicherort
- TAXONOMY_ID: die Taxonomie-ID der Richtlinien-Tag-Taxonomie
Wiederholen Sie den vorherigen Schritt für jede Taxonomie für Richtlinien-Tags.

Lösung ausführen

Nachdem Sie die Lösung bereitgestellt haben, können Sie sie mit den folgenden Abschnitten ausführen und verwalten.

Sicherungsrichtlinien auf Tabellenebene festlegen

Erstellen Sie in Cloud Shell eine Richtlinie auf Tabellenebene mit den erforderlichen Feldern und speichern Sie sie dann im Cloud Storage-Bucket für Richtlinien:

# 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

Ersetzen Sie Folgendes:

TABLE_PROJECT: das Projekt, in dem sich die Tabelle befindet
TABLE_DATASET: Dataset der Tabelle
TABLE_NAME: der Name der Tabelle

Sicherungsvorgänge auslösen

Die zuvor konfigurierten Cloud Scheduler-Jobs werden automatisch basierend auf ihrem Cron-Ausdruck ausgeführt.

Sie können die Jobs auch manuell in der Google Cloud Console ausführen. Weitere Informationen finden Sie unter Job ausführen.

Überwachen und Berichte erstellen

Wenn Sie Ihr Hostprojekt (PROJECT_ID) ausgewählt haben, können Sie die folgenden Abfragen in BigQuery Studio ausführen, um Berichte und Informationen zu erhalten.

Fortschrittsstatistiken für jeden Durchlauf abrufen (einschließlich laufender Durchläufe):
```
SELECT * FROM `bq_backup_manager.v_run_summary_counts`
```
Alle fatalen Fehler (nicht wiederholbare Fehler) für einen einzelnen Durchlauf abrufen:
```
SELECT * FROM `bq_backup_manager.v_errors_non_retryable`
WHERE run_id = 'RUN_ID'
```
Ersetzen Sie RUN_ID durch die ID der Ausführung.

Alle Ausführungen in einer Tabelle und ihre Ausführungsinformationen abrufen:

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

Sie können auch eine grouped-Version angeben:

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

Zum Debuggen können Sie detaillierte Anfrage- und Antwortinformationen für jede Dienstaufruf erhalten:

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"

Rufen Sie die Sicherungsrichtlinien ab, die manuell hinzugefügt oder vom System basierend auf Fallbacks zugewiesen werden:
```
SELECT * FROM `bq_backup_manager.ext_backup_policies`
```

Beschränkungen

Weitere Informationen zu Limits und Kontingenten für jedes Projekt, das in den backup_operation_project-Feldern angegeben ist, finden Sie unter Limits.

Bereinigen

Damit Ihrem Google Cloud-Konto die in dieser Bereitstellung verwendeten Ressourcen nicht in Rechnung gestellt werden, können Sie entweder die Projekte löschen, die die Ressourcen enthalten, oder die Projekte beibehalten und die einzelnen Ressourcen löschen.

Projekte löschen

Achtung: Das Löschen von Projekten hat folgende Auswirkungen:

Alle Inhalte des Projekts werden gelöscht. Wenn Sie für die Aufgaben in diesem Dokument ein bereits bestehendes Projekt verwendet haben und dieses löschen, werden auch alle anderen im Rahmen des Projekts erstellten Daten gelöscht.
Benutzerdefinierte Projekt-IDs gehen verloren. Beim Erstellen dieses Projekts haben Sie möglicherweise eine benutzerdefinierte Projekt-ID erstellt, die Sie weiterhin verwenden möchten. Damit die URLs, die die Projekt-ID nutzen, z. B. eine appspot.com-URL, erhalten bleiben, sollten Sie ausgewählte Ressourcen innerhalb des Projekts löschen, statt das gesamte Projekt.

Wenn Sie mehrere Architekturen, Anleitungen und Kurzanleitungen durcharbeiten möchten, können Sie die Überschreitung von Projektkontingenten verhindern, indem Sie Projekte wiederverwenden.

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.

Die Neuen Ressourcen löschen

Anstatt die Projekte zu löschen, können Sie die während dieses Vorgangs erstellten Ressourcen löschen.

Löschen Sie in Cloud Shell die Terraform-Ressourcen:
```
terraform destroy -var-file="${VARS}"
```
Mit dem Befehl werden fast alle Ressourcen gelöscht. Prüfen Sie, ob alle Ressourcen entfernt wurden, die Sie löschen möchten.

Nächste Schritte

Weitere Informationen zu BigQuery:
- BigQuery-Tabellen-Snapshots
- BigQuery-Tabellenexporte nach Cloud Storage
Weitere Referenzarchitekturen, Diagramme und Best Practices finden Sie im Cloud-Architekturcenter.

Beitragende

Autor: Karim Wadie | Strategic Cloud Engineer

Weitere Beitragende:

Chris DeForeest | Site Reliability Engineer
Eyal Ben Ivri | Cloud Solutions Architect
Jason Davenport | Developer Advocate
Jaliya Ekanayake | Engineering Manager
Muhammad Zain | Strategic Cloud Engineer