Auf dieser Seite wird beschrieben, wie Sie den Backup and DR-Dienst zum ersten Mal aktivieren und Konfigurationen für Ihr Projekt einrichten.
Komponenten der Architektur für Sicherung und Notfallwiederherstellung
Die Architektur des Sicherungs- und Notfallwiederherstellungsdienstes wird über die folgenden Komponenten bereitgestellt:
Verwaltungskonsole: Die Verwaltungskonsole dient als Verwaltungsebene für Ihre Sicherungs-/Wiederherstellungs-Appliances. Jede Backup and DR-Bereitstellung umfasst eine einzelne Verwaltungskonsole, mit der eine beliebige Anzahl von Appliances für Sicherung und Wiederherstellung verwaltet werden kann. Die Verwaltungskonsole wird im Sicherungsverwaltungsprojekt bereitgestellt und ist in der bereitgestellten Region hochverfügbar. So wird die Ausfallsicherheit bei zonalen Ausfällen gewährleistet.
Sicherungs-/Wiederherstellungs-Appliances: Die Sicherungs-/Wiederherstellungs-Appliance ist der Datenübertrager, der den Lebenszyklus von Sicherungsdaten in Ihrem Unternehmen effizient erfasst, verschiebt und verwaltet. Die Sicherungs-/Wiederherstellungs-Appliances werden in der Workload-Entität für Cloud-Arbeitslasten bereitgestellt.
Backup and DR-Agents: Der Backup and DR-Agent ruft die anwendungsnativen APIs auf, um Daten aus Produktionsanwendungen effizient und inkrementell zu erfassen. Außerdem bietet er die Anwendungsübersicht zum Zeitpunkt der Wiederherstellung. Der Agent wird auf Anwendungshosts installiert, auf denen sich die zu schützenden Anwendungen befinden. Wenn Sie nur die gesamte VM oder eine Teilmenge ihrer Laufwerke schützen, ist der Backup and DR-Agent nicht erforderlich.
Die Verwaltungskonsole wird in einem VPC-Netzwerk des Diensterstellers aktiviert. Dieses VPC-Netzwerk des Diensterstellers kommuniziert über privaten Google-Zugriff mit Ihrem Projekt.
Die Kommunikation zwischen dem Verwaltungsserver und den Appliances, zwischen den Appliances und zwischen den Appliances und den Host-Agents wird durch die gegenseitige TLS-Authentifizierung gesichert.
Hinweise zur Implementierung
Im Folgenden finden Sie einige wichtige Überlegungen, die sich auf die Bereitstellung des Backup- und DR-Diensts auswirken:
Welche RTO-Anforderungen (Recovery Time Objective) hat Ihre Organisation? Die RTO ist die maximale Zeitspanne, in der Sie ohne Ihre Daten auskommen können. Wenn Ihr RTO beispielsweise 4 Stunden beträgt, müssen Sie innerhalb von 4 Stunden nach einer Katastrophe auf Ihre Daten zugreifen können.
Müssen Sie die Sicherungsverwaltung zentralisieren? Sie müssen entscheiden, ob Sie Ihre Back-ups zentral verwalten möchten oder nicht.
- Die zentrale Sicherungsverwaltung bietet Ihnen eine einzige Verwaltungskonsole, mit der Sie Sicherungen für alle Ihre Arbeitslasten in allen Geschäftsbereichen verwalten können. Das kann eine effizientere Methode zum Verwalten von Back-ups sein, da Sie nur eine einzige Verwaltungskonsole benötigen.
- Bei der dezentralen Sicherungsverwaltung haben Sie für jede Sparte eine separate Verwaltungskonsole. Die Vorgehensweise variiert von Organisation zu Organisation.
Was ist Ihr Anwendungsfall für die Sicherung? Benötigen Sie Sicherungen für die Notfallwiederherstellung im Falle einer Katastrophe in einer Produktionsregion oder reicht es aus, Ihre Daten lokal zu schützen? Wenn Sie eine Notfallwiederherstellungsfunktion benötigen, müssen Sie regionsübergreifende Sicherungen in Betracht ziehen. Das bedeutet, dass Sie Ihre Sicherungen an mehreren Orten speichern sollten, damit Ihre Daten auch dann zugänglich sind, wenn ein Standort von einer Katastrophe betroffen ist.
Arbeitslasten befinden sich in einer einzelnen Region
Die beste Sicherungsstrategie in einer Region hängt von Ihren Anforderungen ab.
Wenn Sie keine Notfallwiederherstellung (Disaster Recovery, DR) benötigen
Um die beste Leistung zu erzielen und die Kosten zu senken, sollten Sie die Verwaltungskonsole und die Sicherungs-/Wiederherstellungs-Appliances in derselben Region bereitstellen, in der Ihre Arbeitslasten ausgeführt werden. Speichern Sie Ihre Sicherungsbilder in derselben Region wie Ihre Arbeitslasten.
Wenn Sie auch Sicherungskopien an einem externen Standort haben möchten, können Sie Sicherungen in einer anderen Region speichern oder Dual-Regionen- oder Multi-Regionen-Speicher verwenden. Wenn Sie Sicherungen in einer anderen Region speichern, fallen Netzwerk- und Speichergebühren an.
Wenn Sie sowohl Backup als auch DR benötigen
Für eine optimale Leistung und geringere Kosten sollten Sie eine Verwaltungskonsole in derselben Region wie die Produktionsarbeitslast und eine zweite Verwaltungskonsole in der Region bereitstellen, die Sie für die Notfallwiederherstellung verwenden können.
Stellen Sie Sicherungs-/Wiederherstellungs-Appliances sowohl in der Region für die Produktionsarbeitslast als auch in der DR-Region bereit, um das Recovery Time Objective (RTO) zu minimieren. So wird sichergestellt, dass eine DR-Umgebung im Falle einer Katastrophe vollständig vorab bereitgestellt und verfügbar ist.
Speichern Sie Sicherungs-Images in der Produktionsregion und eine Kopie in der DR-Region (Disaster Recovery, Notfallwiederherstellung) oder verwenden Sie Speicher mit zwei oder mehr Regionen. Die Sicherungskopie in der Produktionsregion kann mit einer schnelleren Leistung die routinemäßigen Sicherungsanforderungen erfüllen. Daten, die in Ihre DR-Region kopiert wurden, können verwendet werden, um Ihre Arbeitslasten wiederherzustellen, falls die Produktionsregion ausfällt.
Arbeitslasten befinden sich in mehreren Regionen
Die beste Sicherungsstrategie für verschiedene Regionen hängt von Ihren Anforderungen ab.
Wenn Sie keine Notfallwiederherstellung (Disaster Recovery, DR) benötigen
Um die beste Leistung zu erzielen und die Kosten zu senken, sollten Sie die Verwaltungskonsole in einer der Regionen bereitstellen, in denen Ihre Arbeitslasten ausgeführt werden. Dies ermöglicht eine zentrale Verwaltung aller Arbeitslasten und Regionen.
Stellen Sie in jeder Region, in der die Arbeitslasten ausgeführt werden, eine oder mehrere Sicherungs-/Wiederherstellungs-Appliances bereit. Speichern Sie Ihre Back-ups in derselben Region wie Ihre Arbeitslasten.
Wenn Sie auch Sicherungskopien an einem externen Standort haben möchten, können Sie Sicherungen in einer anderen Region speichern oder Dual-Regionen- oder Multi-Regionen-Speicher verwenden. Wenn Sie Sicherungen in einer anderen Region oder Multiregion speichern, fallen Gebühren für Netzwerk und Speicher an.
Wenn Sie sowohl Backup als auch DR benötigen
Stellen Sie in jeder der Produktionsarbeitslastregionen eine Verwaltungskonsole und in der DR-Region eine weitere Verwaltungskonsole bereit.
Stellen Sie Sicherungs-/Wiederherstellungs-Appliances sowohl in den Produktionsarbeitslastregionen als auch in der DR-Region bereit, um das Recovery Time Objective (RTO) zu minimieren. So wird sichergestellt, dass eine DR-Umgebung im Katastrophenfall vollständig vorab bereitgestellt und verfügbar ist.
Sicherungen in der Region des Produktions-Workloads und eine Kopie in der DR-Region speichern oder Dual-Region- oder Multi-Region-Speicher verwenden. Die Sicherungskopie der Produktionsregion kann verwendet werden, um die Sicherungsanforderungen zu erfüllen.
Ein Sicherungs-Image in der DR kann verwendet werden, um Arbeitslasten wiederherzustellen, wenn die Produktionsregion ausgefallen ist.
Backup- und DR-Dienst in der Google Cloud -Konsole einrichten
Rufen Sie die Google Cloud -Konsole auf, um die Backup and DR Service API zu aktivieren und Berechtigungen für Ihr Konto einzurichten:
Google Cloud Backup and DR aktivieren
Typen von Sicherungs‑/Wiederherstellungs-Appliances
Der Backup and DR Service bietet Appliance-Typen, die für verschiedene Arbeitslasten optimiert sind: Compute Engine-VMs, VMware-VMs, Datenbanken und Dateisysteme. Sie können den Gerätetyp auswählen, der Ihren Anforderungen am besten entspricht. Es ist wichtig, den besten Appliance-Typ für Ihre Arbeitslasten auszuwählen. Sobald die Sicherungs-/Wiederherstellungs-Appliance in Betrieb ist, läuft sie kontinuierlich und ist jederzeit bereit, Sicherungs-, Wiederherstellungs- und andere Jobs auszuführen.
Der Backup- und DR-Dienst bietet die folgenden Appliance-Typen:
- Standard für Compute Engine-VMs oder SAP HANA-Datenbanken: Wählen Sie diese Option aus, wenn Sie nur Compute Engine-Instanzen oder SAP HANA-Datenbanken mit nichtflüchtigem Speicher sichern möchten. Standardmäßig wird mit dieser Appliance der Maschinentyp „e2-standard-4“ mit einer Mindestkapazität für Persistent Disk von 10 GB hinzugefügt. Mit dieser Appliance können bis zu 5.000 Compute Engine-VMs verwaltet werden.
- Standard für VMware-VMs und andere Datenbanken oder Ressourcen: Wählen Sie diese Option aus, wenn Sie eine Standardkonfiguration wünschen, die eine optimale Leistung für die Sicherung von Datenbanken, VMware-VMs und anderen Ressourcen unterstützt. Standardmäßig wird mit dieser Appliance der Maschinentyp „n2-standard-16“ hinzugefügt. Dadurch werden 4 TB als Mindestkapazität für ausgeglichene Laufwerke hinzugefügt. Dieses Gerät kann bis zu 1.500 Anwendungen verwalten.
Basic for VMware VMs and other databases or resources (Einfach für VMware-VMs und andere Datenbanken oder Ressourcen): Wählen Sie diese Option aus, wenn Sie eine einfache Konfiguration mit mittlerer Leistung zum Sichern von Datenbanken, VMware-VMs und anderen Ressourcen benötigen. Standardmäßig wird mit dieser Appliance der Maschinentyp „e2-standard-16“ hinzugefügt. Dieses Gerät kann bis zu 1.500 Anwendungen verwalten. Sie können einen der folgenden Festplattentypen zum Speichern Ihrer Daten auswählen.
- Nichtflüchtiger Speicher mit minimaler Kapazität: Diese Option bietet eine minimale Festplattenkapazität von 10 GB. Bei diesem Speichertyp werden Sicherungen als Persistent Disk-Snapshots gespeichert und belegen nicht den lokalen Speicher der Sicherungs-/Wiederherstellungs-Appliance.
- Standard-Persistent Disk: Wählen Sie diesen Speichertyp aus, wenn Sie effizienten Blockspeicher benötigen. Empfohlen für Google Cloud VMware Engine-VMs, Datenbanken oder Dateisystemanwendungen mit mittleren bis hohen E/A-Anzahlen sowie für Compute Engine-VMs. Dadurch wird die Mindestkapazität für Persistent Disk um 4 TB erhöht.
- Nichtflüchtiger SSD-Speicher: Wählen Sie diesen Speichertyp aus, wenn Sie schnellen Blockspeicher benötigen. Empfohlen für Google Cloud VMware Engine, Datenbanken oder Dateisystemanwendungen mit sehr hohen E/A-Anzahlen sowie für Compute Engine-VMs. Dadurch wird die Mindestkapazität für Persistent Disk um 4 TB erhöht.
Wenn Sie eine Appliance bereitstellen, wird unabhängig vom Appliance-Typ automatisch ein Dienstkonto erstellt. Sie können das Dienstkonto auf der Seite Dienstkonto aufrufen.
Der Name des Dienstkontos wird in der E-Mail-Adresse im Format „my-service-account@my-project.iam.gserviceaccount.com“ angezeigt, wobei „appliance-name“ der Name eines Geräts und „projectid“ die ID Ihres Google Cloud Projekts ist.
Speichertyp auswählen
Die Sicherungs-/Wiederherstellungs-Appliance speichert Sicherungsdaten im lokalen Appliance-Snapshot-Pool. Sie können sie zur langfristigen Aufbewahrung in den Objektspeicher kopieren. Google Cloud bietet die folgenden drei Arten von lokalem Objektspeicher:
Nichtflüchtiger Speicher mit minimaler Kapazität: Sicherungs-Images werden als Snapshots des nichtflüchtigen Speichers gespeichert, die nicht den lokalen Speicher der Sicherungs-/Wiederherstellungs-Appliance belegen.
Nichtflüchtiger Standardspeicher: Dieser Speichertyp bietet effizienten Blockspeicher mit einem nichtflüchtigen Speicher von 4 TB. Empfohlen für VMware Engine-VMs und Datenbank- oder Dateisystemanwendungen mit mittleren bis hohen E/A-Anzahlen.
Nichtflüchtiger SSD-Speicher: Dieser Speichertyp bietet schnellen Blockspeicher mit einem Persistent Disk von 4 TB. Empfohlen für Google Cloud VMware Engine-VMs und Datenbank- oder Dateisystemanwendungen mit sehr hohen E/A-Anzahlen.
Sie können die Kapazität Ihrer Festplattenpools später erweitern.
Sie können Sicherungen mit langfristigen Aufbewahrungsanforderungen in den Google Cloud Standard-, Nearline- und Coldline-Speicher verschieben, je nachdem, wie oft Sie voraussichtlich auf die Daten zugreifen müssen.
Empfohlene Netzwerktopologie für den Backup- und DR-Dienst
Google Cloud empfiehlt die Verwendung einer freigegebene VPC bei der Bereitstellung des Backup- und DR-Dienstes. Eine freigegebene VPC ermöglicht einer Organisation, Ressourcen von mehreren Projekten mit einem gemeinsamen VPC-Netzwerk zu verbinden, sodass sie sicher und effizient über interne IP-Adressen dieses Netzwerks miteinander kommunizieren können. Wenn Sie eine freigegebene VPC verwenden, bestimmen Sie ein Projekt zum Hostprojekt und fügen ihm ein oder mehrere Dienstprojekte hinzu. Die VPC-Netzwerke im Hostprojekt werden als freigegebene VPC-Netzwerke bezeichnet. Zulässige Ressourcen aus Dienstprojekten können Subnetze im freigegebenen VPC-Netzwerk verwenden.
Über eine freigegebene VPC können Organisationsadministratoren administrative Aufgaben wie das Erstellen und Verwalten von Instanzen an Dienstprojektadministratoren delegieren, ohne die zentrale Steuerung von Netzwerkressourcen wie Subnetzen, Routen und Firewalls aus der Hand zu geben.
Die Verwaltungskonsole wird in einer VPC des VPC-Netzwerks des Diensterstellers aktiviert. Dieses VPC-Netzwerk des Diensterstellers kommuniziert über privaten Google-Zugriff mit Ihrem Projekt. Der primäre Zweck dieser Verbindung besteht darin, dass die Verwaltungskonsole und die Sicherungs-/Wiederherstellungsgeräte Metadaten austauschen. Sicherungs-Traffic wird nicht über diesen Link weitergeleitet. Eine Verwaltungskonsole muss jedoch mit allen Appliances für Sicherung und Wiederherstellung kommunizieren, die in einem beliebigen Netzwerk bereitgestellt werden.
Best Practices für freigegebene VPC
Die folgenden Best Practices werden empfohlen:
Verbindung zur Verwaltungskonsole herstellen: Es empfiehlt sich, das Netzwerk des Dienstanbieters mit einem freigegebene VPC-Netzwerk in Ihrem Netzwerk zu verbinden. Der gesamte Traffic von der Verwaltungskonsole fließt durch diese VPC und damit durch das Hostprojekt. Durch die Bereitstellung der Verbindung zum Backup and DR Service über eine freigegebene VPC wird auch eine nahtlose Verbindung zwischen Projekten, in denen die Arbeitslasten ausgeführt werden (Dienstprojekte), und dem Backup and DR Service ermöglicht.
Standort der Sicherungs-/Wiederherstellungs-Appliance: Die Sicherungs-/Wiederherstellungs-Appliances müssen in einem Subnetz bereitgestellt werden, für das der privater Google-Zugriff für die Verbindung zur Verwaltungskonsole aktiviert ist. Es gibt zwei empfohlene Strategien für die Auswahl der Projekte für die Sicherungs-/Wiederherstellungs-Appliances:
Im zentralen Hostprojekt: Bei dieser Strategie wird der Backup- und DR-Dienst als zentraler Dienst der IT behandelt. Das zentrale Sicherungsteam ist für die Bereitstellung des Dienstes zuständig. Daher werden alle Sicherungs-/Wiederherstellungs-Appliances im Hostprojekt bereitgestellt, sodass zentrale Administratoren alle Sicherungsressourcen in einem zentralen Projekt konsolidieren können. Dieser Ansatz hat den Vorteil, dass alle sicherungsbezogenen Ressourcen und die zugehörige Abrechnung in einem einzigen Projekt zusammengefasst werden.
In Dienstprojekten: Diese Strategie eignet sich für dezentralere Teams, in denen Dienstprojekte erstellt und ihre Verwaltung an verteilte Teams delegiert wird. In diesem Szenario wird empfohlen, VPC für Downstream-Dienstprojekte bereitzustellen. Sicherungs-/Wiederherstellungs-Appliances werden in den Dienstprojekten in diesen VPCs installiert. Dadurch können Arbeitslast und Sicherungs-/Wiederherstellungs-Appliance in einem einzigen Projekt untergebracht werden.
Privater Google-Zugriff: Es empfiehlt sich, den privaten Google-Zugriff für jedes Subnetz zu aktivieren, in dem Sie ein Sicherungs-/Wiederherstellungsgerät installieren. So kann die Sicherungs-/Wiederherstellungs-Appliance mit APIs wie Compute Engine, Cloud Storage und Cloud Logging kommunizieren, was für die Überwachung und Benachrichtigung wichtig ist. Um Verbindungen zu Google Cloud -APIs zu vereinfachen und zu optimieren, sollten Sie die DNS-Auflösung für
private.googleapis.com
konfigurieren, wie im Abschnitt Zusammenfassung der Konfigurationsoptionen beschrieben. Konfigurieren Sie außerdem die Firewallregeln der Sicherungs-/Wiederherstellungsgeräte so, dass Verbindungen zum CIDR-Bereich199.36.153.8/30
über den TCP-Port443
zugelassen werden.
Firewallkonfigurationen
Die folgenden erforderlichen Firewallregeln für eingehenden Traffic in den Backup and DR Service werden automatisch hinzugefügt.
Zweck | Quelle | Ziel | Port (TCP) |
---|---|---|---|
Support-Traffic (Support zur Appliance) | Host mit SSH-Client | Sicherungs‑/Wiederherstellungs-Appliance | 26 |
iSCSI-Sicherung (Host zu Appliance) | Host, auf dem der Backup and DR-Agent ausgeführt wird | Sicherungs‑/Wiederherstellungs-Appliance | 3260 |
StreamSnap-Traffic (Appliance zu Appliance) | Sicherungs‑/Wiederherstellungs-Appliance | Sicherungs‑/Wiederherstellungs-Appliance | 5107 |
Verbindung der Sicherungs-/Wiederherstellungs-Appliance zur Verwaltungskonsole | IP-Adresse oder Subnetz der Sicherungs‑/Wiederherstellungs-Appliance | *.backupdr.googleusercontent.com | 443 |
Weitere Informationen zum Konfigurieren dieser Regel finden Sie unter Backup- und DR-Dienst für die Bereitstellung vorbereiten.
Für jeden Host, auf dem der Backup and DR-Agent ausgeführt wird, müssen Sie den folgenden TCP-Port manuell hinzufügen, um die Verbindung mit einer Firewallregel für eingehenden Traffic zuzulassen.
Zweck | Quelle | Ziel | Port (TCP) |
---|---|---|---|
Agent-Traffic (Appliance zu Host) | Sicherungs‑/Wiederherstellungs-Appliance | Host, auf dem der Backup and DR-Agent ausgeführt wird | 5106 |
Für Hosts, die NFS für Sicherungstraffic verwenden, oder für ESX-Hosts, die in VMware Engine ausgeführt werden und NFS für Bereitstellungen verwenden, müssen Sie die folgenden TCP- und UDP-Ports manuell hinzufügen, um die Verbindung mit einer Ingress-Firewallregel zuzulassen.
Zweck | Quelle | Ziel | Port (TCP/UDP) |
---|---|---|---|
NFS-Sicherung oder -Bereitstellung | Host, auf dem der Agent ausgeführt wird, oder ESXi-Host, auf dem das Mount ausgeführt wird | Sicherungs‑/Wiederherstellungs-Appliance | 111, 756, 2049, 4001, 4045 |
Eine Liste der Berechtigungen, die bei diesem Vorgang verwendet werden, finden Sie unter Berechtigungsreferenz für die Installation von Sicherung und Notfallwiederherstellung.
Unterstützte Regionen
Im folgenden Abschnitt sind die unterstützten Regionen für die Verwaltungskonsole und die Sicherungs-/Wiederherstellungs-Appliances aufgeführt.
Unterstützte Regionen für die Verwaltungskonsole
Der Backup- und DR-Dienst kann zum Sichern unterstützter Arbeitslasten in jederGoogle Cloud -Region verwendet werden. Die Verwaltungskonsole kann jedoch nur in den folgenden Regionen aktiviert werden:
Geografischer Bereich | Name der Region | Beschreibung der Region | |
---|---|---|---|
Nordamerika | |||
northamerica-northeast1 * |
Montreal |
|
|
northamerica-northeast2 |
Toronto |
|
|
us-central1 |
Iowa |
|
|
us-east1 |
South Carolina | ||
us-east4 |
Northern Virginia | ||
us-east5 |
Columbus | ||
us-south1 |
Dallas |
|
|
us-west1 |
Oregon |
|
|
us-west2 |
Los Angeles | ||
us-west3 |
Salt Lake City | ||
us-west4 |
Las Vegas | ||
northamerica-south1 * |
Querétaro | ||
Südamerika | |||
southamerica-east1 |
São Paulo |
|
|
southamerica-west1 |
Santiago |
|
|
Europa | |||
europe-central2 |
Warschau | ||
europe-north1 |
Finnland |
|
|
europe-southwest1 |
Madrid |
|
|
europe-west1 |
Belgien |
|
|
europe-west2 |
London |
|
|
europe-west3 |
Frankfurt |
|
|
europe-west4 |
Niederlande |
|
|
europe-west6 |
Zürich |
|
|
europe-west8 |
Mailand | ||
europe-west9 |
Paris |
|
|
europe-west10 |
Berlin |
|
|
europe-west12 |
Turin | ||
Naher Osten | |||
me-central1 |
Doha | ||
me-central2 |
Dammam | ||
me-west1 |
Israel | ||
Afrika | |||
africa-south1 |
Johannesburg | ||
Asiatisch-pazifischer Raum | |||
asia-east1 |
Taiwan | ||
asia-east2 |
Hongkong | ||
asia-northeast1 |
Tokio | ||
asia-northeast2 * |
Osaka | ||
asia-northeast3 |
Seoul | ||
asia-southeast1 |
Singapur | ||
asia-southeast2 |
Jakarta | ||
australia-southeast1 |
Sydney | ||
australia-southeast2 |
Melbourne | ||
Indien | |||
asia-south1 |
Mumbai | ||
asia-south2 |
Delhi |
* Querétaro, Montreal und Osaka haben jeweils drei Zonen, die sich in einem oder zwei physischen Rechenzentren befinden. Im seltenen Fall einer Katastrophe können in diesen Regionen gespeicherte Daten verloren gehen.
Unterstützte Regionen für Sicherungs‑/Wiederherstellungs-Appliance
Sicherungs-/Wiederherstellungs-Appliances können in einer beliebigen Google Cloud -Zone bereitgestellt werden.
Der Workflow-Dienst zum Bereitstellen der Sicherungs-/Wiederherstellungs-Appliance wird in den aufgeführten Regionen unterstützt. Wenn der Workflow-Dienst in einer Region, in der Ihre Sicherungs-/Wiederherstellungs-Appliance bereitgestellt wird, nicht verfügbar ist, wird der Workflow im Backup- und DR-Dienst standardmäßig in der Region us-central1
ausgeführt. Die Appliance selbst wird weiterhin in der von Ihnen ausgewählten Region erstellt. Wenn Sie eine Organisationsrichtlinie haben, die das Erstellen von Ressourcen in anderen Regionen verhindert, müssen Sie Ihre Organisationsrichtlinie vorübergehend aktualisieren, um das Erstellen von Ressourcen in der Region us-central1
zu ermöglichen. Sie können die us-central1
-Region nach der Bereitstellung der Sicherungs-/Wiederherstellungs-Appliance einschränken.