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

Sicherung von Applikationen mit Trident Protect

09/04/2025 Beitragende

PDFs

Sie können alle von Trident Protect gemanagten Applikationen schützen, indem Sie Snapshots und Backups mithilfe einer automatisierten Sicherungsrichtlinie oder ad hoc erstellen.

Sie können Trident Protect so konfigurieren, dass Dateisysteme während des Datenschutzes eingefroren und wieder eingefroren werden. "Erfahren Sie mehr über das Konfigurieren des Dateisystemfrierens mit Trident Protect".

Erstellen Sie einen On-Demand Snapshot

Sie können jederzeit einen On-Demand-Snapshot erstellen.

Im Umfang des Clusters enthaltene Ressourcen werden in einem Backup, einem Snapshot oder Klon eingeschlossen, wenn sie in der Anwendungsdefinition explizit referenziert werden oder wenn sie Verweise auf einen der Anwendungsnamepspaces haben.

Erstellen Sie mithilfe eines CR-Systems einen Snapshot

Schritte

Erstellen Sie die benutzerdefinierte Ressourcendatei (CR) und benennen Sie sie trident-protect-snapshot-cr.yaml.
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.applicationRef: Der Kubernetes-Name der zu Snapshot enden Anwendung.
- Spec.appVaultRef: (required) der Name des AppVault, in dem der Snapshot-Inhalt (Metadaten) gespeichert werden soll.
- Spec.reclaimPolicy: (Optional) definiert, was mit dem AppArchiv eines Snapshots geschieht, wenn der Snapshot CR gelöscht wird. Das bedeutet, dass der Snapshot auch dann gelöscht wird, wenn er auf gesetzt Retain ist. Gültige Optionen:
  - Retain (Standard)
  - Delete
    
    --- apiVersion: protect.trident.netapp.io/v1 kind: Snapshot metadata: namespace: my-app-namespace name: my-cr-name spec: applicationRef: my-application appVaultRef: appvault-name reclaimPolicy: Delete
Nachdem Sie die Datei mit den richtigen Werten ausgefüllt trident-protect-snapshot-cr.yaml haben, wenden Sie den CR an:
```
kubectl apply -f trident-protect-snapshot-cr.yaml
```

Erstellen Sie einen Snapshot mithilfe der CLI

Schritte

Erstellen Sie den Snapshot, und ersetzen Sie Werte in Klammern durch Informationen aus Ihrer Umgebung. Beispiel:

tridentctl-protect create snapshot <my_snapshot_name> --appvault <my_appvault_name> --app <name_of_app_to_snapshot> -n <application_namespace>

Erstellen Sie ein On-Demand-Backup

Sie können eine App jederzeit sichern.

Bevor Sie beginnen

Vergewissern Sie sich, dass der Ablauf des AWS-Sitzungstokens für alle langwierigen s3-Backup-Vorgänge ausreichend ist. Wenn das Token während des Backup-Vorgangs 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 IAM-Dokumentation".

Erstellen Sie ein Backup mit einem CR

Schritte

Erstellen Sie die benutzerdefinierte Ressourcendatei (CR) und benennen Sie sie trident-protect-backup-cr.yaml.
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.applicationRef: (required) der Kubernetes-Name der zu Back-up-Applikation.
- Spec.appVaultRef: (required) der Name des AppVault, in dem der Backup-Inhalt gespeichert werden soll.
- Spec.DataMover: (Optional) Eine Zeichenfolge, die angibt, welches Backup-Tool für den Backup-Vorgang verwendet werden soll. Mögliche Werte (Groß-/Kleinschreibung beachten):
  - Restic
  - Kopia (Standard)
- Spec.reclaimPolicy: (Optional) definiert, was mit einem Backup geschieht, wenn es von seinem Anspruch freigegeben wird. Mögliche Werte:
  - Delete
  - Retain (Standard)
- spec.snapshotRef: (Optional): Name des Snapshots, der als Quelle der Sicherung verwendet werden soll. Falls nicht angegeben, wird ein temporärer Snapshot erstellt und gesichert.
- metadata.annotations.protect.trident.netapp.io/full-backup: (Optional) Diese Annotation wird verwendet, um anzugeben, ob eine Sicherung nicht inkrementell sein soll. Standardmäßig sind alle Backups inkrementell. Wenn diese Anmerkung jedoch auf eingestellt ist true, wird die Sicherung nicht inkrementell. Falls nicht angegeben, folgt das Backup der standardmäßigen inkrementellen Backup-Einstellung. Es empfiehlt sich, regelmäßig ein vollständiges Backup durchzuführen und anschließend zwischen vollständigen Backups inkrementelle Backups durchzuführen, um das Risiko von Wiederherstellungen zu minimieren.
  
  Beispiel YAML:
```
---
apiVersion: protect.trident.netapp.io/v1
kind: Backup
metadata:
  namespace: my-app-namespace
  name: my-cr-name
  annotations:
    protect.trident.netapp.io/full-backup: "true"
spec:
  applicationRef: my-application
  appVaultRef: appvault-name
  dataMover: Kopia
```
Nachdem Sie die Datei mit den richtigen Werten ausgefüllt trident-protect-backup-cr.yaml haben, wenden Sie den CR an:
```
kubectl apply -f trident-protect-backup-cr.yaml
```

Erstellen Sie mithilfe der CLI ein Backup

Schritte

Erstellen Sie das Backup, und ersetzen Sie Werte in Klammern durch Informationen aus Ihrer Umgebung. Beispiel:
```
tridentctl-protect create backup <my_backup_name> --appvault <my-vault-name> --app <name_of_app_to_back_up> --data-mover <Kopia_or_Restic> -n <application_namespace>
```
Optional können Sie mit dem --full-backup Flag angeben, ob ein Backup nicht inkrementell sein soll. Standardmäßig sind alle Backups inkrementell. Wenn dieses Flag verwendet wird, wird das Backup nicht inkrementell. Es empfiehlt sich, regelmäßig ein vollständiges Backup durchzuführen und anschließend zwischen vollständigen Backups inkrementelle Backups durchzuführen, um das Risiko von Wiederherstellungen zu minimieren.

Erstellen Sie einen Zeitplan für die Datensicherung

Eine Schutzrichtlinie schützt eine App, indem sie nach einem festgelegten Zeitplan Snapshots, Backups oder beides erstellt. Sie können stündlich, täglich, wöchentlich und monatlich Snapshots und Backups erstellen und die Anzahl der aufzubewahrenden Kopien angeben. Sie können eine nicht inkrementelle vollständige Sicherung planen, indem Sie die Annotation „full-backup-rule“ verwenden. Standardmäßig sind alle Sicherungen inkrementell. Durch regelmäßiges Durchführen einer vollständigen Sicherung und inkrementeller Sicherungen zwischendurch können Sie das mit Wiederherstellungen verbundene Risiko verringern.

Sie können Zeitpläne für Snapshots nur erstellen, indem Sie backupRetention auf Null und snapshotRetention auf einen Wert größer Null. Einstellung snapshotRetention auf Null bedeutet, dass bei allen geplanten Sicherungen weiterhin Snapshots erstellt werden, diese sind jedoch temporär und werden unmittelbar nach Abschluss der Sicherung gelöscht.
Im Umfang des Clusters enthaltene Ressourcen werden in einem Backup, einem Snapshot oder Klon eingeschlossen, wenn sie in der Anwendungsdefinition explizit referenziert werden oder wenn sie Verweise auf einen der Anwendungsnamepspaces haben.

Erstellen Sie einen Zeitplan mit einem CR

Schritte

Erstellen Sie die benutzerdefinierte Ressourcendatei (CR) und benennen Sie sie trident-protect-schedule-cr.yaml.
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.DataMover: (Optional) Eine Zeichenfolge, die angibt, welches Backup-Tool für den Backup-Vorgang verwendet werden soll. Mögliche Werte (Groß-/Kleinschreibung beachten):
  - Restic
  - Kopia (Standard)
- Spec.applicationRef: Der Kubernetes-Name der zu Back-up Applikation.
- Spec.appVaultRef: (required) der Name des AppVault, in dem der Backup-Inhalt gespeichert werden soll.
- spec.backupRetention: Die Anzahl der aufzubewahrenden Backups. Null gibt an, dass keine Sicherungen erstellt werden sollen (nur Snapshots).
- Spec.snapshotRetention: Die Anzahl der zu behaltenden Snapshots. Null bedeutet, dass keine Snapshots erstellt werden sollen.
- spec.granularity: die Häufigkeit, mit der der Zeitplan ausgeführt werden soll. Mögliche Werte, zusammen mit den erforderlichen zugeordneten Feldern:
  - Hourly(erfordert die Angabe spec.minute )
  - Daily(erfordert die Angabe spec.minute Und spec.hour )
  - Weekly(erfordert die Angabe spec.minute, spec.hour , Und spec.dayOfWeek )
  - Monthly(erfordert die Angabe spec.minute, spec.hour , Und spec.dayOfMonth )
  - Custom
- spec.dayOfMonth: (Optional) Der Tag des Monats (1 – 31), an dem der Zeitplan ausgeführt werden soll. Dieses Feld ist erforderlich, wenn die Granularität auf Monthly . Der Wert muss als Zeichenfolge angegeben werden.
- spec.dayOfWeek: (Optional) Der Wochentag (0 - 7), an dem der Zeitplan ausgeführt werden soll. Werte von 0 oder 7 zeigen Sonntag an. Dieses Feld ist erforderlich, wenn die Granularität auf Weekly . Der Wert muss als Zeichenfolge angegeben werden.
- spec.hour: (Optional) Die Stunde des Tages (0 - 23), zu der der Zeitplan ausgeführt werden soll. Dieses Feld ist erforderlich, wenn die Granularität auf Daily , Weekly , oder Monthly . Der Wert muss als Zeichenfolge angegeben werden.
- spec.minute: (Optional) Die Minute der Stunde (0 – 59), zu der der Zeitplan ausgeführt werden soll. Dieses Feld ist erforderlich, wenn die Granularität auf Hourly , Daily , Weekly , oder Monthly . Der Wert muss als Zeichenfolge angegeben werden.
- metadata.annotations.protect.trident.netapp.io/full-backup-rule: (Optional) Diese Anmerkung wird verwendet, um die Regel für die Planung eines vollständigen Backups anzugeben. Sie können ihn für ein konstantes vollständiges Backup einstellen always oder es an Ihre Anforderungen anpassen. Wenn Sie beispielsweise die tägliche Granularität auswählen, können Sie die Wochentage angeben, an denen ein vollständiges Backup erfolgen soll.
  
  Beispiel-YAML für Sicherungs- und Snapshot-Zeitplan:
  --- apiVersion: protect.trident.netapp.io/v1 kind: Schedule metadata: namespace: my-app-namespace name: my-cr-name annotations: protect.trident.netapp.io/full-backup-rule: "Monday,Thursday" spec: dataMover: Kopia applicationRef: my-application appVaultRef: appvault-name backupRetention: "15" snapshotRetention: "15" granularity: Daily hour: "0" minute: "0"
  Beispiel-YAML für einen Nur-Snapshot-Zeitplan:
```
---
apiVersion: protect.trident.netapp.io/v1
kind: Schedule
metadata:
  namespace: my-app-namespace
  name: my-snapshot-schedule
spec:
  applicationRef: my-application
  appVaultRef: appvault-name
  backupRetention: "0"
  snapshotRetention: "15"
  granularity: Daily
  hour: "2"
  minute: "0"
```
Nachdem Sie die Datei mit den richtigen Werten ausgefüllt trident-protect-schedule-cr.yaml haben, wenden Sie den CR an:
```
kubectl apply -f trident-protect-schedule-cr.yaml
```

Erstellen Sie einen Zeitplan über die CLI

Schritte

Erstellen Sie den Schutzplan und ersetzen Sie Werte in Klammern durch Informationen aus Ihrer Umgebung. Beispiel:

Mit können tridentctl-protect create schedule --help Sie detaillierte Hilfeinformationen für diesen Befehl anzeigen.
```
tridentctl-protect create schedule <my_schedule_name> --appvault <my_appvault_name> --app <name_of_app_to_snapshot> --backup-retention <how_many_backups_to_retain> --data-mover <Kopia_or_Restic> --day-of-month <day_of_month_to_run_schedule> --day-of-week <day_of_month_to_run_schedule> --granularity <frequency_to_run> --hour <hour_of_day_to_run> --minute <minute_of_hour_to_run> --recurrence-rule <recurrence> --snapshot-retention <how_many_snapshots_to_retain> -n <application_namespace> --full-backup-rule <string>
```
Sie können das Flag auf always für ein konstantes vollständiges Backup setzen --full-backup-rule oder es an Ihre Anforderungen anpassen. Wenn Sie beispielsweise die tägliche Granularität wählen, können Sie die Wochentage angeben, an denen das vollständige Backup erfolgen soll. Verwenden Sie beispielsweise --full-backup-rule "Monday,Thursday", um die vollständige Sicherung montags und donnerstags zu planen.

Für Snapshot-only-Zeitpläne legen Sie fest --backup-retention 0 und geben Sie einen Wert größer als 0 an für --snapshot-retention .

Löschen Sie einen Snapshot

Löschen Sie die geplanten oder On-Demand Snapshots, die Sie nicht mehr benötigen.

Schritte

Entfernen Sie den Snapshot CR, der dem Snapshot zugeordnet ist:
```
kubectl delete snapshot <snapshot_name> -n my-app-namespace
```

Löschen Sie ein Backup

Löschen Sie die geplanten oder On-Demand-Backups, die Sie nicht mehr benötigen.

Stellen Sie sicher, dass die Rückforderungsrichtlinie auf Delete , um alle Sicherungsdaten aus dem Objektspeicher zu entfernen. Die Standardeinstellung der Richtlinie ist Retain um versehentlichen Datenverlust zu vermeiden. Wenn die Richtlinie nicht geändert wird Delete , verbleiben die Sicherungsdaten im Objektspeicher und müssen manuell gelöscht werden.

Schritte

Entfernen Sie den Backup-CR, der dem Backup zugeordnet ist:
```
kubectl delete backup <backup_name> -n my-app-namespace
```

Überprüfen Sie den Status eines Sicherungsvorgangs

Sie können die Befehlszeile verwenden, um den Status eines laufenden, abgeschlossenen oder fehlgeschlagenen Sicherungsvorgangs zu überprüfen.

Schritte

Verwenden Sie den folgenden Befehl, um den Status des Sicherungsvorgangs abzurufen und Werte in Bracken durch Informationen aus Ihrer Umgebung zu ersetzen:
```
kubectl get backup -n <namespace_name> <my_backup_cr_name> -o jsonpath='{.status}'
```

Backup und Restore für Azure-NetApp-Files (ANF)-Vorgänge

Falls Sie Trident Protect installiert haben, können Sie die platzsparenden Backup- und Restore-Funktionen für Storage-Back-Ends aktivieren, die die Azure-NetApp-Files Storage-Klasse verwenden und vor Trident 24.06 erstellt wurden. Diese Funktion arbeitet mit NFSv4-Volumes zusammen und verbraucht keinen zusätzlichen Speicherplatz aus dem Kapazitäts-Pool.

Bevor Sie beginnen

Stellen Sie Folgendes sicher:

Sie haben Trident Protect installiert.
Sie haben eine Anwendung in Trident Protect definiert. Diese Anwendung verfügt nur über begrenzte Schutzfunktionen, bis Sie diesen Vorgang abgeschlossen haben.
Sie haben azure-netapp-files als Standard-Storage-Klasse für Ihr Storage-Back-End ausgewählt.

Erweitern Sie für Konfigurationsschritte

Gehen Sie in Trident folgendermaßen vor, wenn das ANF-Volume vor dem Upgrade auf Trident 24.10 erstellt wurde:
1. Aktivieren Sie das Snapshot-Verzeichnis für jedes PV, das auf Azure-NetApp-Dateien basiert und der Anwendung zugeordnet ist:
  tridentctl update volume <pv name> --snapshot-dir=true -n trident
2. Vergewissern Sie sich, dass das Snapshot-Verzeichnis für jedes zugeordnete PV aktiviert wurde:
  tridentctl get volume <pv name> -n trident -o yaml | grep snapshotDir
  Antwort:
```
snapshotDirectory: "true"
```
+
Wenn das Snapshot-Verzeichnis nicht aktiviert ist, wählt Trident Protect die regelmäßige Backup-Funktion aus, die während des Backup-Prozesses vorübergehend Speicherplatz im Kapazitäts-Pool verbraucht. Stellen Sie in diesem Fall sicher, dass im Kapazitätspool ausreichend Speicherplatz verfügbar ist, um ein temporäres Volume der Größe des zu sichernden Volumes zu erstellen.

Ergebnis

Die Applikation ist mit Trident Protect für die Sicherung und Wiederherstellung bereit. Jede PVC kann auch von anderen Anwendungen für Backups und Wiederherstellungen verwendet werden.

Sicherung von Applikationen mit Trident Protect

Creating your file...

Erstellen Sie einen On-Demand Snapshot

Erstellen Sie ein On-Demand-Backup

Erstellen Sie einen Zeitplan für die Datensicherung

Löschen Sie einen Snapshot

Löschen Sie ein Backup

Überprüfen Sie den Status eines Sicherungsvorgangs

Backup und Restore für Azure-NetApp-Files (ANF)-Vorgänge