Skip to main content
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Stellen Sie Applikationen mit Trident Protect wieder her

Beitragende netapp-aruldeepa

Sie können Trident Protect verwenden, um Ihre Anwendung aus einem Snapshot oder einem Backup wiederherzustellen. Das Wiederherstellen aus einem vorhandenen Snapshot erfolgt schneller, wenn die Anwendung auf dasselbe Cluster wiederhergestellt wird.

Hinweis Wenn Sie eine Anwendung wiederherstellen, werden alle für die Anwendung konfigurierten Ausführungshaken mit der App wiederhergestellt. Wenn ein Hook für die Ausführung nach der Wiederherstellung vorhanden ist, wird er automatisch als Teil des Wiederherstellungsvorgangs ausgeführt.

Namespace-Annotationen und -Labels bei Restore- und Failover-Vorgängen

Während von Restore- und Failover-Vorgängen werden Labels und Annotationen im Ziel-Namespace so angefertigt, dass sie den Labels und Annotationen im Quell-Namespace entsprechen. Beschriftungen oder Anmerkungen aus dem Quell-Namespace, die nicht im Ziel-Namespace vorhanden sind, werden hinzugefügt. Alle bereits vorhandenen Beschriftungen oder Anmerkungen werden überschrieben, um dem Wert aus dem Quell-Namespace zu entsprechen. Beschriftungen oder Anmerkungen, die nur im Ziel-Namespace vorhanden sind, bleiben unverändert.

Hinweis Wenn Sie Red hat OpenShift verwenden, ist es wichtig, die wichtige Rolle von Namespace-Annotationen in OpenShift-Umgebungen zu beachten. Namespace-Anmerkungen stellen sicher, dass wiederhergestellte Pods den durch OpenShift Security Context Constraints (SCCs) definierten Berechtigungen und Sicherheitskonfigurationen entsprechen und ohne Berechtigungsprobleme auf Volumes zugreifen können. Weitere Informationen finden Sie im "Dokumentation zu den Einschränkungen für den Sicherheitskontext von OpenShift".

Sie können verhindern, dass bestimmte Annotationen im Ziel-Namespace überschrieben werden, indem Sie die Kubernetes-Umgebungsvariable vor der Wiederherstellung oder dem Failover einstellen RESTORE_SKIP_NAMESPACE_ANNOTATIONS. Beispiel:

kubectl set env -n trident-protect deploy/trident-protect-controller-manager RESTORE_SKIP_NAMESPACE_ANNOTATIONS=<annotation_key_to_skip_1>,<annotation_key_to_skip_2>

Wenn Sie die Quellanwendung mit Helm mit dem Flag installiert haben, wird der Label-Schlüssel mit --create-namespace einer speziellen Bestrahlung name versehen. Während des Wiederherstellungs- oder Failover-Prozesses kopiert Trident Protect dieses Label in den Ziel-Namespace, aktualisiert jedoch den Wert auf den Ziel-Namespace-Wert, wenn der Wert von Quell-Namespace mit dem Quell-Namespace übereinstimmt. Wenn dieser Wert nicht mit dem Quell-Namespace übereinstimmt, wird er ohne Änderungen in den Ziel-Namespace kopiert.

Beispiel

Im folgenden Beispiel wird ein Quell- und Ziel-Namespace präsentiert, der jeweils unterschiedliche Annotationen und Labels enthält. Sie können den Status des Ziel-Namespace vor und nach dem Vorgang anzeigen und sehen, wie die Annotationen und Labels im Ziel-Namespace kombiniert oder überschrieben werden.

Vor der Wiederherstellung oder dem Failover

Die folgende Tabelle zeigt den Status der Beispiel-Namespaces für Quelle und Ziel vor dem Restore- oder Failover-Vorgang:

Namespace Anmerkungen Etiketten

Namespace ns-1 (Quelle)

  • Annotation.one/key: „Aktualisiertwert“

  • Anmerkung.zwei/Taste: "Wahr"

  • Umgebung = Produktion

  • Compliance=hipaa

  • Name=ns-1

Namespace ns-2 (Ziel)

  • Anmerkung.One/key: „True“

  • Anmerkung.drei/Taste: "False"

  • Rolle=Datenbank

Nach dem Wiederherstellungsvorgang

In der folgenden Tabelle wird der Status des Beispiel-Ziel-Namespace nach der Wiederherstellung oder dem Failover-Vorgang dargestellt. Einige Schlüssel wurden hinzugefügt, einige wurden überschrieben und das Label wurde aktualisiert, name um dem Ziel-Namespace zu entsprechen:

Namespace Anmerkungen Etiketten

Namespace ns-2 (Ziel)

  • Annotation.one/key: „Aktualisiertwert“

  • Anmerkung.zwei/Taste: "Wahr"

  • Anmerkung.drei/Taste: "False"

  • Name=ns-2

  • Compliance=hipaa

  • Umgebung = Produktion

  • Rolle=Datenbank

Wiederherstellung aus einem Backup in einem anderen Namespace

Wenn Sie ein Backup mit einem Backup Restore CR in einem anderen Namespace wiederherstellen, stellt Trident Protect die Anwendung in einem neuen Namespace wieder her und erstellt eine Anwendungs-CR für die wiederhergestellte Anwendung. Erstellen Sie zum Schutz der wiederhergestellten Applikation On-Demand-Backups oder Snapshots oder erstellen Sie einen Sicherungszeitplan.

Hinweis Wenn Sie ein Backup in einem anderen Namespace mit vorhandenen Ressourcen wiederherstellen, werden keine Ressourcen verändert, die Namen mit denen im Backup teilen. Um alle Ressourcen im Backup wiederherzustellen, löschen Sie entweder den Ziel-Namespace und erstellen Sie ihn neu, oder stellen Sie das Backup in einem neuen Namespace wieder her.
Bevor Sie beginnen

Vergewissern Sie sich, dass der Ablauf des AWS-Sitzungstokens für alle langwierigen s3-Wiederherstellungsvorgänge ausreichend ist. Wenn das Token während des Wiederherstellungsvorgangs abläuft, kann der Vorgang fehlschlagen.

Hinweis Wenn Sie Backups mit Kopia als Data Mover wiederherstellen, können Sie optional Anmerkungen im CR-System angeben oder das Verhalten des von Kopia verwendeten emphemeralen Speichers mithilfe der CLI steuern. Weitere Informationen zu den Optionen, die Sie konfigurieren können, finden Sie in der "Kopia-Dokumentation". Verwenden Sie den tridentctl-protect create --help Befehl, um weitere Informationen zum Angeben von Annotationen mit der Trident Protect-CLI zu erhalten.
CR verwenden
Schritte
  1. Erstellen Sie die benutzerdefinierte Ressourcendatei (CR) und benennen Sie sie trident-protect-backup-restore-cr.yaml.

  2. Konfigurieren Sie in der erstellten Datei die folgenden Attribute:

    • metadata.name: (required) der Name dieser benutzerdefinierten Ressource; wählen Sie einen eindeutigen und sinnvollen Namen für Ihre Umgebung.

    • Spec.appArchivePath: Der Pfad innerhalb von AppVault, in dem die Backup-Inhalte gespeichert werden. Sie können den folgenden Befehl verwenden, um diesen Pfad zu finden:

      kubectl get backups <BACKUP_NAME> -n my-app-namespace -o jsonpath='{.status.appArchivePath}'
    • Spec.appVaultRef: (required) der Name des AppVault, in dem der Backup-Inhalt gespeichert ist.

    • spec.namespaceMapping: die Zuordnung des Quell-Namespace des Wiederherstellungsvorgangs zum Ziel-Namespace. Ersetzen my-source-namespace Sie und my-destination-namespace mit Informationen aus Ihrer Umgebung.

    • Spec.storageClassMapping: Das Mapping der Quellspeicherklasse des Wiederherstellungsvorgangs an die Zielspeicherklasse. Ersetzen destinationStorageClass Sie und sourceStorageClass mit Informationen aus Ihrer Umgebung.

      ---
      apiVersion: protect.trident.netapp.io/v1
      kind: BackupRestore
      metadata:
        name: my-cr-name
        namespace: my-destination-namespace
        annotations: # Optional annotations for Kopia data mover
          protect.trident.netapp.io/kopia-content-cache-size-limit-mb: "1000"
      spec:
        appArchivePath: my-backup-path
        appVaultRef: appvault-name
        namespaceMapping: [{"source": "my-source-namespace", "destination": "my-destination-namespace"}]
        storageClassMapping:
          destination: "${destinationStorageClass}"
          source: "${sourceStorageClass}"
  3. (Optional) Wenn Sie nur bestimmte Ressourcen der wiederherzustellenden Anwendung auswählen müssen, fügen Sie eine Filterung hinzu, die Ressourcen mit bestimmten Bezeichnungen enthält oder ausschließt:

    Hinweis Trident Protect wählt einige Ressourcen automatisch aus, da sie mit den von Ihnen ausgewählten Ressourcen in Beziehung stehen. Wenn Sie beispielsweise eine beanspruchende Ressource für ein persistentes Volume auswählen und ihm ein zugeordneter Pod zugewiesen ist, stellt Trident Protect auch den zugehörigen Pod wieder her.
    • ResourceFilter.resourceSelectionCriteria: (Erforderlich für die Filterung) Verwenden Include oder Exclude um eine in resourceMatchers definierte Ressource ein- oder auszuschließen. Fügen Sie die folgenden resourceMatchers-Parameter hinzu, um die einzuschließenden oder auszuschließenden Ressourcen zu definieren:

      • RefindeFilter.refindeMatchers: Eine Reihe von refindeMatcher-Objekten. Wenn Sie mehrere Elemente in diesem Array definieren, stimmen sie als OP-Operation überein, und die Felder innerhalb jedes Elements (Gruppe, Typ, Version) stimmen mit einer UND-Operation überein.

        • ResourceMatchers[].Group: (Optional) Gruppe der zu filternden Ressource.

        • ResourceMatchers[].Kind: (Optional) Art der zu filternden Ressource.

        • ResourceMatchers[].Version: (Optional) Version der zu filternden Ressource.

        • ResourceMatchers[].Namen: (Optional) Namen im Kubernetes metadata.name-Feld der zu filternden Ressource.

        • ResourceMatchers[].Namespaces: (Optional) Namespaces im Kubernetes metadata.name-Feld der zu filternden Ressource.

        • ResourceMatchers[].labelSelectors: (Optional) Label selector string im Feld Kubernetes metadata.name der Ressource, wie im definiert "Kubernetes-Dokumentation". Zum Beispiel: "trident.netapp.io/os=linux".

          Beispiel:

    spec:
      resourceFilter:
        resourceSelectionCriteria: "Include"
        resourceMatchers:
          - group: my-resource-group-1
            kind: my-resource-kind-1
            version: my-resource-version-1
            names: ["my-resource-names"]
            namespaces: ["my-resource-namespaces"]
            labelSelectors: ["trident.netapp.io/os=linux"]
          - group: my-resource-group-2
            kind: my-resource-kind-2
            version: my-resource-version-2
            names: ["my-resource-names"]
            namespaces: ["my-resource-namespaces"]
            labelSelectors: ["trident.netapp.io/os=linux"]
  4. Nachdem Sie die Datei mit den richtigen Werten ausgefüllt trident-protect-backup-restore-cr.yaml haben, wenden Sie den CR an:

    kubectl apply -f trident-protect-backup-restore-cr.yaml
Verwenden Sie die CLI
Schritte
  1. Stellen Sie das Backup in einem anderen Namespace wieder her und ersetzen Sie die Werte in Klammern durch Informationen aus Ihrer Umgebung. Das namespace-mapping Argument verwendet durch Doppelpunkte getrennte Namespaces, um Quellnamepaces im Format den richtigen Zielnamepaces zuzuordnen source1:dest1,source2:dest2. Beispiel:

    tridentctl-protect create backuprestore <my_restore_name> \
    --backup <backup_namespace>/<backup_to_restore> \
    --namespace-mapping <source_to_destination_namespace_mapping> \
    -n <application_namespace>

Wiederherstellung von einem Backup in den ursprünglichen Namespace

Sie können ein Backup im ursprünglichen Namespace jederzeit wiederherstellen.

Bevor Sie beginnen

Vergewissern Sie sich, dass der Ablauf des AWS-Sitzungstokens für alle langwierigen s3-Wiederherstellungsvorgänge ausreichend ist. Wenn das Token während des Wiederherstellungsvorgangs abläuft, kann der Vorgang fehlschlagen.

Hinweis Wenn Sie Backups mit Kopia als Data Mover wiederherstellen, können Sie optional Anmerkungen im CR-System angeben oder das Verhalten des von Kopia verwendeten emphemeralen Speichers mithilfe der CLI steuern. Weitere Informationen zu den Optionen, die Sie konfigurieren können, finden Sie in der "Kopia-Dokumentation". Verwenden Sie den tridentctl-protect create --help Befehl, um weitere Informationen zum Angeben von Annotationen mit der Trident Protect-CLI zu erhalten.
CR verwenden
Schritte
  1. Erstellen Sie die benutzerdefinierte Ressourcendatei (CR) und benennen Sie sie trident-protect-backup-ipr-cr.yaml.

  2. Konfigurieren Sie in der erstellten Datei die folgenden Attribute:

    • metadata.name: (required) der Name dieser benutzerdefinierten Ressource; wählen Sie einen eindeutigen und sinnvollen Namen für Ihre Umgebung.

    • Spec.appArchivePath: Der Pfad innerhalb von AppVault, in dem die Backup-Inhalte gespeichert werden. Sie können den folgenden Befehl verwenden, um diesen Pfad zu finden:

      kubectl get backups <BACKUP_NAME> -n my-app-namespace -o jsonpath='{.status.appArchivePath}'
    • Spec.appVaultRef: (required) der Name des AppVault, in dem der Backup-Inhalt gespeichert ist.

      Beispiel:

    ---
    apiVersion: protect.trident.netapp.io/v1
    kind: BackupInplaceRestore
    metadata:
      name: my-cr-name
      namespace: my-app-namespace
      annotations: # Optional annotations for Kopia data mover
        protect.trident.netapp.io/kopia-content-cache-size-limit-mb: "1000"
    spec:
      appArchivePath: my-backup-path
      appVaultRef: appvault-name
  3. (Optional) Wenn Sie nur bestimmte Ressourcen der wiederherzustellenden Anwendung auswählen müssen, fügen Sie eine Filterung hinzu, die Ressourcen mit bestimmten Bezeichnungen enthält oder ausschließt:

    Hinweis Trident Protect wählt einige Ressourcen automatisch aus, da sie mit den von Ihnen ausgewählten Ressourcen in Beziehung stehen. Wenn Sie beispielsweise eine beanspruchende Ressource für ein persistentes Volume auswählen und ihm ein zugeordneter Pod zugewiesen ist, stellt Trident Protect auch den zugehörigen Pod wieder her.
    • ResourceFilter.resourceSelectionCriteria: (Erforderlich für die Filterung) Verwenden Include oder Exclude um eine in resourceMatchers definierte Ressource ein- oder auszuschließen. Fügen Sie die folgenden resourceMatchers-Parameter hinzu, um die einzuschließenden oder auszuschließenden Ressourcen zu definieren:

      • RefindeFilter.refindeMatchers: Eine Reihe von refindeMatcher-Objekten. Wenn Sie mehrere Elemente in diesem Array definieren, stimmen sie als OP-Operation überein, und die Felder innerhalb jedes Elements (Gruppe, Typ, Version) stimmen mit einer UND-Operation überein.

        • ResourceMatchers[].Group: (Optional) Gruppe der zu filternden Ressource.

        • ResourceMatchers[].Kind: (Optional) Art der zu filternden Ressource.

        • ResourceMatchers[].Version: (Optional) Version der zu filternden Ressource.

        • ResourceMatchers[].Namen: (Optional) Namen im Kubernetes metadata.name-Feld der zu filternden Ressource.

        • ResourceMatchers[].Namespaces: (Optional) Namespaces im Kubernetes metadata.name-Feld der zu filternden Ressource.

        • ResourceMatchers[].labelSelectors: (Optional) Label selector string im Feld Kubernetes metadata.name der Ressource, wie im definiert "Kubernetes-Dokumentation". Zum Beispiel: "trident.netapp.io/os=linux".

          Beispiel:

    spec:
      resourceFilter:
        resourceSelectionCriteria: "Include"
        resourceMatchers:
          - group: my-resource-group-1
            kind: my-resource-kind-1
            version: my-resource-version-1
            names: ["my-resource-names"]
            namespaces: ["my-resource-namespaces"]
            labelSelectors: ["trident.netapp.io/os=linux"]
          - group: my-resource-group-2
            kind: my-resource-kind-2
            version: my-resource-version-2
            names: ["my-resource-names"]
            namespaces: ["my-resource-namespaces"]
            labelSelectors: ["trident.netapp.io/os=linux"]
  4. Nachdem Sie die Datei mit den richtigen Werten ausgefüllt trident-protect-backup-ipr-cr.yaml haben, wenden Sie den CR an:

    kubectl apply -f trident-protect-backup-ipr-cr.yaml
Verwenden Sie die CLI
Schritte
  1. Stellen Sie das Backup auf den ursprünglichen Namespace wieder her, und ersetzen Sie die Werte in Klammern durch Informationen aus Ihrer Umgebung. Das backup Argument verwendet einen Namespace und einen Backup-Namen im Format <namespace>/<name>. Beispiel:

    tridentctl-protect create backupinplacerestore <my_restore_name> \
    --backup <namespace/backup_to_restore> \
    -n <application_namespace>

Wiederherstellung von einem Backup in einem anderen Cluster

Sie können ein Backup in einem anderen Cluster wiederherstellen, wenn ein Problem mit dem ursprünglichen Cluster auftritt.

Hinweis Wenn Sie Backups mit Kopia als Data Mover wiederherstellen, können Sie optional Anmerkungen im CR-System angeben oder das Verhalten des von Kopia verwendeten emphemeralen Speichers mithilfe der CLI steuern. Weitere Informationen zu den Optionen, die Sie konfigurieren können, finden Sie in der "Kopia-Dokumentation". Verwenden Sie den tridentctl-protect create --help Befehl, um weitere Informationen zum Angeben von Annotationen mit der Trident Protect-CLI zu erhalten.
Bevor Sie beginnen

Stellen Sie sicher, dass die folgenden Voraussetzungen erfüllt sind:

  • Auf dem Zielcluster ist Trident Protect installiert.

  • Der Zielcluster hat Zugriff auf den Bucket-Pfad desselben AppVault wie das Quellcluster, in dem das Backup gespeichert ist.

  • Stellen Sie sicher, dass der Ablauf des AWS-Sitzungstokens für alle Wiederherstellungsvorgänge mit langer Laufzeit ausreicht. Wenn das Token während des Wiederherstellungsvorgangs abläuft, kann der Vorgang fehlschlagen.

    • Weitere Informationen zum Überprüfen des Ablaufes des aktuellen Sitzungstokens finden Sie im "AWS API-Dokumentation".

    • Weitere Informationen zu Zugangsdaten für AWS Ressourcen finden Sie in der "AWS-Dokumentation".

Schritte
  1. Überprüfen Sie die Verfügbarkeit von AppVault CR auf dem Zielcluster mithilfe des Trident Protect CLI-Plug-ins:

    tridentctl-protect get appvault --context <destination_cluster_name>
    Hinweis Stellen Sie sicher, dass der für die Anwendungswiederherstellung vorgesehene Namespace auf dem Zielcluster vorhanden ist.
  2. Zeigen Sie die Backup-Inhalte des verfügbaren AppVault vom Zielcluster an:

    tridentctl-protect get appvaultcontent <appvault_name> \
    --show-resources backup \
    --show-paths \
    --context <destination_cluster_name>

    Mit diesem Befehl werden die verfügbaren Backups im AppVault angezeigt, einschließlich der ursprünglichen Cluster, der entsprechenden Anwendungsnamen, Zeitstempel und Archivpfade.

    Beispielausgabe:

    +-------------+-----------+--------+-----------------+--------------------------+-------------+
    |   CLUSTER   |    APP    |  TYPE  |      NAME       |        TIMESTAMP         |    PATH     |
    +-------------+-----------+--------+-----------------+--------------------------+-------------+
    | production1 | wordpress | backup | wordpress-bkup-1| 2024-10-30 08:37:40 (UTC)| backuppath1 |
    | production1 | wordpress | backup | wordpress-bkup-2| 2024-10-30 08:37:40 (UTC)| backuppath2 |
    +-------------+-----------+--------+-----------------+--------------------------+-------------+
  3. Stellen Sie die Anwendung mithilfe des AppVault-Namens und Archivpfads auf dem Zielcluster wieder her:

CR verwenden
  1. Erstellen Sie die benutzerdefinierte Ressourcendatei (CR) und benennen Sie sie trident-protect-backup-restore-cr.yaml.

  2. Konfigurieren Sie in der erstellten Datei die folgenden Attribute:

    • metadata.name: (required) der Name dieser benutzerdefinierten Ressource; wählen Sie einen eindeutigen und sinnvollen Namen für Ihre Umgebung.

    • Spec.appVaultRef: (required) der Name des AppVault, in dem der Backup-Inhalt gespeichert ist.

    • Spec.appArchivePath: Der Pfad innerhalb von AppVault, in dem die Backup-Inhalte gespeichert werden. Sie können den folgenden Befehl verwenden, um diesen Pfad zu finden:

      kubectl get backups <BACKUP_NAME> -n my-app-namespace -o jsonpath='{.status.appArchivePath}'
      Hinweis Wenn BackupRestore CR nicht verfügbar ist, können Sie den in Schritt 2 genannten Befehl verwenden, um den Inhalt des Backups anzuzeigen.
    • spec.namespaceMapping: die Zuordnung des Quell-Namespace des Wiederherstellungsvorgangs zum Ziel-Namespace. Ersetzen my-source-namespace Sie und my-destination-namespace mit Informationen aus Ihrer Umgebung.

      Beispiel:

    apiVersion: protect.trident.netapp.io/v1
    kind: BackupRestore
    metadata:
      name: my-cr-name
      namespace: my-destination-namespace
      annotations: # Optional annotations for Kopia data mover
        protect.trident.netapp.io/kopia-content-cache-size-limit-mb: "1000"
    spec:
      appVaultRef: appvault-name
      appArchivePath: my-backup-path
      namespaceMapping: [{"source": "my-source-namespace", "destination": "my-destination-namespace"}]
  3. Nachdem Sie die Datei mit den richtigen Werten ausgefüllt trident-protect-backup-restore-cr.yaml haben, wenden Sie den CR an:

    kubectl apply -f trident-protect-backup-restore-cr.yaml
Verwenden Sie die CLI
  1. Verwenden Sie den folgenden Befehl, um die Anwendung wiederherzustellen und Werte in Klammern durch Informationen aus Ihrer Umgebung zu ersetzen. Das Namespace-Mapping-Argument verwendet durch Doppelpunkte getrennte Namespaces, um Quellnamepaces im Format source1:dest1,source2:dest2 den korrekten Zielnamepaces zuzuordnen. Beispiel:

    tridentctl-protect create backuprestore <restore_name> \
    --namespace-mapping <source_to_destination_namespace_mapping> \
    --appvault <appvault_name> \
    --path <backup_path> \
    --context <destination_cluster_name> \
    -n <application_namespace>

Wiederherstellung von einem Snapshot in einem anderen Namespace

Sie können Daten aus einem Snapshot mithilfe einer benutzerdefinierten Ressourcendatei (CR) entweder in einem anderen Namespace oder im ursprünglichen QuellNamespace wiederherstellen. Wenn Sie einen Snapshot mithilfe eines SnapshotRestore CR in einem anderen Namespace wiederherstellen, stellt Trident Protect die Anwendung in einem neuen Namespace wieder her und erstellt eine Anwendungs-CR für die wiederhergestellte Anwendung. Erstellen Sie zum Schutz der wiederhergestellten Applikation On-Demand-Backups oder Snapshots oder erstellen Sie einen Sicherungszeitplan.

Bevor Sie beginnen

Vergewissern Sie sich, dass der Ablauf des AWS-Sitzungstokens für alle langwierigen s3-Wiederherstellungsvorgänge ausreichend ist. Wenn das Token während des Wiederherstellungsvorgangs abläuft, kann der Vorgang fehlschlagen.

CR verwenden
Schritte
  1. Erstellen Sie die benutzerdefinierte Ressourcendatei (CR) und benennen Sie sie trident-protect-snapshot-restore-cr.yaml.

  2. Konfigurieren Sie in der erstellten Datei die folgenden Attribute:

    • metadata.name: (required) der Name dieser benutzerdefinierten Ressource; wählen Sie einen eindeutigen und sinnvollen Namen für Ihre Umgebung.

    • Spec.appVaultRef: (required) der Name des AppVault, in dem der Snapshot-Inhalt gespeichert ist.

    • Spec.appArchivePath: Der Pfad innerhalb von AppVault, wo der Snapshot-Inhalt gespeichert wird. Sie können den folgenden Befehl verwenden, um diesen Pfad zu finden:

      kubectl get snapshots <SNAPHOT_NAME> -n my-app-namespace -o jsonpath='{.status.appArchivePath}'
    • spec.namespaceMapping: die Zuordnung des Quell-Namespace des Wiederherstellungsvorgangs zum Ziel-Namespace. Ersetzen my-source-namespace Sie und my-destination-namespace mit Informationen aus Ihrer Umgebung.

    • Spec.storageClassMapping: Das Mapping der Quellspeicherklasse des Wiederherstellungsvorgangs an die Zielspeicherklasse. Ersetzen destinationStorageClass Sie und sourceStorageClass mit Informationen aus Ihrer Umgebung.

      Hinweis Der storageClassMapping Attribut funktioniert nur, wenn sowohl das ursprüngliche als auch das neue StorageClass Verwenden Sie dasselbe Speicher-Backend. Wenn Sie versuchen, auf einem StorageClass das ein anderes Speicher-Backend verwendet, schlägt der Wiederherstellungsvorgang fehl.
    ---
    apiVersion: protect.trident.netapp.io/v1
    kind: SnapshotRestore
    metadata:
      name: my-cr-name
      namespace: my-app-namespace
    spec:
      appVaultRef: appvault-name
      appArchivePath: my-snapshot-path
      namespaceMapping: [{"source": "my-source-namespace", "destination": "my-destination-namespace"}]
      storageClassMapping:
        destination: "${destinationStorageClass}"
        source: "${sourceStorageClass}"
  3. (Optional) Wenn Sie nur bestimmte Ressourcen der wiederherzustellenden Anwendung auswählen müssen, fügen Sie eine Filterung hinzu, die Ressourcen mit bestimmten Bezeichnungen enthält oder ausschließt:

    Hinweis Trident Protect wählt einige Ressourcen automatisch aus, da sie mit den von Ihnen ausgewählten Ressourcen in Beziehung stehen. Wenn Sie beispielsweise eine beanspruchende Ressource für ein persistentes Volume auswählen und ihm ein zugeordneter Pod zugewiesen ist, stellt Trident Protect auch den zugehörigen Pod wieder her.
    • ResourceFilter.resourceSelectionCriteria: (Erforderlich für die Filterung) Verwenden Include oder Exclude um eine in resourceMatchers definierte Ressource ein- oder auszuschließen. Fügen Sie die folgenden resourceMatchers-Parameter hinzu, um die einzuschließenden oder auszuschließenden Ressourcen zu definieren:

      • RefindeFilter.refindeMatchers: Eine Reihe von refindeMatcher-Objekten. Wenn Sie mehrere Elemente in diesem Array definieren, stimmen sie als OP-Operation überein, und die Felder innerhalb jedes Elements (Gruppe, Typ, Version) stimmen mit einer UND-Operation überein.

        • ResourceMatchers[].Group: (Optional) Gruppe der zu filternden Ressource.

        • ResourceMatchers[].Kind: (Optional) Art der zu filternden Ressource.

        • ResourceMatchers[].Version: (Optional) Version der zu filternden Ressource.

        • ResourceMatchers[].Namen: (Optional) Namen im Kubernetes metadata.name-Feld der zu filternden Ressource.

        • ResourceMatchers[].Namespaces: (Optional) Namespaces im Kubernetes metadata.name-Feld der zu filternden Ressource.

        • ResourceMatchers[].labelSelectors: (Optional) Label selector string im Feld Kubernetes metadata.name der Ressource, wie im definiert "Kubernetes-Dokumentation". Zum Beispiel: "trident.netapp.io/os=linux".

          Beispiel:

    spec:
      resourceFilter:
        resourceSelectionCriteria: "Include"
        resourceMatchers:
          - group: my-resource-group-1
            kind: my-resource-kind-1
            version: my-resource-version-1
            names: ["my-resource-names"]
            namespaces: ["my-resource-namespaces"]
            labelSelectors: ["trident.netapp.io/os=linux"]
          - group: my-resource-group-2
            kind: my-resource-kind-2
            version: my-resource-version-2
            names: ["my-resource-names"]
            namespaces: ["my-resource-namespaces"]
            labelSelectors: ["trident.netapp.io/os=linux"]
  4. Nachdem Sie die Datei mit den richtigen Werten ausgefüllt trident-protect-snapshot-restore-cr.yaml haben, wenden Sie den CR an:

    kubectl apply -f trident-protect-snapshot-restore-cr.yaml
Verwenden Sie die CLI
Schritte
  1. Stellen Sie den Snapshot in einem anderen Namespace wieder her und ersetzen Sie Werte in Klammern durch Informationen aus Ihrer Umgebung.

    • Das snapshot Argument verwendet einen Namespace und Snapshot-Namen im Format <namespace>/<name>.

    • Das namespace-mapping Argument verwendet durch Doppelpunkte getrennte Namespaces, um Quellnamepaces im Format den richtigen Zielnamepaces zuzuordnen source1:dest1,source2:dest2.

      Beispiel:

    tridentctl-protect create snapshotrestore <my_restore_name> \
    --snapshot <namespace/snapshot_to_restore> \
    --namespace-mapping <source_to_destination_namespace_mapping> \
    -n <application_namespace>

Wiederherstellung von einem Snapshot im ursprünglichen Namespace

Sie können einen Snapshot jederzeit im ursprünglichen Namespace wiederherstellen.

Bevor Sie beginnen

Vergewissern Sie sich, dass der Ablauf des AWS-Sitzungstokens für alle langwierigen s3-Wiederherstellungsvorgänge ausreichend ist. Wenn das Token während des Wiederherstellungsvorgangs abläuft, kann der Vorgang fehlschlagen.

CR verwenden
Schritte
  1. Erstellen Sie die benutzerdefinierte Ressourcendatei (CR) und benennen Sie sie trident-protect-snapshot-ipr-cr.yaml.

  2. Konfigurieren Sie in der erstellten Datei die folgenden Attribute:

    • metadata.name: (required) der Name dieser benutzerdefinierten Ressource; wählen Sie einen eindeutigen und sinnvollen Namen für Ihre Umgebung.

    • Spec.appVaultRef: (required) der Name des AppVault, in dem der Snapshot-Inhalt gespeichert ist.

    • Spec.appArchivePath: Der Pfad innerhalb von AppVault, wo der Snapshot-Inhalt gespeichert wird. Sie können den folgenden Befehl verwenden, um diesen Pfad zu finden:

      kubectl get snapshots <SNAPSHOT_NAME> -n my-app-namespace -o jsonpath='{.status.appArchivePath}'
      ---
      apiVersion: protect.trident.netapp.io/v1
      kind: SnapshotInplaceRestore
      metadata:
        name: my-cr-name
        namespace: my-app-namespace
      spec:
        appVaultRef: appvault-name
          appArchivePath: my-snapshot-path
  3. (Optional) Wenn Sie nur bestimmte Ressourcen der wiederherzustellenden Anwendung auswählen müssen, fügen Sie eine Filterung hinzu, die Ressourcen mit bestimmten Bezeichnungen enthält oder ausschließt:

    Hinweis Trident Protect wählt einige Ressourcen automatisch aus, da sie mit den von Ihnen ausgewählten Ressourcen in Beziehung stehen. Wenn Sie beispielsweise eine beanspruchende Ressource für ein persistentes Volume auswählen und ihm ein zugeordneter Pod zugewiesen ist, stellt Trident Protect auch den zugehörigen Pod wieder her.
    • ResourceFilter.resourceSelectionCriteria: (Erforderlich für die Filterung) Verwenden Include oder Exclude um eine in resourceMatchers definierte Ressource ein- oder auszuschließen. Fügen Sie die folgenden resourceMatchers-Parameter hinzu, um die einzuschließenden oder auszuschließenden Ressourcen zu definieren:

      • RefindeFilter.refindeMatchers: Eine Reihe von refindeMatcher-Objekten. Wenn Sie mehrere Elemente in diesem Array definieren, stimmen sie als OP-Operation überein, und die Felder innerhalb jedes Elements (Gruppe, Typ, Version) stimmen mit einer UND-Operation überein.

        • ResourceMatchers[].Group: (Optional) Gruppe der zu filternden Ressource.

        • ResourceMatchers[].Kind: (Optional) Art der zu filternden Ressource.

        • ResourceMatchers[].Version: (Optional) Version der zu filternden Ressource.

        • ResourceMatchers[].Namen: (Optional) Namen im Kubernetes metadata.name-Feld der zu filternden Ressource.

        • ResourceMatchers[].Namespaces: (Optional) Namespaces im Kubernetes metadata.name-Feld der zu filternden Ressource.

        • ResourceMatchers[].labelSelectors: (Optional) Label selector string im Feld Kubernetes metadata.name der Ressource, wie im definiert "Kubernetes-Dokumentation". Zum Beispiel: "trident.netapp.io/os=linux".

          Beispiel:

    spec:
      resourceFilter:
        resourceSelectionCriteria: "Include"
        resourceMatchers:
          - group: my-resource-group-1
            kind: my-resource-kind-1
            version: my-resource-version-1
            names: ["my-resource-names"]
            namespaces: ["my-resource-namespaces"]
            labelSelectors: ["trident.netapp.io/os=linux"]
          - group: my-resource-group-2
            kind: my-resource-kind-2
            version: my-resource-version-2
            names: ["my-resource-names"]
            namespaces: ["my-resource-namespaces"]
            labelSelectors: ["trident.netapp.io/os=linux"]
  4. Nachdem Sie die Datei mit den richtigen Werten ausgefüllt trident-protect-snapshot-ipr-cr.yaml haben, wenden Sie den CR an:

    kubectl apply -f trident-protect-snapshot-ipr-cr.yaml
Verwenden Sie die CLI
Schritte
  1. Stellen Sie den Snapshot auf den ursprünglichen Namespace wieder her, und ersetzen Sie Werte in Klammern durch Informationen aus Ihrer Umgebung. Beispiel:

    tridentctl-protect create snapshotinplacerestore <my_restore_name> \
    --snapshot <snapshot_to_restore> \
    -n <application_namespace>

Überprüfen Sie den Status eines Wiederherstellungsvorgangs

Sie können die Befehlszeile verwenden, um den Status eines Wiederherstellungsvorgangs zu überprüfen, der gerade ausgeführt wird, abgeschlossen wurde oder fehlgeschlagen ist.

Schritte
  1. Verwenden Sie den folgenden Befehl, um den Status des Wiederherstellungsvorgangs abzurufen und Werte in Bracken durch Informationen aus Ihrer Umgebung zu ersetzen:

    kubectl get backuprestore -n <namespace_name> <my_restore_cr_name> -o jsonpath='{.status}'