Der Backup Vault ist eine von Google verwaltete regionale Ressource, die einen isolierten, unveränderlichen und nicht löschbaren Speicher für Sicherungen bietet. Daten werden in einer Hierarchie aus Vaults, Datenquellen und Sicherungen organisiert. Durch erzwungene Aufbewahrungszeiträume und Identitätsisolation auf Projektebene werden Daten vor versehentlichem oder böswilligem Löschen geschützt.
In diesem Dokument wird erläutert, wie Backup Vaults funktionieren, einschließlich des hierarchischen Ressourcenmodells, der unterstützten Arbeitslasten, der Sicherungsmodelle, der Standortkompatibilität, der Verfügbarkeit und der Anforderungen an die Benennung.
Ressourcenhierarchie
Daten in Backup und DR werden im Backup Vault in einer dreistufigen Hierarchie organisiert:
Backup Vault: Ein übergeordneter Container, der globale Mindestaufbewahrungsrichtlinien erzwingt.
Datenquelle: Eine untergeordnete Ressource, die eine bestimmte geschützte Entität darstellt (z. B. eine Compute Engine-Instanz). Das System erstellt diese automatisch bei der ersten Sicherung.
Sicherung: Eine untergeordnete Ressource einer Datenquelle, die eine einzelne Sicherung mit einem bestimmten Wiederherstellungspunkt darstellt.
Das folgende Diagramm zeigt das Ressourcenmodell für Backup Vaults:
Beschränkungen
Auf dieser Seite werden Backup Vaults für Ressourcen beschrieben, die über die Google Cloud Console 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, finden Sie weitere Informationen unter Übersicht über Backup Vaults, die über die Appliance-Verwaltungskonsole verwaltet werden.
AlloyDB-Cluster und Filestore-Instanzen in Backup Vaults werden für Multiregionen nicht unterstützt.
Backup und DR legt keine Einschränkungen für die kompatiblen Zielorte fest, wenn eine Arbeitslast aus einer Backup Vault-Sicherung wiederhergestellt wird.
Je nach Standort Ihres Backup Vaults und der Quellarbeitslast können Gebühren für die Netzwerkübertragung anfallen. Weitere Informationen finden Sie unter Preise für Backup und DR.
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. |
| Appliance-Verwaltungskonsole | Konsolidiert die Sicherungsverwaltung, indem die Appliance-Verwaltungskonsole bereitgestellt und Backup Vaults in einem zentralen Administratorprojekt erstellt werden. Administratoren konfigurieren Sicherungsrichtlinien in der zentralen Verwaltungskonsole, um Ressourcen wie Google Cloud VMware Engine-VMs in mehreren Dienstprojekten zu schützen. |
Isoliert die Sicherungsverwaltung, indem für jedes Projekt oder jede Line of Business eine separate Appliance-Verwaltungskonsole und ein separater Backup Vault bereitgestellt werden. Dieser Ansatz ist ideal für dezentrale Organisationen, in denen die Verantwortlichkeiten für die Sicherungsverwaltung auf mehrere Teams aufgeteilt sind. |
Unterstützte Standorte für Backup Vault
Sie können einen Backup Vault in derselben Region wie die Quellarbeitslast (regional), in einer anderen Region als die Quellarbeitslast (regionenübergreifend) oder in mehreren Regionen (multiregional) erstellen.
Unterstützte Regionen und regionenübergreifende Regionen
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 |
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 Zonenseparation. Das bedeutet, dass sich die mehreren Zonen innerhalb jeder dieser Regionen möglicherweise nicht in physisch getrennten Rechenzentrumscampus befinden. Daher könnte ein einzelnes, lokal begrenztes physisches Katastrophenereignis potenziell mehrere Zonen innerhalb derselben Region betreffen, was das Risiko von Datenverlusten im Vergleich zu Regionen mit Zonentrennung erhöht.
Unterstützte Multiregionen
Sie können Backup Vaults in den folgenden Multiregionen 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 jede unterstützte Arbeitslast beschrieben, wenn regionale und überregionale Backup Vaults verwendet werden. Sicherungspläne in der Google Cloud Console müssen in derselben Region wie die Quellarbeitslast erstellt werden.
| Arbeitslast | Das Backup Vault muss sich in derselben Region wie die Quellarbeitslast 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 |
Multiregionale Kompatibilität
Die folgenden Anforderungen müssen erfüllt sein, um Multiregionen zu verwenden:
Wenn eine Arbeitslast multiregionale Backup Vaults unterstützt, muss der Standort der Quellarbeitslast mit dem Standort des multiregionalen Backup Vaults kompatibel sein.
Sie können nur Ressourcen in Regionen sichern, die dasselbe Präfix haben. Beispiel: Ressourcen in Regionen mit dem Präfix
asiadürfen nur in der Multiregionasiagesichert werden.
In der folgenden Tabelle werden die kompatiblen Backup Vault-Standorte für jede unterstützte Arbeitslast beschrieben, wenn multiregionale Backup Vaults verwendet werden:
| 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 einem Ausfall einer einzelnen Zone. Sicherungsdaten werden redundant in mindestens zwei separaten Zonen gespeichert.
Backup Vaults, die an multiregionalen Standorten erstellt werden, bieten Schutz vor einem Ausfall 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 innerhalb eines Kontinents. | Autonomie, um explizit eine Region zum Erstellen einer Sicherung zu definieren. |
| Anwendungsfall | Hochverfügbarkeit und einfacher Betrieb | Strikte Compliance, Gesetze zum Datenstandort oder gezielte Notfallwiederherstellungsstandorte innerhalb und außerhalb der regionalen Grenzen der Quelle. |
| Verwaltung | Geringer Aufwand. Einzelner Vault, automatisches Balancing | Mittlerer Aufwand. Erfordert die Einrichtung einer bestimmten Zielkopplung. |
| Kundenverwaltete Verschlüsselungsschlüssel (CMEK, Customer-Managed Encryption Keys) | Ein multiregionaler Backup Vault muss einen CMEK aus derselben Region wie der Backup Vault verwenden. | Für einen regionenübergreifenden Backup Vault muss ein 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 Sicherungsspeicher für 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
Die Namen Ihrer 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 Backup-Vaults müssen mit einer Ziffer oder einem Buchstaben beginnen und enden.
Backup Vault-Namen müssen 3–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.
Backup Vault-Namen 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) eine erzwungene Aufbewahrungsdauer für Ihren Backup Vault. Nach der Konfiguration sind Sicherungen vollständig unveränderlich. Sie können weder von Ihnen noch von anderen Nutzern oder von Google manuell gelöscht werden, bis die von Ihnen angegebene Dauer abgelaufen ist.
Sie können die erzwungene Aufbewahrung über drei Haupt-Vault-Einstellungen steuern:
- Erzwungene Mindestaufbewahrung: Beim Erstellen eines Vaults müssen Sie eine grundlegende Aufbewahrungsdauer (zwischen 1 Tag und 99 Jahren) festlegen. Dadurch wird ein obligatorischer Mindestpreis für den gesamten Vault erstellt:
Vor Ablauf dieser Zeit kann keine Sicherung gelöscht werden. Alle Sicherungspläne, die Daten in diesem Vault speichern, müssen eine Aufbewahrungsdauer für Sicherungen haben, die mindestens so lang ist wie dieser Mindestwert.
Aufbewahrung aus der Sicherungsregel übernehmen: Anstatt sich nur auf die Mindestaufbewahrung des Vaults zu verlassen, können Sie den Vault so konfigurieren, dass er die genaue Aufbewahrungsdauer übernimmt, die 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 gesamten 7 Tage gesperrt. Ergebnis: Das manuelle Löschen wird vollständig verhindert. Sicherungen werden erst automatisch gelöscht, wenn die im Sicherungsplan angegebene Dauer abgelaufen ist.
Erzwungene Aufbewahrungsdauer sperren: Für strenge Compliance-Anforderungen können Sie die Konfiguration der erzwungenen Mindestaufbewahrung dauerhaft sperren.
Wenn Sie eine Sperre festlegen, wählen Sie ein Datum des Inkrafttretens 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 Vaults können Sie die Quellen steuern, aus denen Daten in einem Backup Vault gesichert oder wiederhergestellt werden können. Diese Einstellung bestimmt die Typen von Ressourcen, die Sie in einem Backup Vault speichern können.
Sie können eine der folgenden Zugriffsbeschränkungseinstellungen 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 innerhalb Ihrer aktuellen Organisation unterstützt. Durch diese Auswahl ist der Backup Vault mit Ressourcen kompatibel, die über dieGoogle Cloud Console 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 innerhalb Ihres aktuellen Projekts unterstützt. Durch diese Auswahl wird die 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 aktuelle Organisation beschränken, aber uneingeschränkter Zugriff für Sicherungs-Appliances: Für 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. Dadurch ist die Backup Vault mit Ressourcen kompatibel, die über dieGoogle Cloud Console verwaltet werden, und mit Ressourcen, die über die Appliance-Verwaltungskonsole verwaltet werden.
Uneingeschränkten Zugriff zulassen: Ermöglicht Sicherungs- und Wiederherstellungsvorgänge für beliebige Projekte oder Organisationen. Durch diese Auswahl wird der Backup Vault mit Ressourcen kompatibel, die über die Google Cloud Console 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 Kundenverwaltete Verschlüsselungsschlüssel (CMEK).
Nächste Schritte
- Schutz von Compute Engine-Instanzen automatisieren
- Backup Vault in der Google Cloud Console erstellen und verwalten
- Laufwerke in einer Backup Vault sichern