Informationen zu Cloud SQL-Sicherungen

Auf dieser Seite wird beschrieben, wie Sicherungen für Ihre Cloud SQL-Instanzen funktionieren und welche Sicherungsoptionen Ihnen zur Auswahl stehen. Eine Übersicht über das Wiederherstellen von Daten aus einer Sicherung in einer Instanz finden Sie unter Instanz wiederherstellen – Übersicht.

Mit Cloud SQL können Sie Ihre Instanzen bei Bedarf oder automatisch mithilfe eines Sicherungszeitplans sichern. Cloud SQL-Sicherungen sind inkrementell und helfen Ihnen, verloren gegangene Daten in Ihrer Cloud SQL-Instanz wiederherzustellen. Mit Sicherungen haben Sie folgende Möglichkeiten:

  • Stellen Sie Ihre Instanz in einem früheren Zustand wieder her, wenn ein Problem auftritt.
  • Richten Sie die Notfallwiederherstellung ein, indem Sie eine neue Instanz mit einer Sicherung in einer anderen Region oder Zone erstellen.
  • Erstellen Sie mehrere Instanzen mithilfe von Sicherungen, um die Entwicklung, das Testen und die Migration zu erleichtern.

Cloud SQL-Sicherungen werden standardmäßig auch mit von Google verwalteten oder vom Kunden verwalteten Verschlüsselungsschlüsseln (CMEK) verschlüsselt.

Sie können diese Sicherungen beibehalten, indem Sie die Einstellungen für die Beibehaltung von Sicherungen für Ihre Instanz festlegen. Die Aufbewahrungseinstellungen können je nach Cloud SQL-Version und Sicherungsoption Ihrer Instanz variieren. Außerdem können Sie Sicherungen auch nach dem Löschen Ihrer Instanz beibehalten, um die Instanz nach dem Löschen wiederherstellen zu können.

Cloud SQL bietet zwei Optionen für Sicherungsdienste zum Verwalten Ihrer Sicherungen:

  • Erweiterte Sicherungen: Sicherungen werden in einem zentralen Sicherungsverwaltungsprojekt verwaltet und gespeichert, das den Backup- und DR-Dienst nutzt und eine erzwungene Aufbewahrung, detaillierte Planung und Überwachung bietet.
  • Standardsicherungen: Sicherungen werden im selben Projekt wie Ihre Cloud SQL-Instanzen erstellt, verwaltet und gespeichert.

Weitere Informationen zu den einzelnen Sicherungsoptionen und ihren Funktionen finden Sie unter Sicherungsoptionen.

Sicherungstypen

Cloud SQL führt entweder On-Demand- oder automatische Sicherungen für Ihre Cloud SQL-Instanzen durch.

On-Demand-Sicherungen

On-Demand-Sicherungen sind Sicherungen, die jederzeit erstellt werden können. Dies ist nützlich, wenn Sie einen riskanten Vorgang in Ihrer Datenbank ausführen oder wenn Sie eine Sicherung benötigen und nicht auf den nächsten Sicherungszeitraum warten möchten. Sie können On-Demand-Sicherungen für jede Instanz erstellen, unabhängig davon, ob automatische Sicherungen für diese Instanz aktiviert sind oder nicht.

Automatische Sicherungen

Automatische Sicherungen werden in einem geplanten Rhythmus erstellt, z. B. stündlich, täglich, wöchentlich oder monatlich. Die geplante Häufigkeit hängt von der Sicherungsoption Ihrer Instanz ab. Die Sicherung beginnt innerhalb des Sicherungszeitraums. Cloud SQL empfiehlt, Sicherungen nach Möglichkeit so zu planen, dass sie durchgeführt werden, wenn Ihre Instanz weniger aktiv ist.

Wir empfehlen, keine automatischen Sicherungen manuell zu löschen, da sie für die Wiederherstellung zu einem bestimmten Zeitpunkt erforderlich sind.

Während des Sicherungszeitraums werden regelmäßig automatische Sicherungen durchgeführt, wenn Ihre Instanz ausgeführt wird. Nach dem Beenden der Instanz wird eine zusätzliche automatische Sicherung erstellt, um alle Änderungen, die vor der Beendigung der Instanz vorgenommen wurden, zu schützen. Die Aufbewahrung automatischer Sicherungen hängt von der konfigurierten Aufbewahrungsrichtlinie in der ausgewählten Sicherungsoption für Ihre Instanz ab.

Abschließende Sicherung vor dem Löschen der Instanz erstellen

Mit finalen Sicherungen können Sie eine Sicherung Ihrer Cloud SQL-Instanz erstellen, bevor Sie die Instanz löschen. Das ist nützlich, um die Instanzdaten nach dem Löschen der Instanz beizubehalten. Sie können die endgültige Sicherung später verwenden, um eine Instanz zu erstellen oder eine vorhandene Instanz wiederherzustellen. Weitere Informationen zum Aufrufen und Ansehen von Details zu Ihrer letzten Sicherung finden Sie unter Liste der letzten Sicherungen ansehen.

Standardmäßig speichert Cloud SQL die letzte Sicherung 30 Tage lang. Sie können jedoch anpassen, wie lange Cloud SQL die Sicherung aufbewahrt. Diese Zeitspanne kann zwischen 1 Tag und 365 Tagen für Standardsicherungen oder zwischen 1 Tag und 99 Jahren für erweiterte Sicherungen liegen. Sie können die Instanz dann aus der Sicherung wiederherstellen, sofern sie verfügbar ist. Abschließende Sicherungen werden ähnlich wie andere Sicherungen für die Anzahl der Tage berechnet, die sie aufbewahrt werden.

Sicherungen nach der Instanzlöschung beibehalten

Beibehaltene Sicherungen sind Sicherungen, die von Cloud SQL nach dem Löschen einer Instanz beibehalten werden. Diese Sicherungen bestehen aus On-Demand-Sicherungen und automatischen Sicherungen, die erstellt wurden, als die Instanz aktiv war. Wenn Sie eine Instanz löschen, sind diese Sicherungen unabhängig von Ihrer Instanz und werden auf Projektebene gespeichert. Aufbewahrte Sicherungen unterscheiden sich von abschließenden Sicherungen, die die letzten Sicherungen sind, die beim Löschen der Instanz erstellt werden.

Sie können die Beschreibung dieser Sicherungen aktualisieren, um sie in Ihrem Google Cloud -Projekt besser verwalten zu können. Aufbewahrte Sicherungen können jederzeit in einer neuen oder vorhandenen Cloud SQL-Instanz wiederhergestellt werden.

Der Aufbewahrungszeitraum für diese Sicherungen wird durch den Sicherungstyp definiert und kann nach dem Löschen der Instanz nicht mehr geändert werden. On-Demand-Sicherungen werden für unbegrenzte Zeit aufbewahrt, bis sie manuell gelöscht werden oder das Projekt, das die Sicherung enthält, gelöscht wird. Bei erweiterten Sicherungen werden On-Demand-Sicherungen entsprechend der ausgewählten Aufbewahrungsregel aufbewahrt. Automatisierte Sicherungen werden nach dem Löschen der Instanz fortlaufend gelöscht, eine Sicherung pro Tag. Der rollierende Zeitraum wird basierend auf den Aufbewahrungseinstellungen der Instanz vor dem Löschen definiert. Je nach ausgewählter Sicherungsoption für Ihre Instanz kann er zwischen 1 Tag und 99 Jahren liegen. Wenn die Aufbewahrungseinstellung für automatische Sicherungen Ihrer Instanz beispielsweise auf „7“ festgelegt war, wird die letzte automatische Sicherung 7 Tage nach dem Löschen der Instanz gelöscht.

Aufbewahrte Sicherungen können jederzeit manuell gelöscht werden. Wenn Sie jedoch eine aufbewahrte Sicherung löschen, können die gelöschten Sicherungen nicht wiederhergestellt werden.

Da Instanznamen nach dem Löschen einer Instanz in Cloud SQL wiederverwendet werden können, werden aufbewahrte Sicherungen in Ihrem Google Cloud -Projekt mit dem Feld instance_deletion_time gespeichert. Anhand dieses Felds können Sie ermitteln, ob eine bestimmte Sicherung zu einer aktiven oder gelöschten Instanz gehört. Sie können auch die Beschreibung einer Sicherung aktualisieren, um sie leichter verwalten zu können.

Aufbewahrung von Transaktionslogs

Die Aufbewahrungsdauer der Transaktionslogs wird in Tagen angegeben. Bei Cloud SQL Enterprise Plus-Instanzen liegt der Bereich zwischen 1 und 35 Tagen, wobei der Standardwert 14 Tage beträgt. Bei Cloud SQL Enterprise-Instanzen liegt der Bereich zwischen 1 und 7 Tagen, wobei der Standardwert 7 Tage beträgt. Sowohl bei der Cloud SQL Enterprise Plus Edition als auch bei der Cloud SQL Enterprise Edition muss die Einstellung für die Aufbewahrung des Transaktionsprotokolls geringer sein als die Einstellung für die Aufbewahrung des Back-ups.

Sicherungen für Replikate

Sicherungen sind für Replikatinstanzen nicht verfügbar. Da Replikatinstanzen Kopien von primären Instanzen sind, werden Sicherungen mit der primären Instanz verwaltet. Wenn eine Replikatinstanz aufgrund eines Failovers oder Switchovers zu einer eigenständigen Instanz hochgestuft wird, ist die Instanz für Back-ups aktiviert und erfordert eine eigene Back-up-Konfiguration. Hochgestufte Replikate übernehmen nicht die Sicherungskonfigurationen der primären Instanz und können nicht auf die Sicherungen der primären Instanz zugreifen.

Sicherungsoptionen

Cloud SQL bietet zwei Optionen für Sicherungsdienste zum Verwalten der Sicherungen Ihrer Instanz: Standard- und Erweiterte-Sicherungen. Sie können je nach den Anforderungen Ihrer Instanz zwischen den Standard- und erweiterten Sicherungsoptionen wählen. Instanzen können zwar nicht beide Sicherungsoptionen gleichzeitig verwenden, aber Cloud SQL bietet Ihnen die Möglichkeit, bei Bedarf zwischen diesen Sicherungsoptionen zu wechseln.

Die folgende Tabelle bietet einen Überblick über die Features, die bei den einzelnen Sicherungsoptionen verfügbar sind:

Features Standardsicherungen Erweiterte Sicherungen
Backup Vault -
Erzwungene Aufbewahrung mit Aufbewahrungssperre -
Sicherungen bei Projektlöschung beibehalten -
Zentrale projektübergreifende Sicherungsverwaltung -
Aufbewahrungsdauer für Sicherungen 1 Jahr Unbegrenzt
Zeitplan für automatische Sicherungen Täglich Stündlich, täglich, wöchentlich, monatlich, jährlich
Wiederherstellung zu einem bestimmten Zeitpunkt mithilfe von Logs
Regionenübergreifende Sicherung und Wiederherstellung. -
On-Demand-Sicherungen
Multiregionale Sicherungen -
Alle Sicherungen beim Löschen der Instanz beibehalten
Abschließende Sicherung beim Löschen der Instanz
CMEK-Unterstützung -

Weitere Informationen zu diesen Sicherungsoptionen finden Sie unter Standardsicherungen und Erweiterte Sicherungen.

Erweiterte Sicherungen

Mit erweiterten Sicherungen können Sie mit Backup and DR alle Sicherungen für Ihre Cloud SQL-Instanzen in verschiedenen Projekten in einem zentralen Sicherungsprojekt verwalten und speichern. Backup and DR bietet eine zentrale Verwaltung, Überwachung und Berichterstellung für tägliche Sicherungsvorgänge an einem Ort. Sicherungen werden in einem Backup Vault gespeichert. Das ist eine von Google verwaltete, sichere und isolierte Speicherressource, die von Backup und DR verwaltet wird. Die Sicherungs- und Wiederherstellungseinstellungen werden über Sicherungspläne verwaltet. So erhalten Sie unveränderliche und nicht löschbare Sicherungen, die unabhängig vom Quellprojekt sind. Weitere Informationen zur Funktionsweise von Sicherungen mit Backup und DR finden Sie unter Backup und DR – Übersicht.

Bei erweiterten Sicherungen wird mit Backup and DR ein zentrales Sicherungsprojekt erstellt, in dem Sie die Sicherungspläne und Backup Vault für Ihre Cloud SQL-Instanzen verwalten. Diese Pläne können mit mehreren Projekten verknüpft werden.

Wenn Sie einen Sicherungsplan an eine Cloud SQL-Instanz anhängen, werden die vorhandenen Sicherungs- und Wiederherstellungseinstellungen durch den Sicherungsplan überschrieben. Der Plan mit Ihren Sicherungs- und Wiederherstellungseinstellungen wird im zentralen Sicherungsprojekt gespeichert. Alle Sicherungen, die erstellt werden, wenn der Plan auf Ihrer Cloud SQL-Instanz aktiv ist, werden im Backup Vault im Sicherungsprojekt gespeichert.

Da Backup and DR in einem separaten Google Cloud Projekt verwaltet wird, sind Sicherungen geschützt, wenn ein Quell- oder Arbeitslastprojekt gelöscht wird. Rollen und Verantwortlichkeiten werden von der Backup and DR Admin verwaltet und sind von den Cloud SQL Admin-Rollen und ‑Verantwortlichkeiten getrennt.

Sie können Sicherungen nach dem Löschen der Instanz beibehalten oder vor dem Löschen eine letzte Sicherung Ihrer Instanz erstellen. Alle Sicherungen, die im Rahmen von erweiterten Sicherungen erstellt werden, können verwendet werden, um eine Instanz wiederherzustellen, während sie aktiv ist oder nachdem sie gelöscht wurde.

Sicherungsaufbewahrung

Wenn Sie erweiterte Sicherungen verwenden, können Sie Sicherungen bis zu 99 Jahre lang in einem Backup Vault aufbewahren. Für den Backup Vault gilt eine erzwungene Mindestaufbewahrungsdauer zwischen 1 Tag und 99 Jahren.

Sicherungsspeicher

Sicherungen werden an einem zentralen Ort gespeichert, der als Backup Vault bezeichnet wird. Ein Backup Vault ist ein sicherer und isolierter Speicher, der vom Backup- und DR-Dienst verwaltet wird. Mit einem Backup Vault können Sie Sicherungen zwischen 1 Tag und 99 Jahren aufbewahren. Weitere Informationen finden Sie unter Sicherungs-Vaults.

Kosten für Sicherungen

Bei erweiterten Sicherungen richten sich die Kosten für Sicherungen nach der Gesamtgröße der Sicherung, die im Backup Vault gespeichert ist. Diese Sicherungen werden auf Grundlage der Sicherungskonfiguration im zugehörigen Sicherungsplan der Instanz erstellt. Die Gesamtkosten werden von Backup and DR anhand der Preise für Backup and DR berechnet.

Beschränkungen

Bei der Verwendung von erweiterten Sicherungen gelten die folgenden Einschränkungen:

  • Der Backup-Tresor und Ihre Cloud SQL-Instanz müssen sich in derselben Region befinden.
  • Wenn Sie den verknüpften Sicherungsplan einer Instanz ändern möchten, müssen Sie die Instanz auf Standardsicherungen umstellen. Dazu löschen Sie die vorhandene Verknüpfung des Sicherungsplans und verknüpfen dann den neuen Sicherungsplan.
  • Sie können kein DR-Replikat (Disaster Recovery, Notfallwiederherstellung) für eine Instanz mit erweiterten Sicherungen erstellen.
  • Wenn Ihre Instanz ein DR-Replikat (Disaster Recovery) hat, können Sie keine erweiterten Sicherungen für die Instanz aktivieren.
  • Sie können einer Replikatinstanz keinen Sicherungsplan zuordnen.
  • Wenn für Ihre Instanz erweiterte Sicherungen verwendet werden, können Sie die Instanz nicht zu einem Replikat herabstufen.

Standardsicherungen

Standardsicherungen sind Sicherungen, die von Cloud SQL mit Ihrer Cloud SQL-Instanz verwaltet werden. Cloud SQL-Sicherungen sind inkrementell und enthalten nur Daten, die sich nach der letzten Sicherung geändert haben. Standardmäßig speichert Cloud SQL sieben automatische Sicherungen für jede Cloud SQL Enterprise-Instanz und 15 automatische Sicherungen für jede Cloud SQL Enterprise Plus-Instanz zusätzlich zu On-Demand-Sicherungen. Sie können konfigurieren, wie viele automatische Sicherungen beibehalten werden sollen (von 1 bis 365).

Wenn Sie eine Instanz löschen, können Sie alle Sicherungen beibehalten und eine abschließende Sicherung Ihrer Daten erstellen. So können Sie alle gelöschten Instanzen wiederherstellen. Wenn Sie jedoch keine Sicherungen beibehalten oder vor dem Löschen Ihrer Instanz keine abschließende Sicherung erstellen, werden alle Instanzsicherungen automatisch von Cloud SQL gelöscht.

Sicherungsaufbewahrung

Bedarfsorientierte Sicherungen werden nicht automatisch gelöscht. Sie bleiben erhalten, bis Sie sie manuell löschen oder bis die Instanz gelöscht wird. Da On-Demand-Sicherungen nicht automatisch gelöscht werden, können sie langfristig Auswirkungen auf Ihre Abrechnungsgebühren haben.

Automatische Sicherungen können zwischen 1 und 365 Tagen aufbewahrt werden, indem Sie die Aufbewahrungsdauer in den Sicherungseinstellungen Ihrer Instanz konfigurieren. Während Transaktionslogs in Tagen gezählt werden, ist nicht garantiert, dass die automatischen Sicherungen innerhalb eines Tages erfolgen.

Wenn Sie die Aufbewahrung von Sicherungen nach dem Löschen der Instanz für Ihre On-Demand- und automatischen Sicherungen aktivieren, gelten für diese Sicherungen dieselben Aufbewahrungseinstellungen: 1 bis 365 Tage für automatische Sicherungen und unbegrenzt für On-Demand-Sicherungen. Weitere Informationen finden Sie unter Sicherungen nach der Instanzlöschung beibehalten.

Die Logs werden einmal täglich, nicht kontinuierlich gelöscht. Wenn die Anzahl der Tage für die Logaufbewahrung mit der Anzahl der Sicherungen identisch ist, kann dies eine unzureichende Logaufbewahrung zur Folge haben. Wenn Sie beispielsweise die Logaufbewahrung auf 7 Tage und die Sicherungsaufbewahrung auf sieben Sicherungen festlegen, werden Logs von sechs bis sieben Tagen aufbewahrt.

Wir empfehlen, die Anzahl der Sicherungen mindestens auf eine mehr als die Anzahl von Tagen der Logaufbewahrung festzulegen, um eine Mindestanzahl von festgelegten Tagen für die Logaufbewahrung sicherzustellen.

Weitere Informationen zum Aktivieren von aufbewahrten Sicherungen für Ihre neuen oder vorhandenen Instanzen finden Sie unter Aufbewahrte Sicherungen verwalten. Weitere Informationen zum Wiederherstellen einer Instanz aus einer aufbewahrten Sicherung finden Sie unter Aus einer aufbewahrten Sicherung wiederherstellen.

Sicherungsspeicher

In einer Konfiguration für eine Region werden Sicherungen in den verschiedenen Zonen innerhalb der Region repliziert. Bei einer Konfiguration mit mehreren Regionen wird empfohlen, Sicherungen in derselben Region wie die Instanz zu erstellen, um die Latenz zu minimieren und potenzielle Sicherungsfehler aufgrund von Organisationsrichtlinien oder standortbezogenen Einschränkungen zu vermeiden.

Sicherungen werden für Instanzen in Hochverfügbarkeits- (HA) und Nicht-HA-Konfigurationen am selben Ort gespeichert. In HA-Konfigurationen können Sie im Falle eines Failovers oder Switchovers zur sekundären Instanz weiterhin auf die Sicherungen Ihrer Instanz zugreifen.

So können Sie Ihre Sicherungsspeicherorte definieren:

Standardspeicherorte für Sicherungen

Wenn Sie keinen Speicherort angeben, werden die Sicherungen an einem multiregionalen Standort gespeichert, der geografisch dem Standort Ihrer Cloud SQL-Instanz am nächsten ist. Beispiel: Wenn sich Ihre Cloud SQL-Instanz in us-central1 befindet, werden die Sicherungen standardmäßig am multiregionalen Speicherort us gespeichert. Ein Standardspeicherort wie australia-southeast1 liegt jedoch außerhalb eines multiregionalen Bereichs. Der nächstgelegene multiregionale Standort ist asia.

Benutzerdefinierte Speicherorte für Sicherungen

Mit Cloud SQL können Sie einen benutzerdefinierten Speicherort für Ihre Sicherungsdaten auswählen. Dies ist hilfreich, wenn Ihre Organisation Vorschriften zur Datenaufbewahrung einhalten muss, die Sie dazu verpflichten, Ihre Sicherungen innerhalb eines bestimmten geografischen Gebiets aufzubewahren. Wenn für Ihre Organisation diese Art von Anforderung besteht, wird wahrscheinlich eine Organisationsrichtlinie zur Beschränkung von Ressourcenstandorten verwendet. Sollten Sie in diesem Fall versuchen, einen geografischen Standort zu nutzen, der nicht der Richtlinie entspricht, wird auf der Seite Sicherungen eine entsprechende Warnung angezeigt. Bei einer solchen Warnung müssen Sie den Speicherort der Sicherung in einen gemäß der Richtlinie zulässigen Speicherort ändern.

Beachten Sie Folgendes, wenn Sie einen benutzerdefinierten Speicherort für eine Sicherung auswählen:

  • Kosten: Ein Cluster in Ihrer Instanz befindet sich möglicherweise in einer kostengünstigeren Region als die anderen.
  • Nähe zum Anwendungsserver: Sie sollten die Sicherung möglichst in der Nähe Ihrer Bereitstellungsanwendung speichern.
  • Speicherauslastung: Sie benötigen genügend Speicherplatz zur Sicherung Ihrer Daten, da diese immer umfangreicher werden. Je nach Arbeitslast können Cluster mit verschiedenen Größen oder mit unterschiedlicher Laufwerknutzung vorhanden sein. Dies kann den Cluster beeinflussen, den Sie auswählen.

Eine vollständige Liste der gültigen regionalen Werte finden Sie unter Instanzstandorte. Eine vollständige Liste multiregionaler Werte finden Sie unter Multi-regional locations.

Weitere Informationen zum Festlegen von Speicherorten für Sicherungen und zum Anzeigen der Speicherorte von Sicherungen für eine Instanz finden Sie unter Benutzerdefinierten Speicherort für Sicherungen festlegen und Sicherungsorte anzeigen.

Einschränkungen der Sicherungsrate

Cloud SQL begrenzt die Rate der Sicherungsvorgänge auf dem Datenlaufwerk. Es sind maximal fünf Sicherungsvorgänge pro 50 Minuten pro Instanz und Projekt zulässig. Wenn ein Sicherungsvorgang fehlschlägt, wird er nicht auf dieses Kontingent angerechnet. Wenn Sie das Limit erreichen, schlägt der Vorgang mit einer Fehlermeldung fehl, die Sie darüber informiert, wann Sie es noch einmal versuchen können.

Sehen wir uns an, wie Cloud SQL die Ratenbegrenzung für Sicherungen ausführt.

Cloud SQL verwendet Tokens aus einem Bucket, um zu ermitteln, wie viele Sicherungsvorgänge gleichzeitig verfügbar sind. Jede Instanz hat einen Bucket. Der Bucket kann maximal fünf Tokens für Sicherungsvorgänge verwenden. Alle 10 Minuten wird dem Bucket ein neues Token hinzugefügt. Wenn der Bucket voll ist, läuft das Token über.

Jedes Mal, wenn Sie einen Sicherungsvorgang ausführen, wird ein Token aus dem Bucket gewährt. Wenn der Vorgang erfolgreich ist, wird das Token aus dem Bucket entfernt. Wenn der Vorgang fehlschlägt, wird das Token an den Bucket zurückgegeben. Dies wird im folgenden Diagramm veranschaulicht:

Funktionsweise von Tokens

Sicherungen im Vergleich zu Exporten

Sicherungen werden von Cloud SQL gemäß Aufbewahrungsrichtlinien verwaltet und getrennt von der Cloud SQL-Instanz gespeichert. Cloud SQL-Sicherungen unterscheiden sich von einem Export, der in Cloud Storage hochgeladen wird, wo Sie den Lebenszyklus verwalten. Sicherungen umfassen das gesamte Laufwerk der Instanz. Für Exporte können Sie bestimmte Inhalte auswählen.

Sicherungs- und Wiederherstellungsvorgänge können nicht verwendet werden, um eine Datenbank auf eine neuere Version zu aktualisieren. Sie können Daten aus einer Sicherung nur in einer Instanz mit derselben Datenbankversion wiederherstellen, die zum Zeitpunkt der Sicherung verwendet wurde.

Zum Aktualisieren auf eine neuere Version sollten Sie den Database Migration Service verwenden oder Ihre Datenbank in eine neue Cloud SQL-Instanz exportieren und dann importieren.

Kosten für Sicherungen

Standardmäßig speichert Cloud SQL sieben automatische Sicherungen für jede Cloud SQL Enterprise-Instanz und 15 automatische Sicherungen für jede Cloud SQL Enterprise Plus-Instanz zusätzlich zu On-Demand-Sicherungen. Sie können konfigurieren, wie viele automatisierte Sicherungen beibehalten werden sollen (von 1 bis 365). Der Sicherungsspeicher kostet weniger als andere Instanztypen.

Weitere Informationen zu Preisen für Back-ups finden Sie auf der Preisseite.

Sicherungsgröße

Alle Cloud SQL-Sicherungen mit Ausnahme der ersten sind inkrementell. Sie enthalten nur Daten, die sich nach der letzten Sicherung geändert haben. Die älteste Sicherung hat eine ähnliche Größe wie die Datenbank, aber die Größe der nachfolgenden Sicherungen hängt von der Änderungsrate Ihrer Daten ab. Wird die älteste Sicherung gelöscht, wird die nächstältere Sicherung erweitert, sodass sie eine vollständige Sicherung darstellt. Außerdem wird sie angepasst, um die Differenz zwischen den Sicherungen zu erfassen. Jede nachfolgende inkrementelle Sicherung wird ebenfalls aktualisiert, um der neuen vollständigen Sicherung zu entsprechen.

Sie können die Größe einer einzelnen Sicherung prüfen. Die Sicherungsgröße stellt die abrechenbare Größe für jede Sicherung dar.

Fehlerbehebung

Problem Fehlerbehebung
Der Status des aktuellen Vorgangs wird nicht angezeigt. Die Google Cloud Console meldet erfolgreiche oder fehlgeschlagene Vorgänge nur, wenn diese abgeschlossen sind. Es werden keine Warnungen oder andere Updates angezeigt.

Führen Sie den Befehl gcloud sql operations list aus, um alle Vorgänge für die angegebene Cloud SQL-Instanz aufzulisten.

Sie möchten wissen, wer einen On-Demand-Sicherungsvorgang ausgelöst hat. Auf der Benutzeroberfläche wird nicht der Nutzer angezeigt, der einen Vorgang gestartet hat.

Suchen Sie in den Logs und filtern Sie nach Text, um den Nutzer zu finden. Möglicherweise müssen Sie Audit-Logs für private Informationen verwenden. Zu den relevanten Logdateien gehören:

  • cloudsql.googleapis.com/postgres.log
  • Wenn Cloud-Audit-Logs aktiviert ist und Sie die erforderlichen Berechtigungen zum Aufrufen von Logs haben, ist möglicherweise auch cloudaudit.googleapis.com/activity verfügbar.
Nach dem Löschen einer Instanz können Sie keine Sicherung mehr vornehmen.

Wenn Sie eine Instanz löschen, ohne eine abschließende Sicherung der Daten zu erstellen, ist keine Datenwiederherstellung möglich. Wenn Sie die Instanz jedoch wiederherstellen, werden auch die Sicherungen von Cloud SQL wiederhergestellt. Weitere Informationen zum Wiederherstellen einer gelöschten Instanz finden Sie unter Wiederherstellungssicherungen.

Wenn Sie einen Exportvorgang durchgeführt haben, können Sie eine neue Instanz erstellen und dann mit einem Importvorgang die Datenbank neu erstellen. Exporte werden in Cloud Storage geschrieben und Importe werden von dort gelesen.

Eine automatische Sicherung bleibt viele Stunden hängen und kann nicht abgebrochen werden. Sicherungen können je nach Datenbankgröße sehr lange dauern.

Wenn Sie den Vorgang wirklich abbrechen müssen, können Sie den Kundensupport bitten, einen Neustart der Instanz zu erzwingen (force restart).

Ein Wiederherstellungsvorgang kann fehlschlagen, wenn ein oder mehrere Nutzer, auf die in der SQL-Dumpdatei verwiesen wird, nicht vorhanden sind. Vor dem Wiederherstellen eines SQL-Dumps müssen alle Datenbanknutzer, die Inhaber von Objekten in der Dumpdatenbank sind oder Berechtigungen dafür haben, in der Zieldatenbank vorhanden sein. Andernfalls kann der Wiederherstellungsvorgang die Objekte nicht mit den ursprünglichen Eigentumsrechten oder Berechtigungen neu erstellen.

Erstellen Sie die Datenbanknutzer, bevor Sie den SQL-Dump wiederherstellen.

Sie möchten die Anzahl der Tage für die Aufbewahrung automatischer Sicherungen von sieben auf 30 Tage oder länger erhöhen. Sie können die Anzahl der beizubehaltenden automatisierten Sicherungen auf 1 bis 365 festlegen. Automatische Sicherungen werden basierend auf dem konfigurierten Aufbewahrungswert regelmäßig entfernt. Leider bedeutet dies, dass die jeweils aktuell sichtbaren Sicherungen die einzigen automatischen Sicherungen sind, aus denen Sie wiederherstellen können.

Wenn Sie Sicherungen unbegrenzt aufbewahren möchten, können Sie eine On-Demand-Sicherung erstellen, da diese nicht auf dieselbe Weise wie automatische Sicherungen gelöscht wird. On-Demand-Sicherungen werden für unbegrenzte Zeit aufbewahrt. Das heißt, sie bleiben so lange erhalten, bis sie gelöscht werden, oder bis die Instanz gelöscht wird, zu der sie gehören. Da diese Art der Sicherung nicht automatisch gelöscht wird, kann sich dies auf die Abrechnung auswirken.

Eine automatische Sicherung ist fehlgeschlagen und Sie haben keine E-Mail-Benachrichtigung erhalten. Wenn Sie von Cloud SQL über den Status der Sicherung benachrichtigt werden möchten, konfigurieren Sie eine logbasierte Benachrichtigung.
Eine Instanz löst wiederholt einen Fehler aus, weil der Status zwischen "Fehler" und "Sicherung wiederherstellen" wechselt. Versuche, nach der Wiederherstellung eine Verbindung zur Datenbank herzustellen und diese zu verwenden, schlagen fehl.
  • Möglicherweise sind zu viele offene Verbindungen vorhanden. Zu viele Verbindungen können durch Fehler verursacht werden, die bei einer Verbindung auftreten, wenn keine autovacuum-Einstellungen zum Bereinigen inaktiver Verbindungen vorhanden sind.
  • Ein Wechsel kann auftreten, wenn benutzerdefinierter Code Wiederholungslogik verwendet, die nach einigen Fehlern nicht beendet wird.
  • Möglicherweise ist zu viel Traffic vorhanden. Verwenden Sie Verbindungs-Pooling und andere Best Practices für Verbindungen.

Versuchen Sie Folgendes:

  1. Prüfen Sie, ob die Datenbank für autovacuum eingerichtet ist.
  2. Prüfen Sie, ob im benutzerdefinierten Code eine Verbindungswiederholungslogik eingerichtet ist.
  3. Reduzieren Sie den Traffic, bis die Datenbank wiederhergestellt ist, und erhöhen Sie ihn dann langsam wieder.
Sie stellen fest, dass Daten fehlen, wenn Sie einen Sicherungs-/Wiederherstellungsvorgang durchführen. Tabellen wurden als nicht geloggt erstellt. Beispiel:

CREATE UNLOGGED TABLE ....

Diese Tabellen sind nicht in einer Wiederherstellung aus einer Sicherung enthalten:

  • Die Inhalte nicht geloggter Tabellen haben bei einer HA-Instanz keinen Failover.
  • Nicht geloggte Tabellen überstehen keine Postgres-Abstürze.
  • Nicht geloggte Tabellen werden nicht in Lesereplikate repliziert.
  • Nicht geloggte Tabellen werden während der Sicherungswiederherstellung automatisch gelöscht.

Die Lösung besteht darin, keine nicht geloggten Tabellen zu verwenden, wenn Sie diese Tabellen über eine Sicherung wiederherstellen möchten. Bei der Wiederherstellung aus einer Datenbank, die bereits nicht geloggte Tabellen enthält, können Sie die Datenbank in einer Datei speichern und die Daten aktualisieren, nachdem Sie die Dumpdatei in ALTER TABLE bis SET LOGGED in diesen Tabellen geändert haben.

Nächste Schritte