Auf dieser Seite werden Sicherungspläne beschrieben, mit denen Sie erweiterte Sicherungsstrategien zum Sichern Ihrer Ressourcen definieren können. Sie können Sicherungspläne verwenden, um die folgenden Ressourcen zu sichern:
Cloud SQL-Instanzen
Compute Engine-Instanzen und -Laufwerke
AlloyDB for PostgreSQL-Cluster
Filestore-Instanzen
In einem Sicherungsplan können Sie festlegen, wann und wie eine Ressource gesichert werden soll. Sie können die Sicherungshäufigkeit, den Aufbewahrungszeitraum für Sicherungen und den Speicherort des Backup Vault für die Speicherung von Sicherungen angeben. Wenn Sie einen Sicherungsplan einer Ressource zuordnen, werden die Sicherungen für diese Ressourcen von Backup und DR automatisch gemäß der Konfiguration im Sicherungsplan erstellt und aufbewahrt.
Bevor Sie einen Sicherungsplan erstellen, müssen Sie den Speicherort für Ihre Sicherungen festlegen, indem Sie einen Backup Vault erstellen.
Ein Sicherungsplan enthält eine oder mehrere Sicherungsregeln. In jeder Sicherungsregel werden die folgenden Parameter definiert:
Häufigkeit: Sie können Sicherungen so planen, dass sie stündlich, täglich, wöchentlich, monatlich oder jährlich ausgeführt werden.
Stündlich: Die verfügbare Häufigkeit hängt vom Ressourcentyp ab. Weitere Informationen finden Sie unter Häufigkeitsbereiche für stündliche Sicherungen.
Wöchentlich: Sie können einen bestimmten Wochentag auswählen.
Monatlich: Sie können einen bestimmten Tag des Monats auswählen, z. B. den 15.
Sicherungstyp: Sie können Regeln für geplante Sicherungen verwenden oder On‑Demand-Sicherungen starten.
Sicherungszeitraum: Sie können den Zeitraum definieren, in dem Sicherungsjobs gestartet werden können. Für das Sicherungsfenster gelten die folgenden Anforderungen:
Es muss das 24‑Stunden-Format verwendet werden. Die Start- und Endzeiten müssen zwischen 00 und 24 liegen.
Sie muss mindestens sechs Stunden lang sein.
Einschränkung: Ein Sicherungsplan umfasst immer das Bootlaufwerk. Wenn Sie im Abschnitt Datenschutz der Maschinenkonfiguration die Option Bootlaufwerk ausschließen auswählen, ist das Bootlaufwerk trotzdem im Sicherungsplan enthalten. Weitere Informationen finden Sie unter VM-Instanz mit zusätzlichen Nicht-Bootlaufwerken erstellen.
Häufigkeitsbereiche für stündliche Sicherungen
In diesem Abschnitt wird die Häufigkeit für stündliche Sicherungen angegeben. Bei einer stündlichen Häufigkeit von 1 werden Jobs jede Stunde vom Start- bis zum Endzeitpunkt ausgeführt.
Wenn
recurrence_typeaufHOURLYgesetzt ist, ist diese Einstellung erforderlich.Wenn
recurrence_typenichtHOURLYist, gilt diese Einstellung nicht.Wenn Sie einen Wert für diese Einstellung angeben und
recurrence_typenichtHOURLYist, tritt ein Validierungsfehler auf.
Die unterstützten Werte für die einzelnen Ressourcentypen sind:
| Ressourcentyp | Stündliche Häufigkeit |
|---|---|
| Compute Engine-Instanz | 1-23 |
| Compute Engine-Laufwerk | 1-23 |
| Cloud SQL-Instanz | 6-23 |
| AlloyDB for PostgreSQL-Cluster | 1-23 |
| Filestore-Instanz | 1-23 |
Informationen zu Compute Engine-Instanzressourcen finden Sie unter Best Practices für stündliche Back-ups.
Sicherungen von Datenbanklogs
Für Datenbankressourcen wie Cloud SQL oder AlloyDB können Sie Protokollsicherungen im Sicherungsplan aktivieren. Dies ermöglicht die Wiederherstellung zu einem bestimmten Zeitpunkt, da Transaktionslogs zwischen den vollständigen Sicherungen erfasst werden.
Übersicht über die Datenaufbewahrung in Backup and DR
Backup and DR verwaltet den Sicherungslebenszyklus und die Sicherheit mit zwei Aufbewahrungsarten:
Zugewiesene Aufbewahrungsdauer: Wird im Sicherungsplan mit der Einstellung Sicherungen löschen nach definiert.
Sicherungen werden für diesen Zeitraum aufbewahrt und laufen am Ende des Zeitraums ab.
Sie können Sicherungen vor diesem Datum manuell löschen, sofern die erzwungene Aufbewahrung dies nicht verhindert.
Erzwungener Aufbewahrungszeitraum: Wird in der Konfiguration des Backup Vaults mit der Einstellung Löschen verhindern für definiert.
Mit dieser Einstellung wird verhindert, dass Sicherungen für den angegebenen Zeitraum gelöscht werden können.
Wenn die erzwungene Aufbewahrungsdauer länger als die zugewiesene Aufbewahrungsdauer ist, werden Sicherungen erst nach Ablauf der erzwungenen Aufbewahrungsdauer gelöscht.
Sie können eine erzwungene Aufbewahrungsdauer auf einen gesamten Backup-Vault anwenden oder den Backup-Vault so konfigurieren, dass die zugewiesene Aufbewahrungsdauer (Sicherungen löschen nach) für jede geschützte Ressource erzwungen wird.
Maximale benutzerdefinierte On‑Demand-Aufbewahrung
Mit dieser Einstellung wird die maximale Anzahl von Tagen festgelegt, die eine On-Demand-Sicherung (manuell außerhalb des automatischen Zeitplans erstellt) aufbewahrt werden kann. So wird verhindert, dass Nutzer versehentlich zu lange Aufbewahrungszeiträume für manuelle Snapshots festlegen.
Verbrauch von Sicherungsspeicher
Beachten Sie die folgenden Regeln für den Sicherungsspeicher in einem Sicherungsplan:
Automatisches Löschen: Sicherungen werden automatisch gelöscht, wenn die definierte Aufbewahrungsdauer für Sicherungen erreicht ist.
Mindestaufbewahrung: Die Aufbewahrungsdauer für Sicherungen muss mindestens so lang sein wie die Mindestaufbewahrungsdauer des Backup Vaults.
Geerbter Standardwert: Der Standardwert für das Löschen von Sicherungen wird vom Mindestaufbewahrungszeitraum des Backup Vaults übernommen.
Unveränderlichkeit: Mit einem Sicherungsplan erstellte Sicherungen sind unveränderlich. Sie können während der erzwungenen Mindestaufbewahrungsdauer des Backup Vaults nicht geändert oder gelöscht werden.
Arbeitslasten in einem CMEK-fähigen Backup Vault sichern
Wenn Sie einen Backup Vault mit CMEK konfigurieren, werden die darin gespeicherten Backups mit dem von Ihnen angegebenen Schlüssel geschützt. Die folgenden Regeln gelten, wenn Sie einen Sicherungsplan mit einem CMEK-fähigen Vault verknüpfen:
CMEK-geschützte Arbeitslasten: Wenn eine Quellarbeitslast durch CMEK geschützt ist (z. B. eine Compute Engine-Instanz mit CMEK-verschlüsselten Laufwerken), müssen Sie sie in einem CMEK-fähigen Backup Vault sichern. Sie können keine CMEK-geschützte Ressource in einem Backup Vault sichern, der Google-owned and Google-managed encryption keysverwendet.
Arbeitslasten mit Google-owned and Google-managed encryption keys: Wenn eine Quellarbeitslast Google-owned and Google-managed encryption keysverwendet, müssen Sie sie in einem Backup Vault sichern, der Google-owned and Google-managed encryption keysverwendet.
Wiederholungsversuche für Sicherungsjobs
Wenn ein geplanter Job fehlschlägt, wird er vom Planer automatisch bis zu dreimal wiederholt.
- Erster Fehler: Der Status wird als „Wiederholt“ markiert und es wird 4 Minuten gewartet.
- Zweiter Fehler: Der nächste Wiederholungsversuch wird nach 16 Minuten in die Warteschlange gestellt.
- Dritter Fehler: Der letzte Wiederholungsversuch wird nach 64 Minuten in die Warteschlange gestellt.
- Endgültiger Fehler: Nach insgesamt vier Versuchen ändert sich der Status in „Fehler“. Für diesen Zeitraum werden keine weiteren Jobs ausgeführt.
Job-Wiederholungen werden unter Überwachen > Jobs gemeldet. Zur Identifizierung von Wiederholungsversuchen haben alle vier Jobs dieselbe Jobnummer mit einem eindeutigen Suffix (z.B. Job_12345, Job_12345a, Job_12345b).
Von Sicherungsplänen unterstützte Regionen
Sicherungspläne können nur in Regionen erstellt werden, in denen Backup und DR verfügbar ist und in denen sich die zu sichernden Ressourcen befinden. Zum Erstellen eines Sicherungsplans muss auch ein Backup Vault an einem kompatiblen Standort verfügbar sein. Wenn Sie einen Sicherungsplan in einer nicht unterstützten Region erstellen müssen, verwenden Sie die Sicherungsvorlagen in der Appliance-Verwaltungskonsole.
Sicherungspläne werden in den folgenden Regionen unterstützt.
| 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 Rechenzentrumscampi befinden. Ein einzelnes, lokalisiertes physisches Katastrophenereignis könnte daher mehrere Zonen in derselben Region betreffen und das Risiko von Datenverlust im Vergleich zu Regionen mit Zonentrennung erhöhen.
Namen von Sicherungsplänen und ‑regeln
Namen von Sicherungsplänen und Regeln müssen die folgenden Anforderungen erfüllen:
- Darf nur Kleinbuchstaben, Ziffern, Bindestriche (
-), Unterstriche (_) und Punkte (.) enthalten. Leerzeichen sind nicht zulässig. - Mit einer Ziffer oder einem Buchstaben beginnen und enden
- Maximal 63 Zeichen
- Darf nicht wie eine IP-Adresse in Dezimalpunktschreibweise dargestellt werden. Beispiel:
192.0.2.255