Sicherungen – Übersicht

Auf dieser Seite wird gezeigt, wie Sicherungen Ihrer Cloud SQL-Instanz funktionieren.

Eine Schritt-für-Schritt-Anleitung zur Planung von Sicherungen und zur Erstellung von On-Demand-Sicherungen finden Sie unter On-Demand- und automatische Sicherungen erstellen und verwalten.

Eine Übersicht über das Wiederherstellen von Daten aus einer Sicherung in einer Instanz finden Sie unter Instanz wiederherstellen – Übersicht.

Das bieten Sicherungen

Mit Sicherungen können Sie verloren gegangene Daten in Ihrer Cloud SQL-Instanz wiederherstellen. Wenn eine Instanz ein Problem hat, können Sie sie außerdem in einem vorherigen Zustand wiederherstellen. Dazu verwenden Sie die Sicherung, um sie zu überschreiben. Aktivieren Sie für jede Instanz, die wichtige Daten enthält, automatische Sicherungen. Durch Sicherungen werden Ihre Daten vor Verlust oder Schäden geschützt.

Das Aktivieren automatischer Sicherungen in Verbindung mit dem Transaktions-Logging ist auch für manche Vorgänge wie das Erstellen von Klonen und Replikaten erforderlich.

Was Sicherungen kosten

Standardmäßig speichert Cloud SQL für jede Instanz sieben automatische Sicherungen zusätzlich zu allen On-Demand-Sicherungen. Sie können festlegen, wie viele automatische Sicherungen beibehalten werden sollen. Der Sicherungsspeicher kostet weniger als andere Instanztypen. Weitere Informationen finden Sie auf der Seite „Preise“.

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 betreffen die gesamte Datenbank. 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.

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.

Größe von Sicherungen

Cloud SQL-Sicherungen 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. Sobald die älteste Sicherung gelöscht wurde, wird die nächstältere Sicherung vergrößert, damit immer eine vollständige Sicherung vorhanden ist.

Sicherungstypen

In Cloud SQL gibt es zwei Sicherungstypen:

On-Demand-Sicherungen

Sie können jederzeit eine Sicherung erstellen. Dies kann nützlich für Sie sein, 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 bedarfsorientierte Sicherungen für jede Instanz erstellen, unabhängig davon, ob automatische Sicherungen für diese Instanz aktiviert sind oder nicht.

Bedarfsorientierte Sicherungen werden nicht wie automatische Sicherungen automatisch gelöscht. Sie bleiben erhalten, bis sie oder ihre Instanz gelöscht werden. Da sie nicht automatisch gelöscht werden, können On-Demand-Sicherungen langfristig Auswirkungen auf Ihre Abrechnungsgebühren haben.

Automatische Sicherungen

Für automatische Sicherungen gilt ein Sicherungszeitfenster von vier Stunden. Die Sicherungen werden während dieses Zeitraums gestartet. Planen Sie Sicherungen nach Möglichkeit so, dass sie durchgeführt werden, wenn Ihre Instanz die geringste Aktivität hat.

Während des Sicherungszeitraums finden jeden Tag automatische Sicherungen statt, 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. Standardmäßig werden bis zu sieben der letzten Sicherungen aufbewahrt. Automatische Sicherungen werden angehalten, wenn Ihre Instanz länger als 36 Stunden unterbrochen ist. Sie können konfigurieren, wie viele automatisierte Sicherungen beibehalten werden sollen, von 1 bis 365. Werte für die Aufbewahrung von Sicherungs- und Transaktionslogs können gegenüber der Standardeinstellung geändert werden. Weitere Informationen

Speicherort von Sicherungen

Für Sicherungen sind die folgenden Speicherorte verfügbar:

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.

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 finden Sie unter Benutzerdefinierten Speicherort für Sicherungen festlegen und Speicherorte für Sicherungen aufrufen.

Aufbewahrung von automatischen Sicherungs- und Transaktionslogs

Mit automatischen Sicherungen können Sie Cloud SQL-Instanzen wiederherstellen. Für die Wiederherstellung zu einer bestimmten Zeit wird eine Kombination aus automatischen Sicherungen und Transaktionslogs genutzt.

Automatische Sicherungen können bis zu ein Jahr lang aufbewahrt werden, indem die Aufbewahrungsdauer konfiguriert wird, während On-Demand-Sicherungen so lange aufbewahrt werden, bis Sie die Sicherungen oder Ihre Instanz löschen.

Während Transaktionslogs in Tagen gezählt werden, ist nicht garantiert, dass die automatischen Sicherungen an einer Tagesgrenze erfolgen. Für diese Aufbewahrungseinstellungen werden unterschiedliche Einheiten verwendet. Die automatische Sicherung ist optional und kann zwischen 1 und 365 Sicherungen festgelegt werden. Die Aufbewahrung der Transaktionslogs erfolgt in Tagen und kann zwischen einem und sieben betragen. Der Standardwert für beide ist 7.

Die unteren Grenzen sind für Testinstanzen nützlich, da dann Logs und Sicherungen schneller gelöscht werden. Bei Transaktionslogs wächst die Laufwerkgröße nicht so stark bei niedrigeren Grenzen. Bei höheren Werten für die automatische Sicherungsaufbewahrung ist die Wiederherstellung von einem weiter zurückliegenden Punkt möglich.

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.

Eine hohe Schreibaktivität in die Datenbank kann eine große Anzahl von Transaktionslogs erzeugen, die sehr viel Speicherplatz belegen können und zu einem Laufwerkwachstum für Instanzen führen, bei denen die automatische Speichererweiterung aktiviert ist. Wir empfehlen, bei der Bemessung des Instanzspeichers die Aufbewahrung von Transaktionslogs zu berücksichtigen.

Siehe Automatische Sicherungsaufbewahrung einrichten.

Siehe Aufbewahrung von Transaktionslogs festlegen.

Kann ich eine Sicherung exportieren?

Nein, Sie können Sicherungen nicht exportieren. Sie können nur Instanzdaten exportieren. Weitere Informationen finden Sie unter Daten aus Cloud SQL exportieren.

Spezielles Nutzerkonto für Sicherungen

Cloud SQL erstellt für jede Instanz den speziellen Datenbanknutzer cloudsqladmin mit einem eindeutigen, instanzspezifischen Passwort. Für automatische Sicherungen meldet sich Cloud SQL als Nutzer cloudsqladmin an.

Auswirkungen von Sicherungen auf Instanzvorgänge

Schreibvorgänge und andere Vorgänge werden durch Sicherungsvorgänge nicht beeinträchtigt.

Nicht geloggte Tabellen

Nicht geloggte Tabellen werden während der Sicherungswiederherstellung automatisch gelöscht.

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. Der Kulanzzeitraum für eine Cloud SQL-Instanzbereinigung beträgt vier Tage, mit Ausnahme von Lesereplikaten, die sofort gelöscht werden. Während dieser Zeit kann der Kundensupport die Instanz neu erstellen. Nachdem die Instanzen dauerhaft gelöscht wurden, ist keine Datenwiederherstellung mehr möglich.

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. Es werden nur sieben Sicherungen aufbewahrt. Sicherungen werden aufgrund ihrer Größe und der Aufbewahrungskosten regelmäßig gelöscht. 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 Sicherung ist fehlgeschlagen und die Meldung Unknown error wird angezeigt. Beim Sicherungsvorgang ist möglicherweise eine Zeitüberschreitung aufgetreten.

Es gibt zwei Flags, die sich auf die Erstellung der Sicherung auswirken: checkpoint_timeout und checkpoint_completion_target. Zu Beginn der Sicherung wird der Prüfpunkt slow ausgeführt, der checkpoint_completion_target mit checkpoint_timeout multipliziert.

z. B. 900 sec * 0.9 sec = 810 sec = 13.5 min.

Aus diesem Grund tritt eine Zeitüberschreitung auf. Wenn Sie den Wert von checkpoint_completion_target verringern, wird das Problem in diesem Fall behoben.

Eine automatische Sicherung ist fehlgeschlagen und Sie haben keine E-Mail-Benachrichtigung erhalten. Benachrichtigungen werden bei Sicherungsfehlern nicht unterstützt.

Wenn eine automatische Sicherung fehlschlägt, wird auf der Seite Details der Cloud SQL-Instanz die Meldung Operation error angezeigt.

Sie können den Status einer Sicherung mit den Befehlen REST API oder gcloud ermitteln. Listen Sie beispielsweise zuerst die Sicherungen für eine Instanz auf und beschreiben Sie dann eine bestimmte Sicherung anhand ihrer ID:


gcloud sql backups list \
--project=PROJECT_ID \
--instance=INSTANCE_ID
   

gcloud sql backups describe BACKUP-ID \
--instance=INSTANCE_ID
    
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