In Kubernetes sichern und wiederherstellen

Auf dieser Seite erfahren Sie, wie Sie Ihre AlloyDB Omni-Daten mit dem AlloyDB Omni Kubernetes-Operator sichern und wiederherstellen. Dazu sind grundlegende Kenntnisse zum Aktualisieren eines Kubernetes-Clusters mit Manifestdateien und dem kubectl-Befehlszeilentool erforderlich. Weitere Informationen zur Installation und Ausführung von AlloyDB Omni in einem Kubernetes-Cluster finden Sie unter AlloyDB in Kubernetes installieren.

Wenn Sie die kontinuierliche Sicherung und Wiederherstellung in AlloyDB Omni aktivieren möchten, müssen Sie für jeden Datenbankcluster einen Sicherungsplan erstellen. Sicherungen werden gemäß den in der backupPlan-Ressource definierten Sicherungszeitplänen erstellt. Wenn im Sicherungsplan kein Sicherungszeitplan definiert ist, werden standardmäßig kontinuierliche Sicherungen durchgeführt. Sie können Sicherungen zu einem beliebigen Zeitstempel im Wiederherstellungszeitraum mit einer Genauigkeit von Sekunden wiederherstellen oder klonen.

Informationen zum Sichern und Wiederherstellen Ihrer AlloyDB Omni-Daten bei nicht-Kubernetes-Bereitstellungen finden Sie unter Barman für AlloyDB Omni einrichten und pgBackRest für AlloyDB Omni einrichten.

Sicherungen aktivieren und planen

Kontinuierliche Sicherungen werden aktiviert, wenn Sie eine Sicherungsplanressource für Ihren Datenbankcluster erstellen. Sie müssen für jeden Datenbankcluster eine backupPlan-Ressource erstellen, um eine kontinuierliche Sicherung für diesen Cluster zu aktivieren. In dieser Sicherungsplanressource werden die folgenden Parameter definiert:

• Der Speicherort, an dem der AlloyDB Omni-Betreiber Sicherungen speichert. Dies kann lokal in Ihrem Kubernetes-Cluster oder in einem Cloud Storage-Bucket erfolgen.

• Eine Option zum Festlegen mehrerer Sicherungszeitpläne, mit denen automatisch full-, incremental- und differential-Sicherungen erstellt werden. Sie können diesen Zeitplan jederzeit pausieren, auch wenn Sie den Sicherungsplan zum ersten Mal definieren. Wenn ein Sicherungsplan pausiert ist, werden keine geplanten Sicherungen erstellt. Sie können aber weiterhin manuell Sicherungen erstellen.

  Wenn keine Sicherungszeitpläne angegeben sind, gilt standardmäßig „0 0 * * *“. Das bedeutet, dass täglich um Mitternacht (lokale Zeit) eine vollständige Sicherung durchgeführt wird.

• Eine Aufbewahrungsdauer für gespeicherte Sicherungen. Die Dauer kann zwischen einem Tag und 90 Tagen liegen. Der Standardwert ist 14.

Ihr Datenbankcluster kann mehrere Sicherungspläne mit jeweils eigenem Namen und eigener Konfiguration haben. Wenn Sie mehrere backupPlan-Ressourcen mit unterschiedlichen Sicherungszeitplänen für einen Datenbankcluster erstellen, müssen Sie für jede Sicherungsressource einen eindeutigen Sicherungsort definieren.

Plan zum Speichern von Sicherungen lokal erstellen

Wenn Sie Sicherungen aktivieren möchten, die lokal gespeichert werden, wenden Sie das folgende Manifest an:

    apiVersion: alloydbomni.dbadmin.goog/v1
    kind: BackupPlan
    metadata:
      name: BACKUP_PLAN_NAME
      namespace: NAMESPACE
    spec:
      dbclusterRef: DB_CLUSTER_NAME
      backupSchedules:
        full: "FULL_CRON_SCHEDULE"
        differential: "DIFF_CRON_SCHEDULE"
        incremental: "INCR_CRON_SCHEDULE"
      backupRetainDays: RETENTION_DAYS
      paused: PAUSED_BOOLEAN

Ersetzen Sie Folgendes:

• BACKUP_PLAN_NAME: ein Name für diese Sicherungsplanressource, z. B. backup-plan-1.

• NAMESPACE: der Kubernetes-Namespace für diesen Sicherungsplan. Er muss mit dem Namespace des Datenbankclusters übereinstimmen.

• DB_CLUSTER_NAME: der Name Ihres Datenbankclusters, den Sie beim Erstellen zugewiesen haben.

• FULL_CRON_SCHEDULE: einen Sicherungszeitplan zum Erstellen einer vollständigen Sicherung, die alle Daten im cron-Format enthält. Legen Sie beispielsweise „0 0 * * 0“ fest, um jeden Sonntag um 00:00 Uhr ein vollständiges Back-up zu erstellen.

• DIFF_CRON_SCHEDULE: einen Sicherungszeitplan zum Erstellen von Sicherungen, die anfangs vollständige Sicherungen sind. Nachfolgende Sicherungen sind differenziell und basieren auf zwischenzeitlichen Änderungen an den Daten, die im cron-Format ausgedrückt werden. Legen Sie beispielsweise „0 22 * * 3“ fest, um jeden Mittwoch um 22:00 Uhr eine Differenzsicherung durchzuführen.

• INCR_CRON_SCHEDULE: Ein Sicherungszeitplan zum Erstellen von Sicherungen, die Daten enthalten, die sich seit der letzten vollständigen, differenziellen oder inkrementellen Sicherung geändert haben. Sie wird im cron-Format angegeben. Legen Sie beispielsweise „0 21 * * *“ fest, um täglich um 21:00 Uhr eine inkrementelle Sicherung zu erstellen.

• RETENTION_DAYS: Die Anzahl der Tage, für die der AlloyDB Omni-Operator diese Sicherung aufbewahrt. Muss eine Ganzzahl zwischen 1 und 90 sein. Der Standardwert ist 14.

• PAUSED_BOOLEAN: Gibt an, ob der Sicherungsplan pausiert ist. Geben Sie einen der folgenden Werte an:

  • true: Sicherungen werden pausiert und es werden keine geplanten Sicherungen erstellt.

  • false: Der AlloyDB Omni-Operator erstellt Sicherungen gemäß dem Zeitplan, der mit cronSchedule angegeben wurde. Dies ist der Standardwert, wenn er nicht explizit auf true festgelegt ist.

  Der Standardwert ist false.

Plan erstellen, mit dem Back-ups in Cloud Storage gespeichert werden

So aktivieren Sie Sicherungen, die in Cloud Storage gespeichert werden:

Hinweis: Wenn Sie Sicherungen lokal speichern möchten, planen Sie den Speicherplatz sorgfältig. Je länger die Aufbewahrungsdauer, desto mehr Speicherplatz benötigen Sie.

1. Erstellen Sie einen Cloud Storage-Bucket. Notieren Sie sich den Namen, den Sie diesem Bucket zuweisen, da Sie ihn in einem späteren Schritt benötigen.

2. Erstellen Sie ein Dienstkonto, um dem Bucket Sicherungen hinzuzufügen.

3. Weisen Sie dem Dienstkonto Identity and Access Management-Rolle storage.objectAdmin zu.

4. Erstellen Sie einen Schlüssel für das Dienstkonto. Dadurch wird der private Schlüssel in Ihre lokale Umgebung heruntergeladen.

5. Benennen Sie die heruntergeladene Schlüsseldatei in key.json um.

6. Erstellen Sie ein Kubernetes-Secret mit dem privaten Schlüssel:

   kubectl create secret generic SECRET_NAME --from-file=KEY_PATH -n NAMESPACE

   Ersetzen Sie Folgendes:

   • SECRET_NAME: der Name des Kubernetes-Secrets, das Sie erstellen, z. B. gcs-key.

   • KEY_PATH: der Pfad des lokalen Dateisystems zur Datei key.json, die Sie in den vorherigen Schritten heruntergeladen haben.

   • NAMESPACE: den Namespace des Datenbankclusters.

7. Wenden Sie das folgende Manifest an:

     apiVersion: alloydbomni.dbadmin.goog/v1
     kind: BackupPlan
     metadata:
       name: BACKUP_PLAN_NAME
       namespace: NAMESPACE
     spec:
       dbclusterRef: DB_CLUSTER_NAME
       backupSchedules:
         full: "FULL_CRON_SCHEDULE"
         differential: "DIFF_CRON_SCHEDULE"
         incremental: "INCR_CRON_SCHEDULE"
       backupRetainDays: RETENTION_DAYS
       paused: PAUSED_BOOLEAN
       backupLocation:
         type: GCS
         gcsOptions:
           bucket: BUCKET_URL
           key: BACKUP_PATH
           secretRef:
             name: SECRET_NAME
             namespace: NAMESPACE
   

   Ersetzen Sie Folgendes:

   • BACKUP_PLAN_NAME: ein Name für diese Sicherungsplanressource, z. B. backup-plan-1.

   • NAMESPACE: der Kubernetes-Namespace für diesen Sicherungsplan. Er muss mit dem Namespace des Datenbankclusters übereinstimmen.

   • DB_CLUSTER_NAME: der Name Ihres Datenbankclusters, den Sie beim Erstellen zugewiesen haben.

   • FULL_CRON_SCHEDULE: einen Sicherungszeitplan zum Erstellen einer vollständigen Sicherung, die alle Daten im cron-Format enthält. Legen Sie beispielsweise „0 0 * * 0“ fest, um jeden Sonntag um 00:00 Uhr ein vollständiges Back-up zu erstellen.

   • DIFF_CRON_SCHEDULE: einen Sicherungszeitplan zum Erstellen von Sicherungen, die anfangs vollständige Sicherungen sind. Nachfolgende Sicherungen sind differenziell und basieren auf zwischenzeitlichen Änderungen an den Daten, die im cron-Format ausgedrückt werden. Legen Sie beispielsweise „0 22 * * 3“ fest, um jeden Mittwoch um 22:00 Uhr eine Differenzsicherung durchzuführen.

   • INCR_CRON_SCHEDULE: Ein Sicherungszeitplan zum Erstellen von Sicherungen, die Daten enthalten, die sich seit der letzten vollständigen, differenziellen oder inkrementellen Sicherung geändert haben. Sie wird im cron-Format angegeben. Legen Sie beispielsweise „0 21 * * *“ fest, um täglich um 21:00 Uhr eine inkrementelle Sicherung zu erstellen.

   • RETENTION_DAYS: Die Anzahl der Tage, für die der AlloyDB Omni-Operator diese Sicherung aufbewahrt. Muss eine Ganzzahl zwischen 1 und 90 sein. Der Standardwert ist 14.

   • PAUSED_BOOLEAN: Gibt an, ob der Sicherungsplan pausiert ist. Geben Sie einen der folgenden Werte an:

     • true: Sicherungen werden pausiert und es werden keine geplanten Sicherungen erstellt.

     • false: Der AlloyDB Omni-Operator erstellt Sicherungen gemäß dem Zeitplan, der mit cronSchedule angegeben wurde. Dies ist der Standardwert, wenn er nicht explizit auf true festgelegt ist.

     Der Standardwert ist false.

   • BUCKET_URL: der Name des Cloud Storage-Buckets, den Sie in einem früheren Schritt erstellt haben. Dies ist nicht die vollständige URL zum Bucket. Fügen Sie dem Bucket-Namen kein Präfix vorangestellt mit gs:// hinzu.

   • BACKUP_PATH: Der Pfad zum Verzeichnis, in das der AlloyDB Omni-Operator Sicherungen im Cloud Storage-Bucket schreibt. Der Pfad muss absolut sein und mit / beginnen.

   • SECRET_NAME: Der Name, den Sie für das Kubernetes-Secret ausgewählt haben, das Sie in einem vorherigen Schritt erstellt haben.

Manuelle Sicherung erstellen

Sie können jederzeit eine Sicherungsressource manuell erstellen, indem Sie einen Sicherungsplan verwenden, den Sie bereits auf einen Datenbankcluster angewendet haben. Der AlloyDB Omni-Betriebsmitarbeiter wendet den Speicherort und die Aufbewahrungsdauer des ausgewählten Sicherungsplans auf die neue manuelle Sicherung an.

Wenn Sie eine Sicherung manuell erstellen möchten, wenden Sie das folgende Manifest an:

apiVersion: alloydbomni.dbadmin.goog/v1
kind: Backup
metadata:
  name: BACKUP_NAME
  namespace: NAMESPACE
spec:
  dbclusterRef: DB_CLUSTER_NAME
  backupPlanRef: BACKUP_PLAN_NAME
  manual: true
  physicalBackupSpec:
    backupType: BACKUP_TYPE

Ersetzen Sie Folgendes:

• BACKUP_NAME: ein Name für diese Sicherung, z. B. backup-1.

• NAMESPACE: der Kubernetes-Namespace dieser Wiederherstellung. Er muss mit dem Namespace des Datenbankclusters übereinstimmen.

• BACKUP_PLAN_NAME: der Name der Sicherungsplanressource, zu der diese Sicherung gehört. Er muss mit dem Namen übereinstimmen, den Sie beim Erstellen des Sicherungsplans ausgewählt haben.

• DB_CLUSTER_NAME: der Name Ihres Datenbankclusters, den Sie beim Erstellen zugewiesen haben.

• BACKUP_TYPE: Gibt die Art der manuellen Sicherung an, die Sie erstellen möchten. Wählen Sie einen der folgenden Werte aus:

  • full: Erstellt eine vollständige Sicherung mit allen Daten.

  • diff: Erstellt eine differenzielle Sicherung, die von der letzten vollständigen Sicherung abhängt. Nachfolgende Sicherungen sind differenziell und basieren auf den zwischenzeitlich an den Daten vorgenommenen Änderungen.

  • incr: Erstellt eine inkrementelle Sicherung, die von der vorherigen vollständigen oder differenziellen Sicherung abhängt, um Daten zu enthalten, die sich seit der letzten vollständigen oder differenziellen Sicherung geändert haben.

Sicherungen überwachen und auflisten

Ihre Sicherungspläne und Sicherungen sind Ressourcen in Ihrem Kubernetes-Cluster. Verwenden Sie den Befehl kubectl get, um Informationen zu ihnen aufzurufen.

Zusammenfassung eines Sicherungsplans ansehen

Führen Sie den folgenden Befehl aus, um Informationen zu den Sicherungsplänen Ihres Datenbankclusters aufzurufen:

kubectl get backupplan.alloydbomni.dbadmin.goog -n NAMESPACE

Ersetzen Sie NAMESPACE durch den Namespace des Datenbankclusters.

Die Ausgabe sollte so aussehen:

NAME               PHASE   LASTBACKUPTIME         NEXTBACKUPTIME
backup-plan-prod   Ready   2023-10-26T17:26:43Z   2023-10-27T00:00:00Z

Eine Liste der Sicherungen aufrufen

Führen Sie den folgenden Befehl aus, um eine Liste der für Ihren Datenbankcluster verfügbaren Sicherungen aufzurufen:

kubectl get backup.alloydbomni.dbadmin.goog -n NAMESPACE

Ersetzen Sie NAMESPACE durch den Namespace des Datenbankclusters.

Die Ausgabe sollte so aussehen:

NAME                              PHASE       COMPLETETIME               TYPE
backup-plan-prod-20231026172643   Succeeded   2023-10-26T17:26:53Z       full
manual-backup-1                   Succeeded   2023-10-26T18:15:27Z       full
manual-backup-2                   InProgress                             full

Jede Zeile in der Ausgabetabelle steht für eine Sicherungsressource mit den folgenden Attributen:

• Der Name der Sicherung.
• Der Status der Sicherung. Succeeded kennzeichnet eine Sicherung, die wiederhergestellt werden kann.
• Der Zeitstempel der Erstellung der Sicherung.

Aus einer Sicherung wiederherstellen

Achtung :Bei der Wiederherstellung aus einer Sicherung werden alle Daten des Datenbankclusters überschrieben.

Mit AlloyDB können Sie aus einzelnen Sicherungen wiederherstellen oder einen Cluster mit einer Sicherung zu einem bestimmten Zeitpunkt klonen.

Aus einer benannten Sicherung wiederherstellen

So stellen Sie aus einer Sicherung wieder her und ersetzen die Daten in Ihrem Datenbankcluster durch die Daten in der Sicherung:

1. Listet alle Sicherungen auf, deren Phase Succeeded ist.

   kubectl get backup.alloydbomni.dbadmin.goog -n NAMESPACE | grep Succeeded

   Ersetzen Sie NAMESPACE durch den Namespace des Datenbankclusters.

   Wenn mindestens ein geeigneter Sicherungskandidat vorhanden ist, sieht die Ausgabe in etwa so aus:

   backup-plan-prod-20231026172643   Succeeded   2023-10-26T17:26:53Z
   manual-backup-1                   Succeeded   2023-10-26T18:15:27Z
   

2. Wählen Sie eine der im vorherigen Schritt aufgeführten Sicherungen aus, aus der Sie Daten wiederherstellen möchten. Notieren Sie sich den Namen, den Sie im nächsten Schritt verwenden.

3. Wenden Sie das folgende Manifest an:

     apiVersion: alloydbomni.dbadmin.goog/v1
     kind: Restore
     metadata:
       name: RESTORE_NAME
       namespace: NAMESPACE
     spec:
       sourceDBCluster: DB_CLUSTER_NAME
       backup: BACKUP_NAME
   

   Ersetzen Sie Folgendes:

   • RESTORE_NAME: Ein Name, der für die Datenwiederherstellungsressource verwendet werden soll, die dieses Manifest erstellt, z. B. restore-1.

   • DB_CLUSTER_NAME: Der Name Ihres Datenbankclusters, den Sie beim Erstellen zugewiesen haben.

   • BACKUP_NAME: der Name der Sicherung, die Sie im vorherigen Schritt ausgewählt haben.

Cluster von einem bestimmten Zeitpunkt klonen

Mit dem AlloyDB Omni-Operator können Sie die Daten des Clusters zu einem beliebigen Zeitpunkt innerhalb eines Wiederherstellungsfensters klonen. Die Länge des Wiederherstellungszeitraums richtet sich direkt nach der Aufbewahrungsdauer.

Wenn Sie beispielsweise eine Aufbewahrungsdauer von 14 Tagen festgelegt haben, können Sie keine Daten wiederherstellen, die älter als 14 Tage sind. Sie können die Daten zu einem beliebigen Zeitpunkt innerhalb des Wiederherstellungszeitraums wiederherstellen. Der AlloyDB Omni-Betreiber behält Sicherungen und Protokolle einen Tag länger als den angegebenen Wert auf.

Hinweis: Der AlloyDB Omni-Operator unterstützt nur das Klonen von einem bestimmten Zeitpunkt innerhalb desselben Namespaces und desselben Kubernetes-Clusters. Das Klonen zwischen Namespaces wird nicht unterstützt. Informationen zum clusterübergreifenden Wiederherstellen oder Klonen finden Sie im Leitfaden zur Notfallwiederherstellung auf Grundlage von Sicherung und Wiederherstellung.

1. Behalten Sie das Wiederherstellungsfenster im Auge, um den Zeitpunkt der Wiederherstellung zu ermitteln:

   kubectl get backupplan.alloydbomni.dbadmin.goog BACKUP_NAME -n NAMESPACE -o json | jq .status.recoveryWindow
   

   Im Folgenden finden Sie ein Beispiel für eine Antwort:

   recoveryWindow:
   begin: "2024-01-31T02:54:35Z"
   

   Der Zeitstempelwert im RFC 3339-Zeitstempelformat wird in der Wiederherstellungsressource verwendet.

2. Erstellen und wenden Sie das folgende Manifest für die Wiederherstellungsressource an:

   apiVersion: alloydbomni.dbadmin.goog/v1
   kind: Restore
   metadata:
     name: RESTORE_NAME
     namespace: NAMESPACE
   spec:
     sourceDBCluster: DB_CLUSTER_NAME
     pointInTime: "DATE_AND_TIME_STAMP"
     clonedDBClusterConfig:
       dbclusterName: NEW_DB_CLUSTER_NAME
   

   Ersetzen Sie Folgendes:

   • RESTORE_NAME: Ein Name, der für die Datenwiederherstellungsressource verwendet werden soll, die dieses Manifest erstellt, z. B. restore-1.

   • DB_CLUSTER_NAME: Der Name Ihres Datenbankclusters, den Sie beim Erstellen zugewiesen haben.

   • DATE_AND_TIME_STAMP: der RFC 3339-Zeitstempel mit Minutengenauigkeit der kontinuierlichen Sicherung, von der Sie wiederherstellen möchten, z. B. 2024-03-05T15:32:10Z.

   • NEW_DB_CLUSTER_NAME: Der Name des neuen Datenbankclusters.

Wiederherstellungsstatus ansehen

1. So rufen Sie den Fortschritt der Wiederherstellung auf:

   kubectl get restore.alloydbomni.dbadmin.goog -n NAMESPACE

   Ersetzen Sie NAMESPACE durch den Namespace des Datenbankclusters.

   Wenn der Befehl kontinuierlich ausgeführt werden soll, fügen Sie das Flag -Aw hinzu.

   Die Ausgabe sollte so aussehen:

   NAME        PHASE               COMPLETETIME   RESTOREDPOINTINTIME
   restore-1   RestoreInProgress
   

   Wenn der Wert der Spalte PHASE in der Ausgabetabelle ProvisionSucceeded lautet, ist die Wiederherstellung abgeschlossen.

2. So rufen Sie den Fortschritt der Onlinestellung des wiederhergestellten oder geklonten Datenbankclusters auf:

   kubectl get dbclusters -A -n NAMESPACE

   Ersetzen Sie NAMESPACE durch den Namespace des Datenbankclusters.

   Wenn der Befehl kontinuierlich ausgeführt werden soll, fügen Sie das Flag -Aw hinzu.

   Die Ausgabe sollte so aussehen:

   NAMESPACE   NAME               PRIMARYENDPOINT   PRIMARYPHASE   DBCLUSTERPHASE
   default     db-cluster-1       10.128.0.55       Ready          DBClusterReady
   

   Wenn der Wert der Spalte DBCLUSTERPHASE in der Ausgabetabelle DBClusterReady lautet, ist der wiederhergestellte oder geklonte Datenbankcluster einsatzbereit.

Sicherung löschen

Normalerweise müssen Sie Sicherungen nicht manuell löschen. Der AlloyDB Omni-Betriebsmodus löscht automatisch Sicherungen, die älter als die Aufbewahrungsdauer sind, die Sie beim Erstellen eines Sicherungsplans angeben.

Wenn Sie eine Sicherung manuell löschen möchten, muss sie die folgenden Anforderungen erfüllen:

• Die Sicherung ist nicht die einzige Sicherung, die für den Sicherungsplan gespeichert wird. Der AlloyDB Omni-Operator erfordert, dass für jeden Sicherungsplan mindestens eine Sicherung vorhanden ist.

• Von der Sicherung hängen keine anderen Sicherungen ab. Beispiel: eine vollständige Sicherung mit abhängigen differenziellen oder inkrementellen Sicherungen oder eine inkrementelle Sicherung mit abhängigen differenziellen Sicherungen.

Führen Sie den folgenden Befehl aus, um eine Sicherung zu löschen:

kubectl delete backup.alloydbomni.dbadmin.goog/BACKUP_NAME -n NAMESPACE

Ersetzen Sie Folgendes:

• BACKUP_NAME: der Name der Sicherung, die gelöscht werden soll.

• NAMESPACE: den Namespace des Datenbankclusters.

Größe eines Sicherungslaufwerks ändern

So ändern Sie die Größe des lokalen Laufwerks, auf dem Ihre Sicherungen im Kubernetes-Cluster gespeichert werden:

1. Aktualisieren Sie das Feld resources.disks des DBCluster-Manifests so:

   spec:
     primarySpec:
       resources:
         disks:
           - name: BACKUP_DISK
             size: 10Gi
   

   Ersetzen Sie BACKUP_DISK durch den Namen des Laufwerks, auf dem Ihre Sicherungen gespeichert sind.

2. Wenden Sie das Manifest an, um das Update durchzusetzen.

   Der AlloyDB Omni-Operator wendet die aktualisierten Spezifikationen sofort auf Ihren DBCluster an.

Für die Änderung des Sicherungslaufwerks eines laufenden Datenbankclusters gelten die folgenden Einschränkungen:

• Sie können die Größe eines Laufwerks nur erhöhen, wenn die angegebene storageClass die Volumeerweiterung unterstützt.
• Sie können die Größe eines Laufwerks nicht verringern.

Sicherungsplan aktualisieren

Jeder Sicherungsplan ist eine Kubernetes-Ressource. Führen Sie einen der folgenden Schritte aus, um die Konfiguration zu aktualisieren:

• Bearbeiten Sie die Manifestdatei des Sicherungsplans und wenden Sie sie noch einmal an.

• Führen Sie den Befehl kubectl patch aus.

Wenn Sie beispielsweise einen laufenden Sicherungsplan pausieren möchten, ändern Sie das paused-Attribut des Manifests in true und wenden Sie das Manifest dann noch einmal an.

Sicherungsplan löschen

Achtung: Wenn Sie einen Sicherungsplan löschen, werden alle mit diesem Plan verknüpften Sicherungen endgültig gelöscht.

Führen Sie den folgenden Befehl aus, um einen Sicherungsplan und alle zugehörigen Sicherungsressourcen zu löschen:

kubectl delete backupplan.alloydbomni.dbadmin.goog/BACKUP_PLAN_NAME -n NAMESPACE

Ersetzen Sie Folgendes:

• BACKUP_PLAN_NAME: der Name des Sicherungsplans, der gelöscht werden soll.

• NAMESPACE: den Namespace des Datenbankclusters.

Wenn Sie einen Sicherungsplan pausieren möchten, ohne ihn zu löschen, legen Sie das paused-Attribut der Ressource des Sicherungsplans auf true fest. Bei einem pausierten Sicherungsplan werden weiterhin Sicherungen gespeichert und es ist möglich, manuelle Sicherungen zu erstellen.