Backup und DR für die Verwaltungskonsole – Übersicht

Backup und DR für die Verwaltungskonsole ist eine Appliance-basierte Sicherungs- und Notfallwiederherstellungslösung, mit der Sie virtuelle Maschinen (VMs), Dateisysteme und selbstverwaltete Datenbanken inGoogle Cloud - und Hybridumgebungen zentral erfassen, speichern, replizieren und wiederherstellen können. Über eine dedizierte, webbasierte Appliance-Verwaltungskonsole und vom Kunden bereitgestellte Sicherungs-/Wiederherstellungs-Appliances können Sie den Datenschutz für Ihre Arbeitslasten verwalten.

Backup und DR für die Verwaltungskonsole erfasst Daten in einem inkrementellen Format und speichert sie in einem integrierten, für Anwendungen lesbaren Format. Da Sicherungen nativ und nicht als proprietäre Sicherungsarchive gespeichert werden, können Sie Sicherungs-Images direkt von einer Sicherungs-/Wiederherstellungs-Appliance bereitstellen, um Arbeitslasten wiederherzustellen, virtuelle Kopien für Tests und Entwicklung bereitzustellen oder Daten mit minimaler Ausfallzeit zu migrieren.

Einstellung von Backup und DR für die Verwaltungskonsole

Google Cloud Backup und DR wird am 30. September 2027 den Support für die Legacy-Appliance-Verwaltungskonsole (IaaS-Stack) und die zugehörigen nutzerverwalteten Arbeitslasten einstellen. Planen Sie die Migration zu alternativen Sicherungsmethoden so bald wie möglich, um den kontinuierlichen Datenschutz aufrechtzuerhalten.

Von der Einstellung der Verwaltungskonsole betroffene Arbeitslasten

Die Einstellung der Verwaltungskonsole betrifft nur selbstverwaltete Arbeitslasten, die über die Legacy-Appliance-Verwaltungskonsole geschützt sind, einschließlich:

  • Compute Engine-Instanzen, die über die Appliance-Verwaltungskonsole verwaltet werden
  • IBM Db2-Datenbanken
  • Oracle-Datenbanken
  • SAP HANA-Datenbanken
  • Microsoft SQL Server-Datenbanken
  • Google Cloud VMware Engine-VMs
  • Generische Anwendungen und Konsistenzgruppen
  • Nutzerverwaltete Dateisysteme (Linux- und Windows-Dateisysteme, Systemstatus, NFS und SMB/CIFS)

Von Google verwaltete Erstanbieterdienste, die direkt über dieGoogle Cloud -Konsole geschützt werden, einschließlich Compute Engine-VMs, Persistent Disks, Cloud SQL, AlloyDB for PostgreSQL und Filestore, sind von dieser Einstellung nicht betroffen.

Zeitplan und Meilensteine für die Einstellung

Die Einstellung von Backup und DR für die Verwaltungskonsole erfolgt in drei wichtigen Phasen:

  • 31. Dezember 2026 (Löschen inaktiver Verwaltungsserver): Alle Verwaltungsserver in Ihrem Projekt werden nach 30 aufeinanderfolgenden Tagen Inaktivität automatisch gelöscht. Ein Verwaltungsserver gilt nur dann als inaktiv, wenn er keine aktiven Sicherungen, keine geschützten Anwendungen oder Arbeitslasten und keine aktiven Sicherungsjobs hat.
  • 30. September 2027 (Sicherungsstopp): Der Support für das Erstellen neuer Sicherungen mit dem alten Appliance-Verwaltungskonsolen-Stack endet. Wenn Sie die Migration nicht vor diesem Stichtag durchführen, können Sie keine neuen Sicherungen der betroffenen Arbeitslasten erstellen.
  • 31. März 2028 (Wiederherstellungsfrist): Die Möglichkeit zur direkten Wiederherstellung über die alte Appliance-Verwaltungskonsole endet. Wenn Sie Sicherungen nach diesem Stichtag wiederherstellen möchten, müssen Sie das eigenständige Wiederherstellungstool und die Skripts für die langfristige Aufbewahrung verwenden.

Migrationsalternativen für Arbeitslasten der Verwaltungskonsole

Damit der Sicherungsschutz vor dem Sicherungsstopp am 30. September 2027 aufrechterhalten bleibt, migrieren Sie Ihre betroffenen Arbeitslasten zu einer der folgenden unterstützten Sicherungslösungen:

Arbeitslast Migrationsoption Referenz
Compute Engine Google-native Compute Engine-Sicherungen Migrieren Sie Compute Engine-Instanzen mit Google Cloud Backup und DR für Compute Engine-Instanzen zu einer Architektur ohne Appliances.
Nutzerverwaltete Datenbanken (IBM Db2, Oracle, SAP HANA, Microsoft SQL Server usw.) Anwendungskonsistente Vault-Sicherungen mit benutzerdefinierten Skripts Verwenden Sie Compute Engine-VM- und Persistent Disk-Sicherungen in Google Cloud Backup und DR mit dem Guest-Flush-Framework, kombiniert mit benutzerdefinierten Skripts für anwendungskonsistente und unveränderliche Sicherungen.
SAP HANA Agentenbasierte Google Cloud Sicherungen Verwenden Sie den nativen Google Cloud Backint-Agenten oder Snapshots von Persistent Disk. Weitere Informationen finden Sie im Leitfaden zur Sicherung und Wiederherstellung mit dem Agent für SAP Backint oder im Leitfaden zur Sicherung und Wiederherstellung mit Laufwerk-Snapshots.
Allgemeine VM-Arbeitslasten Native Google Cloud Laufwerk-Snapshots Konfigurieren Sie Standard- oder Archiv-Laufwerk-Snapshots, um virtuelle Laufwerke regelmäßig zu sichern. Folgen Sie dazu der Anleitung für Laufwerk-Snapshots.
Alle Arbeitslasten Marktplatzlösungen von Drittanbietern Stellen Sie genehmigte alternative Enterprise-Sicherungslösungen bereit, die im Google Cloud Marketplace verfügbar sind.

Sicherungen nach dem 31. März 2028 aufbewahren und wiederherstellen

Wenn Sie die Möglichkeit zur Wiederherstellung von Sicherungen über den 31. März 2028 hinaus beibehalten möchten, migrieren Sie Ihre alten Sicherungsdaten zu OnVault-Speicher in Cloud Storage, bevor Ihre Appliances heruntergefahren werden:

  1. OnVault-Richtlinien zuweisen: Migrieren Sie alle kritischen Legacy-Sicherungen in Cloud Storage OnVault-Buckets.
  2. Metadaten synchronisieren: Achten Sie darauf, dass alle Metadaten von Persistent Disk-Snapshots vollständig mit Ihrem Cloud Storage-Bucket synchronisiert sind, bevor Ihre lokalen Appliances heruntergefahren werden. Wenden Sie sich an gcbdr-umdb-transition@google.com oder an den Cloud Customer Care, um diese Metadatenübertragung zu überprüfen und abzuschließen.
  3. Wiederherstellungstool verwenden: Verwenden Sie das eigenständige Tool und die Skripts, um OnVault- und Persistent Disk-Sicherungs-Images direkt aus Ihren Cloud Storage-Buckets zu finden und bereitzustellen. Eine Anleitung finden Sie unter Langfristig aufbewahrte Sicherungen wiederherstellen.

Wenn Sie Fragen haben oder Unterstützung bei der Planung Ihrer Migration benötigen, wenden Sie sich an das Übergangsteam unter gcbdr-umdb-transition@google.com, an Cloud Customer Care oder an Ihr Google Cloud-Account-Management-Team.

Unterschiede zwischen Backup und DR für die Verwaltungskonsole und Backup und DR von Google Cloud

Google bietet zwei unterschiedliche Verwaltungs- und Architekturmodelle für Backup und DR:

  • Backup und DR für die Verwaltungskonsole (diese Dokumentation): Eine Appliance-basierte Architektur, bei der Sie Sicherungs-/Wiederherstellungs-Appliances in Ihrem VPC-Netzwerk (Virtual Private Cloud) bereitstellen und verwalten und den Schutz über die dedizierte webbasierte Appliance-Verwaltungskonsole orchestrieren. Dieses Angebot ist für selbstverwaltete Datenbanken (wie Oracle, Microsoft SQL Server, SAP HANA und IBM Db2), Google Cloud VMware Engine- und VMware vSphere-VMs, Dateisysteme und Arbeitslasten konzipiert, die sofortige anwendungssensitive Bereitstellungen, virtuelle Datenbankklone (LiveClones) oder automatisierte Backup und DR-Workflows erfordern.
  • Google Cloud Backup und DR: Eine cloudnative, SaaS-verwaltete Sicherungslösung, die direkt in dieGoogle Cloud Console, die gcloud CLI, die backupdr API und Terraform eingebunden ist. MitGoogle Cloud Backup and DR können Sie native Google Cloud -Ressourcen wie Compute Engine-Instanzen, Persistent Disks und Google Cloud Hyperdisks, Cloud SQL-Instanzen, AlloyDB-Cluster und Filestore-Instanzen direkt in von Google verwalteten, unveränderlichen Backup Vaults schützen, ohne Sicherungs-/Wiederherstellungs-Appliances bereitstellen oder verwalten zu müssen.

In der folgenden Tabelle sind die wichtigsten Unterschiede zwischen den beiden Angeboten für Backup und DR zusammengefasst:

Funktion Backup und DR für die Verwaltungskonsole Google Cloud Backup und DR
Primäre Verwaltungsoberfläche Dedizierte webbasierte Appliance-Verwaltungskonsole und Management Console API Google Cloud Console, gcloud CLI, Backup DR API und Terraform
Architektur und Datenebene Dreistufige Appliance-Architektur, bestehend aus der Appliance-Verwaltungskonsole, vom Kunden bereitgestellten Sicherungs-/Wiederherstellungs-Appliances (Compute Engine-VMs in Ihrer VPC) und einfachen Backup- und DR-Agents auf Arbeitslasthosts Vollständig verwaltete Google-Dienstebene; keine vom Kunden bereitgestellten Sicherungs-/Wiederherstellungs-Appliances oder Gast-Agents für konsolennative Vault-Ressourcen erforderlich
Sicherungskonfigurationsmodell Backup-Vorlagen (mit Snapshot-, OnVault- und Replikationsrichtlinien) kombiniert mit Ressourcenprofilen Konsolennative Sicherungspläne und Sicherungsregeln, die direkt mit einem Ziel-Backup Vault verknüpft sind
Speicherziele Von der Appliance verwaltete Speicherpools (primärer Pool, Snapshot-Pool auf Persistent Disk, OnVault-Pool in Cloud Storage und Spiegelpool auf einer Remote-Appliance) sowie von Google verwaltete Backup Vaults für unterstützte Arbeitslasten Von Google verwaltete, unveränderliche und nicht löschbare Backup Vaults mit erzwungener Aufbewahrung und regionalem oder multiregionalem Speicher
Wiederherstellung und Datenzugriff Vollständige Wiederherstellung, sofortige Standardbereitstellungen, anwendungsspezifische Bereitstellungen, virtuelle Kopien (LiveClones), Bereitstellen und Migrieren sowie automatisierte Backup und DR-Workflows Direkte Wiederherstellung in neuen oder vorhandenen Google Cloud -Ressourcen aus einem Backup Vault
Unterstützte Arbeitslasten Google Cloud VMware Engine, VMware vSphere-VMs, Compute Engine-Instanzen, Linux- und Windows-Dateisysteme (einschließlich NFS, SMB und Filestore), Oracle, Microsoft SQL Server, SAP HANA, IBM Db2, PostgreSQL, SAP ASE, SAP IQ, SAP MaxDB, MySQL, MariaDB, Konsistenzgruppen und generische Anwendungen Compute Engine-Instanzen, Persistent Disks und Hyperdisks, Cloud SQL, AlloyDB und Filestore (plus Einblick in Sicherungen im Backup Vault, die von der Appliance-Verwaltungskonsole erstellt wurden)

Architektur und Kernkomponenten von Backup und DR für die Verwaltungskonsole

Backup und DR für die Management Console verwendet eine dreistufige Architektur, um den Datenschutz in Ihrer Umgebung zu orchestrieren und auszuführen:

  • Appliance-Verwaltungskonsole: Die zentrale, webbasierte Steuerungsebene, auf der Sie Sicherungs-/Wiederherstellungs-Appliances verwalten, Hosts registrieren, Anwendungen erkennen, Sicherungsvorlagen und Ressourcenprofile konfigurieren sowie Sicherungs- und Wiederherstellungsjobs überwachen. Die Appliance-Verwaltungskonsole wird in einem von Google verwalteten Mandantenprojekt ausgeführt und kommuniziert über Private Service Connect oder den privater Google-Zugriff sicher mit Ihren Sicherungs-/Wiederherstellungs-Appliances.
  • Sicherungs-/Wiederherstellungs-Appliances: Virtuelle Compute Engine-Appliances, die in Ihrem Google Cloud -Projekt und VPC-Netzwerk bereitgestellt werden. Die Sicherungs-/Wiederherstellungs-Appliance fungiert als Datenebene, die Daten aus Quellarbeitslasten erfasst, Katalogmetadaten verwaltet, Speicherpools verwaltet, Daten auf Remote-Appliances oder Objektspeicher repliziert und sofortige Bereitstellungen ermöglicht. Sie können je nach Arbeitslasttyp, Dataset-Größe und Speicherkapazität aus vier Appliance-Formfaktoren auswählen.
  • Backup und DR-Agents: Einfache Software-Agents, die auf Linux- oder Windows-Gastbetriebssystemen installiert sind. Der Backup und DR-Agent kommuniziert mit der Sicherungs-/Wiederherstellungs-Appliance, um Datenbanken und Dateisysteme zu erkennen, Anwendungen für die anwendungskonsistente Erfassung stillzulegen, Changed Block Tracking (CBT) und Transaktionsprotokollsicherungen zu koordinieren und anwendungsorientierte Bereitstellungen zu orchestrieren. Der agentenlose Schutz wird für VMware-VMs (über vSphere Storage APIs – Datenschutz) und Compute Engine-Instanzen (über Snapshots von nichtflüchtigem Speicher) verwendet.

Speicherpools auf einer Sicherungs-/Wiederherstellungs-Appliance

Eine Sicherungs-/Wiederherstellungs-Appliance organisiert und speichert erfasste Sicherungsdaten in bis zu vier Arten von Speicherpools:

  • Primärer Pool: Blockspeicher, der direkt an die Sicherungs-/Wiederherstellungs-Appliance angehängt ist (mit Standard- oder nichtflüchtigem SSD-Speicher). Er speichert erfasste Sicherungen und deduplizierte Daten für eine schnelle lokale Wiederherstellung und sofortige Bereitstellung.
  • Snapshot-Pool: Speicher, der Persistent Disk-Snapshots verwendet, um zeitpunktbezogene Kopien von Datenvolumes für leistungsstarke Erfassungs- und Bereitstellungsvorgänge zu speichern.
  • OnVault-Pool: Objektbasierter Speicher für die langfristige Aufbewahrung, der komprimierte, inkrementelle Sicherungsdaten an einen Cloud Storage-Bucket (Standard, Nearline, Coldline oder Archive) oder einen von Google verwalteten Backup Vault sendet.
  • Spiegelpool: Blockspeicher auf einer sekundären Sicherungs-/Wiederherstellungs-Appliance in einer anderen Zone oder Region, die asynchrone, auf Blockebene replizierte Sicherungen (StreamSnap) für die Notfallwiederherstellung empfängt.

Sicherungsvorlagen, -richtlinien und -ressourcenprofile

In der Appliance-Verwaltungskonsole schützen Sie eine erkannte Arbeitslast, indem Sie einen Sicherungsplan anwenden, der aus zwei wiederverwendbaren Bausteinen besteht:

  • Backup-Vorlage: Definiert, wie und wann Daten gesichert, aufbewahrt und repliziert werden. Jede Sicherungsvorlage enthält eine oder mehrere Sicherungsrichtlinien, die Zeitpläne, Recovery Point Objectives (RPOs) und die Aufbewahrung über verschiedene Stufen hinweg steuern:
    • Produktion zu Snapshot: Erfasst Daten aus der Produktionsarbeitslast im lokalen primären Pool oder Snapshot-Pool.
    • Snapshot zu OnVault: Kopiert Snapshot-Sicherungen in einen OnVault-Pool in Cloud Storage oder einen Backup Vault zur langfristigen Aufbewahrung.
    • OnVault zu OnVault: Repliziert Daten zwischen OnVault-Pools in verschiedenen Regionen.
    • Produktion zu Spiegelung (StreamSnap): Repliziert Snapshot-Daten in einen Spiegelungspool auf einer Remote-Sicherungs-/Wiederherstellungs-Appliance.
  • Ressourcenprofil: Definiert, wo die Sicherungsdaten gespeichert werden. Dazu werden die Richtlinien in einer Sicherungsvorlage bestimmten lokalen Sicherungs-/Wiederherstellungs-Appliance-Speicherpools, OnVault-Pools und Remote-Replikations-Appliances zugeordnet.

Wichtige Funktionen von Backup und DR für die Verwaltungskonsole

Backup und DR für die Verwaltungskonsole bietet die folgenden Funktionen für die Sicherung, Wiederherstellung und das Kopiedatenmanagement in Unternehmen:

  • Inkrementelle Erfassung: Nach einer ersten Vollsicherung einer Anwendung oder VM werden bei nachfolgenden Sicherungen nur geänderte Blöcke oder Datenbankdeltas erfasst. Die Sicherungs-/Wiederherstellungs-Appliance synthetisiert virtuelle vollständige Point-in-Time-Images, ohne regelmäßige Vollsicherungen auszuführen, die sich auf die Produktionsleistung auswirken.
  • Anwendungskonsistenter Datenbankschutz und Wiederherstellung zu einem bestimmten Zeitpunkt (PITR): Wird nativ in Datenbank-APIs (wie Oracle RMAN, SQL Server VSS und SAP HANA backint oder Speicher-Snapshots) eingebunden, um anwendungskonsistente Datenbanksicherungen zusammen mit geplanten Transaktionsprotokollsicherungen zu erfassen, sodass Sie zu einem bestimmten Zeitpunkt wiederherstellen können.
  • Sofortige Bereitstellung und virtuelle Kopien: Anstatt zu warten, bis Terabyte an Sicherungsdaten zurück in den Produktionsspeicher kopiert wurden, bevor eine Anwendung gestartet werden kann, können Sie ein Sicherungs-Image direkt von der Sicherungs-/Wiederherstellungs-Appliance auf einem Zielhost bereitstellen:
    • Standardbereitstellung: Das Sicherungs-Image wird als bereitgestelltes Laufwerk oder Dateisystem auf einem Zielhost verfügbar gemacht, um einzelne Dateien zu prüfen oder zu kopieren.
    • Anwendungsspezifische Bereitstellung: Startet sofort eine virtuelle Datenbankinstanz direkt aus dem bereitgestellten Sicherungs-Image auf einem Zieldatenbankserver. Optional können Transaktionslogs auf einen ausgewählten Zeitpunkt vorgerollt werden.
    • Bereitstellen und migrieren: Der Dienst wird sofort über eine sofortige Bereitstellung wiederhergestellt, während die zugrunde liegenden Datendateien im Hintergrund zurück in den Produktionsspeicher migriert werden. Dadurch werden die Recovery Time Objectives (RTOs) minimiert.
    • LiveClone: Erstellt eine unabhängige, beschreibbare virtuelle Kopie eines Sicherungs-Images, die bei Bedarf oder nach einem Zeitplan aktualisiert werden kann, ohne dass für jeden Klon der gesamte physische Speicherplatz belegt wird.
  • Automatisierte Backup und DR-Workflows: Backup und DR-Workflows automatisieren die Erstellung, Aktualisierung und Maskierung von LiveClones und virtuellen Datenbanken nach einem Zeitplan oder bei Bedarf. Entwicklungs-, QA- und Analyseteams können aktuelle Kopien von Produktionsdatenbanken selbst bereitstellen, wobei sensible Daten automatisch durch benutzerdefinierte Skripts bereinigt werden.
  • Regionenübergreifende Notfallwiederherstellung: Replizieren Sie Sicherungs-Images asynchron auf eine sekundäre Sicherungs-/Wiederherstellungs-Appliance in einer anderen Region mithilfe der StreamSnap-Replikation oder kopieren Sie Sicherungen in multiregionale oder biregionale Cloud Storage-Buckets und Backup Vaults, damit Sie Arbeitslasten bei einem Ausfall in einer anderen Region wiederherstellen können.

Unterstützte Arbeitslasten in Backup und DR für die Verwaltungskonsole

Backup und DR für die Verwaltungskonsole schützt eine Vielzahl von virtuellen Maschinen, Dateisystemen und Datenbanken. Detaillierte Informationen zur Versions- und Betriebssystemkompatibilität finden Sie in der Supportmatrix für Appliance-verwaltete Sicherungen und unter Von Backup und DR unterstützte Betriebssysteme und Kernel.

  • Compute Engine-Instanzen: Agentenloser, absturzkonsistenter Snapshot-Schutz und projekt- oder regionsübergreifende Wiederherstellung für Compute Engine-VMs.
  • Google Cloud VMware Engine- und VMware vSphere-VMs: Agentenlose Sicherung auf VM-Ebene, sofortige Bereitstellung, LiveClone und vollständige VM-Wiederherstellung für vCenter- und ESX-Hosts mit VMware Changed Block Tracking (CBT).
  • Dateisysteme und Filestore: Block- und dateibasierte Sicherung und sofortige Bereitstellung für Linux- und Windows-Dateisysteme, NFS-Freigaben, SMB/CIFS-Freigaben und Filestore-Instanzen.
  • Oracle-Datenbanken: Inkrementeller Schutz mit Oracle RMAN-Image-Kopien und Änderungsverfolgung, Archivprotokollsicherungen für PITR, sofortige virtuelle Datenbankbereitstellungen sowie Bereitstellung und Migration.
  • Microsoft SQL Server-Datenbanken: Anwendungskonsistente Sicherungen für eigenständige Instanzen und AlwaysOn-Verfügbarkeitsgruppen, Transaktionsprotokollsicherungen, virtuelle Datenbankbereitstellungen und Datenbankklone.
  • SAP HANA-Datenbanken: Schutz auf Volume-Ebene (Persistent Disk-Snapshot oder LVM) und Dateiebene (backint) für Single-Host-, 1+n- und SAP HANA-Systeme mit horizontaler Skalierung.
  • IBM Db2-Datenbanken: Inkrementelle Sicherungen auf Volume-Ebene und vollständige und inkrementelle Dump-Sicherungen mit Transaktionslog-Erfassung und virtuellen Datenbankbereitstellungen.
  • Andere selbstverwaltete Datenbanken: Schutz für PostgreSQL-, MySQL-, MariaDB-, SAP ASE-, SAP IQ- und SAP MaxDB-Datenbanken sowie für Konsistenzgruppen und generische LVM-Anwendungen.

Nächste Schritte