In Kubernetes sichern und wiederherstellen

Wählen Sie eine Dokumentationsversion aus:

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 zum Installieren und Ausführen von AlloyDB Omni in einem Kubernetes-Cluster finden Sie unter AlloyDB Omni in Kubernetes installieren.

Wenn Sie die kontinuierliche Sicherung und Wiederherstellung von 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 täglich fortlaufende Sicherungen erstellt. Sie können Sicherungen von jedem Zeitstempel im Wiederherstellungszeitraum mit sekundengenauer Granularität wiederherstellen oder klonen.

Informationen zum Sichern und Wiederherstellen Ihrer AlloyDB Omni-Daten in 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 die kontinuierliche Sicherung für diesen Cluster zu aktivieren. Diese Sicherungsplanressource definiert die folgenden Parameter:

  • Der Speicherort, an dem der AlloyDB Omni-Operator 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 wird, werden keine geplanten Sicherungen erstellt. Sie können ihn aber weiterhin verwenden, um Sicherungen manuell zu erstellen.

    Wenn keine Sicherungszeitpläne angegeben sind, wird standardmäßig „0 0 * * *“ verwendet. Dadurch wird täglich um Mitternacht (Ortszeit) eine vollständige Sicherung erstellt.

  • Eine Aufbewahrungsdauer für gespeicherte Sicherungen. Das kann einen Tag oder bis zu 90 Tage dauern. Der Standardwert ist 14.

  • Sie können Back-ups von primären oder Standby-Kubernetes-Clustern erstellen, indem Sie für das Feld backupSourceStrategy den Wert primary oder standby angeben. Um die Leistung des primären Clusters zu steigern, können Sie Sicherungsvorgänge auslagern, indem Sie sie über einen Standby-Cluster planen.

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 Sicherungsspeicherort definieren.

Plan zum lokalen Speichern von Sicherungen 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
      backupSourceStrategy: SOURCE_STRATEGY
      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: Ein Sicherungszeitplan zum Erstellen einer vollständigen Sicherung mit allen Daten im cron-Format. Wenn Sie beispielsweise „0 0 * * 0“ festlegen, wird jeden Sonntag um 00:00 Uhr eine vollständige Sicherung erstellt.

  • DIFF_CRON_SCHEDULE: Ein Sicherungszeitplan zum Erstellen von Sicherungen, die anfangs Vollsicherungen sind. Nachfolgende Sicherungen sind differenziell und basieren auf zwischenzeitlichen Änderungen an den Daten im cron-Format. Wenn Sie beispielsweise „0 22 * * 3“ festlegen, wird jeden Mittwoch um 22:00 Uhr eine differenzielle Sicherung erstellt.

  • 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 Format cron angegeben. Wenn Sie beispielsweise „0 21 * * *“ festlegen, wird täglich um 21:00 Uhr eine inkrementelle Sicherung erstellt.

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

  • SOURCE_STRATEGY: bestimmt, ob Back-ups vom primären oder Standby-Kubernetes-Cluster erstellt werden. Der Standardwert ist primary. Sie können einen der folgenden Werte auswählen:

    • primary: Back-ups werden vom primären Kubernetes-Cluster erstellt.

    • standby: Back-ups werden vom Standby-Kubernetes-Cluster erstellt. Wenn keine Standby-Instanz verfügbar ist, wenn das Feld SOURCE_STRATEGY auf standby gesetzt ist, wird die Sicherung stattdessen vom primären Kubernetes-Cluster erstellt.

  • 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 von cronSchedule angegebenen Zeitplan. Dies ist der Standardwert, wenn er nicht explizit auf true gesetzt wird.

    Der Standardwert ist false.

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

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

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

  2. Erstellen Sie ein Dienstkonto, um dem Bucket Back-ups hinzuzufügen.

  3. Weisen Sie dem Dienstkonto die IAM-Rolle (Identity and Access Management) 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, das den privaten Schlüssel enthält:

    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 lokale Dateisystempfad zur Datei key.json, die Sie in den vorherigen Schritten heruntergeladen haben.

    • NAMESPACE: der 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
    backupSourceStrategy: SOURCE_STRATEGY
    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: Ein Sicherungszeitplan zum Erstellen einer vollständigen Sicherung mit allen Daten im cron-Format. Wenn Sie beispielsweise „0 0 * * 0“ festlegen, wird jeden Sonntag um 00:00 Uhr eine vollständige Sicherung erstellt.

    • DIFF_CRON_SCHEDULE: Ein Sicherungszeitplan zum Erstellen von Sicherungen, die anfangs Vollsicherungen sind. Nachfolgende Sicherungen sind differenziell und basieren auf zwischenzeitlichen Änderungen an den Daten im cron-Format. Wenn Sie beispielsweise „0 22 * * 3“ festlegen, wird jeden Mittwoch um 22:00 Uhr eine differenzielle Sicherung erstellt.

    • 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 Format cron angegeben. Wenn Sie beispielsweise „0 21 * * *“ festlegen, wird täglich um 21:00 Uhr eine inkrementelle Sicherung erstellt.

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

    • SOURCE_STRATEGY: bestimmt, ob Back-ups vom primären oder Standby-Kubernetes-Cluster erstellt werden. Der Standardwert ist primary. Sie können einen der folgenden Werte auswählen:

      • primary: Back-ups werden vom primären Kubernetes-Cluster erstellt.

      • standby: Back-ups werden vom Standby-Kubernetes-Cluster erstellt. Wenn keine Standby-Instanz verfügbar ist, wenn das Feld SOURCE_STRATEGY auf standby gesetzt ist, wird die Sicherung stattdessen vom primären Kubernetes-Cluster erstellt.

    • 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 von cronSchedule angegebenen Zeitplan. Dies ist der Standardwert, wenn er nicht explizit auf true gesetzt wird.

      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. Stellen Sie dem Bucket-Namen nicht gs:// voran.

    • BACKUP_PATH: Der Pfad des Verzeichnisses, in das der AlloyDB Omni-Operator Sicherungen schreibt, innerhalb des Cloud Storage-Bucket. 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 früheren Schritt erstellt haben.

Sicherungen in S3-kompatiblem Speicher erstellen

Mit dem Feld s30options können Sie Sicherungen an S3-kompatible Endpunkte senden.

Die Schritte in der folgenden Anleitung sind allgemein gehalten. Eine spezifische Anleitung für Ihren Anwendungsfall finden Sie in der Dokumentation Ihres S3-Anbieters.

So aktivieren Sie Sicherungen auf Ihrem S3-kompatiblen Speicher:

  1. Erstellen Sie einen S3-Storage-Bucket. Notieren Sie sich den Namen, den Sie diesem Bucket zuweisen, da Sie ihn in einem späteren Schritt verwenden.
  2. Um auf den S3-Speicher-Bucket zuzugreifen, erstellen Sie ein Hauptkonto, z. B. ein Dienstkonto oder einen Nutzer. Erkundigen Sie sich bei Ihrem S3-Anbieter, ob Sie dem Hauptkonto eine vordefinierte Rolle oder Richtlinie zuweisen müssen.
  3. Gewähren Sie dem Hauptkonto, das Sie im vorherigen Schritt erstellt haben, Lese-/Schreibzugriff. Mit diesem Schritt können Sie Daten in den S3-Speicher-Bucket lesen und schreiben.
  4. Erstellen Sie einen Zugriffsschlüssel für den erstellten Principal. Der Zugriffsschlüssel enthält eine Schlüssel-ID und ein Schlüssel-Secret. Bei diesem Vorgang wird der Schlüssel in Ihre lokale Umgebung heruntergeladen.

  5. Erstellen Sie ein Kubernetes-Secret, das den Schlüssel enthält:

    kubectl create secret generic SECRET_NAME --from-literal=access-key-id=KEY_ID --from-literal=access-key=KEY -n NAMESPACE

    Ersetzen Sie Folgendes:

    • SECRET_NAME: der Name des Kubernetes-Secrets, das Sie erstellen, z. B. s3-key.
    • KEY_ID: Die Schlüssel-ID Ihres Zugriffsschlüssels.
    • KEY: Das Schlüssel-Secret Ihres Zugriffsschlüssels.
    • NAMESPACE: der Bereich, in dem der Secret-Name gespeichert wird. Dieser Wert muss eindeutig sein.

  6. 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
  backupSourceStrategy: SOURCE_STRATEGY
  paused: PAUSED_BOOLEAN
  backupLocation:
    type: S3
    s3Options:
      bucket: BUCKET_NAME
      region: REGION
      endpoint: S3ENDPOINT
      key: BACKUP_PATH
      secretRef:
        namespace: NAMESPACE
        name: SECRET_NAME
      certRef:
        name: CA_BUNDLE_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. Der Namespace muss mit dem Namespace des Datenbankclusters übereinstimmen.
    • DB_CLUSTER_NAME: Der Name Ihres Datenbankclusters, den Sie beim Erstellen zugewiesen haben.
    • FULL_CRON_SCHEDULE: Ein Sicherungszeitplan zum Erstellen einer vollständigen Sicherung mit allen Daten im cron-Format. Wenn Sie beispielsweise jeden Sonntag um 00:00 Uhr eine vollständige Sicherung erstellen möchten, legen Sie FULL_CRON_SCHEDULE auf
      0 0 * * 0 fest.
    • DIFF_CRON_SCHEDULE: Ein Sicherungszeitplan zum Erstellen von Sicherungen, die anfangs vollständige Sicherungen sind. Nachfolgende Sicherungen sind differenziell und basieren auf zwischenzeitlichen Änderungen an den Daten im cron-Format. Wenn Sie beispielsweise jeden Mittwoch um 22:00 Uhr eine differenzielle Sicherung erstellen möchten, legen Sie 0 22 * * 3 fest .
    • 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. Dies wird im cron-Format ausgedrückt. Wenn Sie beispielsweise jeden Tag um 21:00 Uhr eine inkrementelle Sicherung erstellen möchten, legen Sie dies auf 0 21 * * * fest .
    • RETENTION_DAYS: Die Anzahl der Tage, für die der AlloyDB Omni Kubernetes-Operator diese Sicherung beibehält. Dieser Parameter muss eine Ganzzahl zwischen 1 und 90 sein. Der Standardwert ist 14.
    • SOURCE_STRATEGY: bestimmt, ob Back-ups vom primären oder Standby-Kubernetes-Cluster erstellt werden. Der Standardwert ist primary. Sie können einen der folgenden Werte auswählen:
      • primary: Back-ups werden vom primären Kubernetes-Cluster erstellt.
      • standby: Back-ups werden vom Standby-Kubernetes-Cluster erstellt. Wenn keine Standby-Instanz verfügbar ist, wenn das Feld SOURCE_STRATEGY auf standby gesetzt ist, wird die Sicherung stattdessen vom primären Kubernetes-Cluster erstellt.
    • 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 Standardwert. Der AlloyDB Omni-Operator erstellt Sicherungen gemäß dem Zeitplan, der von cronSchedule angegeben wird. Dies ist der Standardwert, wenn er nicht explizit auf true gesetzt wird.
    • BUCKET_NAME: Der Name des von Ihnen erstellten S3-Storage-Buckets. Der Bucket-Name ist nicht die vollständige URL zum Bucket. Stellen Sie dem Bucket-Namen nicht gs:// voran.
    • REGION: Die Region, in der der S3-Bucket gespeichert ist.
    • S3ENDPOINT: Der Endpunkt für den S3-Storage-Bucket.
    • BACKUP_PATH: der Pfad des Verzeichnisses, in das der AlloyDB Omni-Operator Backups im S3-Speicher-Bucket schreibt. Der Pfad muss absolut sein und mit / beginnen.
    • NAMESPACE: der Bereich, in dem der Secret-Name eindeutig sein muss.
    • SECRET_NAME: der Name, den Sie für das Kubernetes-Secret ausgewählt haben, das Sie erstellt haben.

    • CA_BUNDLE_SECRET_NAME: Ein Pool von PEM-codierten CA-Zertifikaten, die der S3-Server zum Validieren des Zertifikats verwendet. Achten Sie darauf, dass das Bundle im Secret unter einem Schlüssel namens ca.crt enthalten ist.

      Im folgenden Beispiel wird gezeigt, wie Sie ein Secret erstellen, das das Zertifikat enthält. Dabei ist PEM_FILE_PATH der Pfad zur ca-Bundle-Datei:

      kubectl create secret generic CERT_SECRET_NAME -n NAMESPACE --from-file=ca.crt=PEM_FILE_PATH

Manuelle Sicherung erstellen

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

Wenn Sie manuell ein Backup von einem primären oder Standby-Kubernetes-Cluster erstellen möchten, müssen Sie die Quelldatenbankinstanz für das Backup mit dem Feld backupSourceRole angeben und das folgende Manifest anwenden:

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

Ersetzen Sie Folgendes:

  • BACKUP_NAME: Ein Name für dieses Backup, 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.

  • SOURCE_ROLE: Gibt die Rolle der Quelldatenbankinstanz an, aus der die manuelle Sicherung erstellt wird. Der Standardwert ist primary. Sie können einen der folgenden Werte auswählen:

    • primary: Konfigurieren Sie die Sicherung über den primären Kubernetes-Cluster.
    • standby: Konfigurieren Sie die Sicherung über den Standby-Kubernetes-Cluster.

  • BACKUP_TYPE: Gibt den Typ 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 zwischenzeitlichen Änderungen an den Daten.

    • incr: erstellt eine inkrementelle Sicherung, die von der vorherigen vollständigen oder differenziellen Sicherung abhängt, um Daten einzuschließen, die sich seit der letzten vollständigen oder differenziellen Sicherung geändert haben.

Sicherungen überwachen und auflisten

Ihre Sicherungspläne und Sicherungen sind alle Ressourcen in Ihrem Kubernetes-Cluster. Verwenden Sie den Befehl kubectl get, um Informationen dazu 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 gibt an, dass die Sicherung wiederhergestellt werden kann.
  • Der Zeitstempel der Erstellung der Sicherung.

Aus einer Sicherung wiederherstellen

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

Aus einer benannten Sicherung wiederherstellen

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

  1. Alle Sicherungen auflisten, 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 guter 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 benötigen.

  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 durch dieses Manifest erstellt wird, 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 Clusterdaten zu einem beliebigen Zeitpunkt innerhalb eines Wiederherstellungszeitraums klonen. Die Länge des Wiederherstellungszeitraums wird direkt durch den Aufbewahrungszeitraum bestimmt.

Wenn Ihr Aufbewahrungszeitraum beispielsweise auf 14 Tage festgelegt ist, können Sie keine Daten wiederherstellen, die älter als 14 Tage sind. Sie können Daten zu einem beliebigen Zeitpunkt innerhalb des Wiederherstellungszeitraums wiederherstellen. Der AlloyDB Omni-Operator behält Sicherungen und Logs einen Tag länger als den angegebenen Wert bei.

  1. Behalten Sie das Wiederherstellungsfenster im Blick, um den Wiederherstellungspunkt 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 Sie das folgende Manifest für die Wiederherstellungsressource und wenden Sie es 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 durch dieses Manifest erstellt wird, 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 einer Granularität von einer Minute des kontinuierlichen Back-ups, aus dem Sie die Daten wiederherstellen möchten, z. B. 2024-03-05T15:32:10Z.

    • NEW_DB_CLUSTER_NAME: Der Name des neuen Datenbankclusters.

Wiederherstellungsstatus ansehen

  1. So sehen Sie den Fortschritt des Wiederherstellungsvorgangs:

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

    Ersetzen Sie NAMESPACE durch den Namespace des Datenbankclusters.

    Wenn Sie den Befehl kontinuierlich ausführen möchten, fügen Sie das Flag -Aw hinzu.

    Die Ausgabe sollte so aussehen:

    NAME        PHASE               COMPLETETIME   RESTOREDPOINTINTIME
restore-1   RestoreInProgress

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

  2. So sehen Sie den Fortschritt der Wiederherstellung oder des Klonens des Datenbankclusters:

    kubectl get dbclusters -A -n NAMESPACE

    Ersetzen Sie NAMESPACE durch den Namespace des Datenbankclusters.

    Wenn Sie den Befehl kontinuierlich ausführen möchten, 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-Operator löscht automatisch Sicherungen, die älter als der Aufbewahrungszeitraum sind, den 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 zugehörigen Sicherungsplan gespeichert ist. Für den AlloyDB Omni-Operator ist mindestens eine Sicherung pro Sicherungsplan erforderlich.

  • Die Sicherung ist nicht von anderen Sicherungen abhängig. Beispiele: Eine vollständige Sicherung mit differenziellen oder inkrementellen Sicherungen, die von ihr abhängen, oder eine inkrementelle Sicherung mit differenziellen Sicherungen, die von ihr abhängen.

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 zu löschenden Sicherung.

  • NAMESPACE: der Namespace des Datenbankclusters.

Größe eines Sicherungslaufwerks ändern

Führen Sie die folgenden Schritte aus, um die Größe der lokalen Festplatte zu ändern, auf der Ihre Backups im Kubernetes-Cluster gespeichert sind:

  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 zu erzwingen.

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

Die folgenden Einschränkungen gelten für das Ändern des Sicherungslaufwerks eines laufenden Datenbankclusters:

  • Sie können die Größe eines Laufwerks nur erhöhen, wenn die angegebene storageClass die Volumenerweiterung 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 Attribut paused des Manifests in true und wenden Sie das Manifest dann noch einmal an.

Sicherungsplan löschen

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

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: der Namespace des Datenbankclusters.

Wenn Sie einen Sicherungsplan pausieren möchten, ohne ihn zu löschen, legen Sie das Attribut paused der Ressource des Sicherungsplans auf true fest. In einem pausierten Sicherungsplan werden weiterhin Sicherungen gespeichert und manuelle Sicherungen können erstellt werden.