Mit Backup and DR können Sie Cloud SQL-Instanzen, AlloyDB-Cluster und Compute Engine-Instanzen sowie einzelne Laufwerke über dieGoogle Cloud Konsole sichern. Die Verfahren zum Sichern und Wiederherstellen dieser Ressourcen finden Sie in der entsprechenden Dokumentation. Wenn alle Ihre Arbeitslasten in diese Kategorien fallen, benötigen Sie keine Sicherungs-/Wiederherstellungs-Appliance.
Für Backup und DR für VMware-VMs und SAP HANA-, IBM Db2-, Oracle- und Microsoft SQL Server-Datenbanken, die in Compute Engine-Instanzen ausgeführt werden, ist eine Backup und DR-Appliance-Verwaltungskonsole und eine oder mehrere Sicherungs-/Wiederherstellungs-Appliances erforderlich. Bei dieser Einrichtung müssen Sie die Größe Ihrer Sicherungs-/Wiederherstellungsgeräte an die Anwendungen anpassen, die Sie sichern. Bei dieser Einrichtung müssen Sie einen Verwaltungsserver erstellen, Appliances bereitstellen und dann die Appliance-Verwaltungskonsole verwenden, um Sicherungszeitpläne zu konfigurieren und festzulegen, was und wo gesichert wird.
Eine Übersicht über Strategien, mit denen Sie Ihre Sicherungs-/Wiederherstellungs-Appliances optimal nutzen können, finden Sie unter Überlegungen zur Bereitstellung von Sicherungs-/Wiederherstellungs-Appliances.
Auf dieser Seite wird beschrieben, wie Sie Backup and DR zum ersten Mal aktivieren und Konfigurationen für Ihr Projekt einrichten.
Komponenten der Architektur der Sicherungs‑/Wiederherstellungs-Appliance
Die Architektur für Backup und DR wird über die folgenden Komponenten bereitgestellt:
Google Cloud -Konsole: Die Google Cloud -Konsole umfasst das Backup and DR-Produkt zur zentralen Verwaltung Ihrer gesicherten Persistent Disk-Sicherungen, Sicherungspläne für Compute Engine-Instanzen und erweiterte Sicherungen für Cloud SQL in diesen Produkten.
Appliance-Verwaltungskonsole: Die Appliance-Verwaltungskonsole dient als Verwaltungsebene für Ihre Sicherungs-/Wiederherstellungs-Appliances. Jede Backup und DR-Bereitstellung umfasst eine einzelne Appliance-Verwaltungskonsole, mit der eine beliebige Anzahl von Sicherungs-/Wiederherstellungs-Appliances verwaltet werden kann. Die Appliance-Verwaltungskonsole wird im Sicherungsverwaltungsprojekt bereitgestellt und ist in der bereitgestellten Region hochverfügbar, sodass sie auch bei zonalen Ausfällen funktioniert.
Sicherungs-/Wiederherstellungs-Appliances: Die Sicherungs-/Wiederherstellungs-Appliance ist das Datenübertragungstool, das den Lebenszyklus von Backupdaten in Ihrem Unternehmen effizient erfasst, verschiebt und verwaltet. Die Sicherungs-/Wiederherstellungs-Appliances werden in der Workload-Entität für Cloud-Arbeitslasten bereitgestellt. Wenn Sie mehrere Sicherungs-/Wiederherstellungsgeräte bereitstellen, muss jedes Gerät mit einem eindeutigen Dienstkonto verknüpft sein.
Backup und DR-Agenten: Der Backup und DR-Agent ruft die anwendungsnativen APIs auf, um Daten aus Produktionsanwendungen effizient und inkrementell zu erfassen. Außerdem bietet er die Application Awareness 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 Appliance-Verwaltungskonsole wird in einem VPC-Netzwerk des Diensterstellers aktiviert. Diese Dienstersteller-VPC 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.
Backup und DR in der Google Cloud Console einrichten
Rufen Sie die Google Cloud Console auf, um die Backupdr API zu aktivieren und Berechtigungen für Ihr Konto einzurichten:
Backup und DR Google Cloud aktivieren
Typen von Sicherungs‑/Wiederherstellungs-Appliances
Backup and DR 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 und neu auszuführen.
Backup und DR bietet die folgenden Appliance-Typen:
- Standard für VMware-VMs und andere Datenbanken oder Ressourcen: Dieser n2-standard-16-Maschinentyp bietet optimale Leistung für die Sicherung von Produktionsdatenbanken, VMware-VMs und anderen Ressourcen. Dieses Gerät bietet bei der Bereitstellung 4 TB an ausgewogener Festplattenkapazität. Sie können 63 zusätzliche 4‑TB-Festplatten hinzufügen. Dieses Gerät kann bis zu 1.500 Anwendungen und 5.000 tägliche Snapshots verwalten.
- Standard für Compute Engine-VMs oder SAP HANA-Datenbanken: Dieser Maschinentyp „e2-standard-4“ eignet sich am besten für die Sicherung von Compute Engine-Instanzen, Cloud SQL-Instanzen, AlloyDB-Clustern und Datenressourcen, für die nichtflüchtiger Speicher für Sicherungen verwendet wird: IBM Db2- und SAP HANA-Datenbanken, die für die Verwendung von nichtflüchtigem Speicher konfiguriert sind. Für diesen Appliance-Typ ist eine Mindestkapazität für nichtflüchtigen Speicher von 10 GB erforderlich. Mit dieser Appliance können bis zu 5.000 Compute Engine- und Cloud SQL-Instanzen, AlloyDB-Cluster und Persistent Disk-basierte Datenanwendungen verwaltet werden.
Basic für VMware-VMs und andere Datenbanken oder Ressourcen: Dieser e2-standard-16-Maschinentyp unterstützt eine moderate Leistung zum Sichern von Datenbanken, VMware-VMs und anderen Ressourcen. Dieses Gerät kann bis zu 1.500 Anwendungen und 5.000 tägliche Snapshots verwalten. Diese Appliance bietet bei der Bereitstellung 4 TB Standardfestplattenkapazität. Sie können 63 zusätzliche 4‑TB-Festplatten der folgenden Typen hinzufügen:
- Nichtflüchtiger Speicher mit minimaler Kapazität: Diese Option bietet eine minimale Laufwerkskapazität von 10 GB. Bei diesem Speichertyp werden Sicherungen als Persistent Disk-Snapshots gespeichert und belegen nicht den lokalen Speicher der Sicherungs-/Wiederherstellungs-Appliance.
- Nichtflüchtiger Standardspeicher: 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 werden 4 TB an Persistent Disk-Kapazität als Mindestkapazität hinzugefügt.
- 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 Mindestspeicherkapazität 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 im E-Mail-Adressformat angezeigt:
APPLIANCE_NAME@PROJECT_ID.iam.gserviceaccount.com
Ersetzen Sie Folgendes:
- APPLIANCE_NAME: Der Name Ihrer Sicherungs‑/Wiederherstellungs-Appliance.
- PROJECT_ID: Die ID Ihres Google Cloud Projekts (Quelle).
Sie können Sicherungen mit langfristigen Aufbewahrungsanforderungen in den Standard-, Nearline- und Coldline Storage verschieben, je nachdem, wie oft Sie voraussichtlich auf die Daten zugreifen müssen.
Firewallkonfigurationen
Die folgenden erforderlichen Firewallregeln für eingehenden Traffic für Backup and DR werden automatisch hinzugefügt.
| Zweck | Quelle | Ziel | Port (TCP) |
|---|---|---|---|
| Support-Traffic (Support für Appliance) | SSH_CLIENT_IP | Sicherungs‑/Wiederherstellungs-Appliance | 26 |
| iSCSI-Sicherung (Host zu Appliance) | AGENT_HOST_IP | Sicherungs‑/Wiederherstellungs-Appliance | 3260 |
| StreamSnap-Traffic (Appliance zu Appliance) | SOURCE_APPLIANCE_IP | Sicherungs‑/Wiederherstellungs-Appliance | 5107 |
| Verbindung der Sicherungs-/Wiederherstellungs-Appliance zur Appliance-Verwaltungskonsole | APPLIANCE_IP | *.backupdr.googleusercontent.com | 443 |
Ersetzen Sie Folgendes:
- SSH_CLIENT_IP: Die IP-Adresse des Hosts, auf dem der SSH-Client ausgeführt wird.
- AGENT_HOST_IP: Die IP-Adresse des Hosts, auf dem der Backup and DR-Agent ausgeführt wird.
- SOURCE_APPLIANCE_IP: Die IP-Adresse der Quell-Appliance.
- APPLIANCE_IP: Die IP-Adresse oder das Subnetz der Sicherungs-/Wiederherstellungs-Appliance.
Weitere Informationen zum Konfigurieren dieser Regel finden Sie unter Backup and DR 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) |
|---|---|---|---|
| KI-Agenten-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 Backup-Traffic verwenden, oder für ESX-Hosts, die in Google Cloud VMware Engine ausgeführt werden und NFS für Mounts verwenden, müssen Sie die folgenden TCP- und UDP-Ports manuell hinzufügen, um die Konnektivität mit einer Ingress-Firewallregel zu ermöglichen.
| Zweck | Quelle | Ziel | Port (TCP/UDP) |
|---|---|---|---|
| NFS-Sicherung oder -Bereitstellung | Host mit Agent oder ESXi-Host mit Bereitstellung | 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 Backup und DR.
Unterstützte Regionen
Im folgenden Abschnitt sind die unterstützten Regionen für die Appliance-Verwaltungskonsole und die Sicherungs-/Wiederherstellungs-Appliances aufgeführt.
Unterstützte Regionen für die Appliance-Verwaltungskonsole
Mit Backup and DR können unterstützte Arbeitslasten in jederGoogle Cloud -Region gesichert werden. Die Appliance-Verwaltungskonsole kann jedoch nur in den folgenden Regionen aktiviert werden:
| Geografischer Bereich | Name der Region | Beschreibung der Region | |
|---|---|---|---|
| Nordamerika | |||
northamerica-northeast1 * |
Montreal |
 Niedriger CO2-Wert
|
|
northamerica-northeast2 |
Toronto |
Niedriger CO2-Wert
|
|
us-central1 |
Iowa |
Niedriger CO2-Wert
|
|
us-east1 |
South Carolina | ||
us-east4 |
Northern Virginia | ||
us-east5 |
Columbus | ||
us-south1 |
Dallas |
Niedriger CO2-Wert
|
|
us-west1 |
Oregon |
Niedriger CO2-Wert
|
|
us-west2 |
Los Angeles | ||
us-west3 |
Salt Lake City | ||
us-west4 |
Las Vegas | ||
northamerica-south1 * |
Querétaro | ||
| Südamerika | |||
southamerica-east1 |
São Paulo |
Niedriger CO2-Wert
|
|
southamerica-west1 |
Santiago |
Niedriger CO2-Wert
|
|
| Europa | |||
europe-central2 |
Warschau |
Niedriger CO2-Wert
|
|
europe-north1 |
Finnland |
Niedriger CO2-Wert
|
|
europe-north2 |
Stockholm |
Niedriger CO2-Wert
|
|
europe-southwest1 |
Madrid |
Niedriger CO2-Wert
|
|
europe-west1 |
Belgien |
Niedriger CO2-Wert
|
|
europe-west2 |
London |
Niedriger CO2-Wert
|
|
europe-west3 |
Frankfurt | ||
europe-west4 |
Niederlande |
Niedriger CO2-Wert
|
|
europe-west6 |
Zürich |
Niedriger CO2-Wert
|
|
europe-west8 |
Mailand |
Niedriger CO2-Wert
|
|
europe-west9 |
Paris |
Niedriger CO2-Wert
|
|
europe-west10 |
Berlin | ||
europe-west12 |
Turin |
Niedriger CO2-Wert
|
|
| 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 (northamerica-south1), Montréal (northamerica-northeast1) und Osaka (asia-northeast2) unterstützen keine Zonentrennung. Das bedeutet, dass sich die mehreren Zonen in jeder dieser Regionen möglicherweise nicht in physisch getrennten Rechenzentrumscampussen befinden. Folglich könnte ein einzelnes, lokalisiertes physisches Katastrophenereignis potenziell mehrere Zonen innerhalb derselben Region beeinträchtigen, was das Risiko von Datenverlust im Vergleich zu Regionen mit Zonentrennung erhöht.
Unterstützte Regionen für Sicherungs‑/Wiederherstellungs-Appliance
Sicherungs-/Wiederherstellungs-Appliances können in jeder 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 Appliance für Sicherung und Notfallwiederherstellung bereitgestellt wird, nicht verfügbar ist, wird der Workflow in Backup and DR 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.