Der Backup Vault ist eine von Google verwaltete regionale Ressource, die einen isolierten, unveränderlichen und nicht löschbaren Speicher für Sicherungen bietet. Dabei werden Daten in einer Hierarchie aus Vaults, Datenquellen und Sicherungen organisiert und durch erzwungene Aufbewahrungszeiträume und Identitätsisolation auf Projektebene vor versehentlichem oder böswilligem Löschen geschützt.
In diesem Dokument wird beschrieben, wie Sicherungstresore funktionieren, einschließlich des hierarchischen Ressourcenmodells, unterstützter Arbeitslasten, Sicherungsmodelle, Standortkompatibilität, Verfügbarkeit und Benennungsanforderungen.
Ressourcenhierarchie
Daten im Backup- und DR-Dienst sind in einer dreistufigen Hierarchie im Backup Vault organisiert:
Backup Vault: Ein Container der obersten Ebene, in dem globale Mindestaufbewahrungsrichtlinien erzwungen werden.
Datenquelle: Eine untergeordnete Ressource, die eine bestimmte geschützte Einheit darstellt (z. B. eine Compute Engine-Instanz). Das System erstellt diese automatisch bei der ersten Sicherung.
Sicherung: Eine untergeordnete Ressource einer Datenquelle, die eine separate Sicherung mit einem bestimmten Wiederherstellungspunkt zu einem bestimmten Zeitpunkt darstellt.
Das folgende Diagramm zeigt das Backup Vault-Ressourcenmodell:
Beschränkungen
Auf dieser Seite werden Sicherungstresore für Ressourcen beschrieben, die über die Google Cloud -Konsole verwaltet werden, z. B. Compute Engine oder Cloud SQL. Wenn Sie die Appliance-Verwaltungskonsole für Arbeitslasten wie Oracle oder Google Cloud VMware Engine verwenden, lesen Sie den Abschnitt Von der Appliance-Verwaltungskonsole verwaltete Backup-Vaults.
AlloyDB-Cluster und Filestore-Instanzen in Backup Vaults werden für Multiregionen nicht unterstützt.
Der Backup- und DR-Dienst unterliegt bei der Wiederherstellung einer Arbeitslast aus einem Backup in einem Backup Vault keinen Einschränkungen hinsichtlich der kompatiblen Zielstandorte.
Je nach Standort Ihres Backup Vaults und Ihrer Quell-Arbeitslast können Gebühren für die Netzwerkübertragung anfallen. Weitere Informationen finden Sie unter Preise für den Backup- und DR-Dienst.
Unterstützte Ressourcen
| Arbeitslasttyp | Verwaltung |
|---|---|
| Compute Engine-Instanz | Google Cloud Console |
| Compute Engine-Laufwerk | Google Cloud Console |
| Filestore-Instanz | Google Cloud Console |
| Cloud SQL-Instanz | Google Cloud Console |
| AlloyDB-Cluster | Google Cloud Console |
| Google Cloud VMware Engine, Oracle-Datenbank und SQL Server-Datenbank | Appliance-Verwaltungskonsole |
Sicherungsmodelle für Ressourcen
| Zentralisiertes Modell | Dezentrales Modell | |
|---|---|---|
| Google Cloud Console | Konsolidiert die Sicherungsverwaltung durch Erstellen von Backup Vaults und Sicherungsplänen in einem zentralen Administratorprojekt. Administratoren können diese zentral verwalteten Pläne verwenden, um Ressourcen in mehreren Dienstprojekten zu schützen, oder IAM-Berechtigungen verwenden, um den Zugriff auf Sicherungspläne an Anwendungsinhaber zu delegieren. |
Isoliert die Sicherungsverwaltung, indem in jedem Projekt ein separater Backup Vault und ein separater Sicherungsplan erstellt werden. Dieser Ansatz ist ideal für dezentrale Organisationen, in denen einzelne Anwendungsteams für die Sicherung ihrer eigenen Ressourcen verantwortlich sind. |
| Verwaltungskonsole für Appliances | Konsolidiert die Sicherungsverwaltung durch Bereitstellung der Appliance-Verwaltungskonsole und Erstellung von Backup Vaults in einem zentralen Administratorprojekt. Administratoren konfigurieren Sicherungsrichtlinien in der zentralen Verwaltungskonsole, um Ressourcen wie Google Cloud VMware Engine-VMs in mehreren Dienstprojekten zu schützen. |
Isoliert die Sicherungsverwaltung durch die Bereitstellung einer separaten Appliance-Verwaltungskonsole und eines separaten Backup Vault für jedes Projekt oder jede Line of Business. Dieser Ansatz ist ideal für dezentrale Organisationen, in denen die Zuständigkeiten für die Sicherungsverwaltung auf mehrere Teams aufgeteilt sind. |
Unterstützte Standorte für Backup Vaults
Sie können einen Backup Vault in derselben Region wie die Quell-Workload (regional), in einer anderen Region als die Quell-Workload (regionenübergreifend) oder in mehreren Regionen (multiregional) erstellen.
Unterstützte Regionen und regionenübergreifende Funktionen
Sie können Backup Vaults in den folgenden Regionen und regionenübergreifend erstellen:
| 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 | ||
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 | ||
europe-west9 |
Paris |
Niedriger CO2-Wert
|
|
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 (northamerica-south1), Montreal (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 kann ein einzelnes, lokalisiertes physisches Katastrophenereignis möglicherweise mehrere Zonen innerhalb derselben Region beeinträchtigen, was das Risiko eines Datenverlusts im Vergleich zu Regionen mit Zonentrennung erhöht.
Unterstützte Mehrfachregionen
Sie können Sicherungs-Vaults in den folgenden Multi-Regionen erstellen:
| Name des multiregionalen Standorts | Beschreibung |
|---|---|
ASIA |
Rechenzentren in Asien |
EU |
Rechenzentren in der Europäischen Union |
US |
Rechenzentren in den USA |
Kompatibilität des Arbeitslaststandorts
In der folgenden Tabelle werden die kompatiblen Backup Vault-Standorte für die einzelnen unterstützten Arbeitslasten beschrieben, wenn regionale und regionenübergreifende Backup Vaults verwendet werden. Sicherungspläne in der Google Cloud -Konsole müssen in derselben Region wie die Quell-Arbeitslast erstellt werden.
| Arbeitslast | Das Backup Vault muss sich in derselben Region wie die Quell-Workload befinden. | Regionale Unterstützung | Unterstützung für mehrere Regionen | Regionenübergreifende Unterstützung |
|---|---|---|---|---|
| Compute Engine-Instanz | Nein | |||
| Compute Engine-Laufwerk | Nein | |||
| Cloud SQL-Instanz | Ja | |||
| AlloyDB-Cluster | Ja | |||
| Filestore-Instanz | Nein | |||
| Google Cloud VMware Engine, Oracle-Datenbank und SQL Server-Datenbank | Nein |
Kompatibilität mit mehreren Regionen
Die folgenden Anforderungen müssen erfüllt sein, damit Sie mehrere Regionen verwenden können:
Wenn eine Arbeitslast multiregionale Backup Vaults unterstützt, muss der Speicherort der Quellarbeitslast mit dem Speicherort des multiregionalen Backup Vault kompatibel sein.
Sie können nur Ressourcen in Regionen sichern, die dasselbe Präfix haben. Ressourcen in Regionen mit dem Präfix
asiadürfen beispielsweise nur in der Multiregionasiagesichert werden.
In der folgenden Tabelle werden die kompatiblen Speicherorte für Backup Vaults für die einzelnen unterstützten Arbeitslasten bei Verwendung von multiregionalen Backup Vaults beschrieben:
| Arbeitslasttyp | Unterstützt die Verwendung von multiregionalen Backup Vaults? | Unterstützte multiregionale Backup Vaults |
|---|---|---|
| Compute Engine-Instanz | asia, eu, us |
|
| Compute Engine-Laufwerk | asia, eu, us |
|
| Filestore-Instanz | – | |
| Cloud SQL-Instanz | asia, eu, us |
|
| AlloyDB-Cluster | – | |
| Google Cloud VMware Engine, Oracle-Datenbank und SQL Server-Datenbank | – |
Verfügbarkeit
Backup Vaults, die an regionalen und regionenübergreifenden Standorten erstellt werden, bieten Schutz vor Ausfällen in einer einzelnen Zone. Sicherungsdaten werden redundant in mindestens zwei separaten Zonen gespeichert.
Backup Vaults, die an Multi-Region-Standorten erstellt werden, bieten Schutz vor Ausfällen in einer einzelnen Region. Sicherungsdaten werden redundant in mindestens zwei separaten Regionen gespeichert.
Multiregionale und regionenübergreifende Backup Vaults vergleichen
| Kriterium | Multiregionale Sicherungen | Regionenübergreifende Sicherungen |
|---|---|---|
| Sicherung erstellen | Automatisiert von Google in zwei Regionen auf einem Kontinent. | Sie können eine Region explizit für die Sicherung definieren. |
| Anwendungsfall | Hochverfügbarkeit und einfache Bedienung | Strikte Compliance, Gesetze zum Datenstandort oder gezielte Notfallwiederherstellungsstandorte innerhalb und außerhalb der regionalen Grenzen der Quelle. |
| Verwaltung | Geringer Aufwand. Ein Tresor, automatischer Ausgleich | Mittlerer Overhead Erfordert die Einrichtung einer bestimmten Zielgruppenkombination. |
| Kundenverwaltete Verschlüsselungsschlüssel (CMEK, Customer-Managed Encryption Keys) | Für multiregionale Backup Vaults muss CMEK aus derselben Region wie die Backup Vault verwendet werden. | Für regionsübergreifende Backup Vaults muss CMEK aus derselben Region wie der Backup Vault verwendet werden. |
| Auswirkungen auf die Kosten | Gebühr für multiregionale Uploads und Downloads, falls zutreffend. Gebühr für den Backup-Speicher für einen multiregionalen Vault. Verwaltungsgebühr. | Gebühren für die interregionale Datenübertragung. Gebühr für Sicherungsspeicher Verwaltungsgebühr. |
| Unterstützte Arbeitslasten |
|
|
Namen von Backup Vaults
Namen von Backup Vaults müssen die folgenden Anforderungen erfüllen:
Backup Vault-Namen dürfen nur Kleinbuchstaben, Ziffern und Bindestriche (
-) enthalten. Leerzeichen sind nicht zulässig.Namen von Sicherungstresoren müssen mit einer Ziffer oder einem Buchstaben beginnen und enden.
Namen von Backup Vaults müssen zwischen 3 und 63 Zeichen lang sein. Namen mit Punkten dürfen bis zu 222 Zeichen lang sein, wobei jeder durch einen Punkt getrennte Teil nicht mehr als 63 Zeichen enthalten darf.
Namen von Backup Vaults dürfen nicht wie eine IP-Adresse in Dezimalpunktschreibweise dargestellt werden. Beispiel:
192.0.2.255.
Löschen der Sicherung verhindern
Um Ihre Daten vor versehentlichem oder böswilligem Löschen zu schützen, konfigurieren Sie (der Administrator) einen erzwungenen Aufbewahrungszeitraum für Ihren Backup Vault. Nach der Konfiguration sind Back-ups unveränderlich. Sie können nicht manuell von Ihnen, anderen Nutzern oder Google gelöscht werden, bevor der von Ihnen angegebene Zeitraum abgelaufen ist.
Sie können die erzwungene Aufbewahrung mit drei Haupteinstellungen für Vault steuern:
- Erzwungene Mindestaufbewahrung: Wenn Sie einen Vault erstellen, müssen Sie eine Mindestaufbewahrungsdauer (zwischen 1 Tag und 99 Jahren) festlegen. Dadurch wird ein obligatorischer Mindestpreis für das gesamte Archiv festgelegt:
Vor Ablauf dieser Zeit kann keine Sicherung gelöscht werden. Für jeden Sicherungsplan, in dem Daten in diesem Vault gespeichert werden, muss eine Aufbewahrungsdauer für Sicherungen festgelegt sein, die mindestens so lang ist wie dieser Mindestzeitraum.
Aufbewahrung von der Sicherungsregel übernehmen: Anstatt sich nur auf die Mindestaufbewahrung des Vaults zu verlassen, können Sie den Vault so konfigurieren, dass er den genauen Aufbewahrungszeitraum übernimmt, der in Ihren spezifischen Sicherungsplänen definiert ist. Sie müssen diese Einstellung beim Erstellen des Vaults aktivieren.
Wenn die Mindestaufbewahrungsdauer Ihres Vaults 3 Tage beträgt, die Aufbewahrungsdauer Ihres Sicherungsplans jedoch 7 Tage, wird die Sicherung für die vollen 7 Tage gesperrt. Ergebnis: Das manuelle Löschen wird vollständig verhindert. Sicherungen werden erst automatisch gelöscht, wenn die im Sicherungsplan festgelegte Dauer abgelaufen ist.
Erzwungene Aufbewahrungsdauer sperren: Bei strengen Compliance-Anforderungen können Sie die Konfiguration der erzwungenen Mindestaufbewahrung dauerhaft sperren.
Wenn Sie eine Sperre einrichten, wählen Sie ein Datum für das Inkrafttreten aus. Vor dem Datum des Inkrafttretens können Sie die Mindestaufbewahrungsdauer noch nach oben oder unten anpassen, um Fehler zu korrigieren. Nach dem Datum des Inkrafttretens kann niemand (auch kein Project Owner) die Aufbewahrungsdauer verkürzen. Sie dürfen sie nur erhöhen.
Backup Vault-Zugriffsbeschränkung
Mit der Einstellung für Zugriffsbeschränkungen eines Backup Vault können Sie die Quellen steuern, aus denen Daten in einen Backup Vault gesichert oder aus einem Backup Vault wiederhergestellt werden können. Mit dieser Einstellung wird festgelegt, welche Arten von Ressourcen Sie in einem Backup Vault speichern können.
Sie können eine der folgenden Einstellungen für die Zugriffsbeschränkung für einen Backup Vault auswählen. Diese Einstellung ist dauerhaft und kann nicht geändert werden.
Zugriff auf aktuelle Organisation beschränken: Sicherungs- und Wiederherstellungsvorgänge werden nur in Ihrer aktuellen Organisation unterstützt. Durch diese Auswahl ist der Backup Vault mit Ressourcen kompatibel, die über dieGoogle Cloud -Konsole verwaltet werden, z. B. Compute Engine-Instanzen, aber nicht mit Ressourcen, die über die Appliance-Verwaltungskonsole verwaltet werden.
Zugriff auf aktuelles Projekt beschränken: Sicherungs- und Wiederherstellungsvorgänge werden nur in Ihrem aktuellen Projekt unterstützt. Durch diese Auswahl wird der Backup Vault mit Ressourcen kompatibel, die über dieGoogle Cloud -Konsole verwaltet werden (z. B. Compute Engine-Instanzen), aber nicht mit Ressourcen, die über die Verwaltungskonsole der Appliance verwaltet werden.
Zugriff auf aktuelle Organisation beschränken, aber uneingeschränkter Zugriff für Sicherungs-Appliances: Bei Ressourcen, die über die Google Cloud -Konsole verwaltet werden, werden Sicherungs- und Wiederherstellungsvorgänge nur innerhalb Ihrer aktuellen Organisation unterstützt. Ressourcen, die über die Appliance-Verwaltungskonsole verwaltet werden (z. B. Google Cloud VMware Engine-VMs), werden ebenfalls unterstützt. Sicherungs- und Wiederherstellungsvorgänge für diese Ressourcen sind jedoch nicht auf Ihre aktuelle Organisation beschränkt. Durch diese Auswahl wird der Backup Vault mit Ressourcen kompatibel, die über dieGoogle Cloud -Konsole verwaltet werden, und mit Ressourcen, die über die Appliance-Verwaltungskonsole verwaltet werden.
Uneingeschränkten Zugriff zulassen: Ermöglicht Sicherungs- und Wiederherstellungsvorgänge in oder aus beliebigen Projekten oder Organisationen. Durch diese Auswahl wird der Backup Vault mit Ressourcen kompatibel, die über die Google Cloud -Konsole verwaltet werden, und mit Ressourcen, die über die Appliance-Verwaltungskonsole verwaltet werden.
Verschlüsselung
Standardmäßig verschlüsselt Google Cloud Daten im Ruhezustand automatisch mit Google-owned and Google-managed encryption keys. Wenn Sie bestimmte Compliance- oder behördliche Anforderungen in Bezug auf die Schlüssel zum Schutz Ihrer Daten haben, können Sie für Ihre Sicherungen kundenverwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK) verwenden. Weitere Informationen finden Sie unter Vom Kunden verwaltete Verschlüsselungsschlüssel (CMEK).
Nächste Schritte
- Backup Vault in der Google Cloud Console erstellen und verwalten
- Compute Engine-Instanzen in einem Backup-Vault sichern
- Cloud SQL-Instanzen in einem Backup-Vault sichern
- AlloyDB-Cluster in einem Backup Vault sichern
- Filestore-Instanzen in einem Backup Vault sichern
- Laufwerke in einem Backup Vault sichern