Skip to main content
La versione in lingua italiana fornita proviene da una traduzione automatica. Per eventuali incoerenze, fare riferimento alla versione in lingua inglese.

Proteggi le applicazioni utilizzando Trident Protect

Collaboratori netapp-mwallis netapp-shwetav netapp-aruldeepa Copilot
PDF

È possibile proteggere tutte le app gestite da Trident Protect eseguendo snapshot e backup tramite una policy di protezione automatizzata o su base ad hoc.

Nota È possibile configurare Trident Protect in modo che blocchi e sblocchi i file system durante le operazioni di protezione dei dati. "Scopri di più sulla configurazione del congelamento del file system con Trident Protect".

Crea un'istantanea on-demand

Puoi creare uno snapshot on-demand in qualsiasi momento.

Nota Le risorse soggette a ambito cluster sono incluse in un backup, in uno snapshot o in un clone, se fanno riferimento esplicitamente nella definizione dell'applicazione o se hanno riferimenti a uno qualsiasi dei namespace delle applicazioni.
Creare un'istantanea utilizzando una CR
Fasi

  1. Creare il file di risorse personalizzate (CR) e assegnargli un nome trident-protect-snapshot-cr.yaml.

  2. Nel file creato, configurare i seguenti attributi:

    • metadata.name: (required) il nome di questa risorsa personalizzata; scegliere un nome univoco e sensibile per il proprio ambiente.

    • Spec.applicationRef: Il nome Kubernetes dell'applicazione da snapshot.

    • Spec.appVaultRef: (required) il nome dell'AppVault in cui devono essere memorizzati i contenuti (metadati) dello snapshot.

    • Spec.reclaimPolicy: (Optional) definisce cosa accade all'AppArchive di uno snapshot quando lo snapshot CR viene eliminato. Ciò significa che anche se impostato su Retain, l'istantanea verrà eliminata. Opzioni valide:

      • Retain (impostazione predefinita)

      • 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

  3. Dopo aver popolato il trident-protect-snapshot-cr.yaml file con i valori corretti, applicare la CR:

    kubectl apply -f trident-protect-snapshot-cr.yaml
Creare una snapshot utilizzando la CLI
Fasi

  1. Creare l'istantanea, sostituendo i valori tra parentesi con le informazioni dell'ambiente. Ad esempio:

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

Crea un backup su richiesta

Puoi eseguire il backup di un'app in qualsiasi momento.

Nota Le risorse soggette a ambito cluster sono incluse in un backup, in uno snapshot o in un clone, se fanno riferimento esplicitamente nella definizione dell'applicazione o se hanno riferimenti a uno qualsiasi dei namespace delle applicazioni.
Prima di iniziare

Assicurati che la scadenza del token di sessione AWS sia sufficiente per eventuali operazioni di backup S3 a esecuzione prolungata. Se il token scade durante l'operazione di backup, l'operazione potrebbe non riuscire.

Creare un backup utilizzando una CR
Fasi

  1. Creare il file di risorse personalizzate (CR) e assegnargli un nome trident-protect-backup-cr.yaml.

  2. Nel file creato, configurare i seguenti attributi:

    • metadata.name: (required) il nome di questa risorsa personalizzata; scegliere un nome univoco e sensibile per il proprio ambiente.

    • Spec.applicationRef: (required) il nome Kubernetes dell'applicazione di cui eseguire il backup.

    • Spec.appVaultRef: (required) il nome dell'AppVault in cui devono essere memorizzati i contenuti di backup.

    • Spec.dataMover: (Optional) stringa che indica quale strumento di backup utilizzare per l'operazione di backup. Valori possibili (distinzione tra maiuscole e minuscole):

      • Restic

      • Kopia (impostazione predefinita)

    • Spec.reclaimPolicy: (Optional) definisce cosa accade a un backup quando viene rilasciato dalla relativa dichiarazione. Valori possibili:

      • Delete

      • Retain (impostazione predefinita)

    • spec.snapshotRef: (Facoltativo): Nome dello snapshot da utilizzare come origine del backup. Se non viene fornito, verrà creato e eseguito il backup di uno snapshot temporaneo.

      Esempio YAML:

    ---
apiVersion: protect.trident.netapp.io/v1
kind: Backup
metadata:
  namespace: my-app-namespace
  name: my-cr-name
spec:
  applicationRef: my-application
  appVaultRef: appvault-name
  dataMover: Kopia

  3. Dopo aver popolato il trident-protect-backup-cr.yaml file con i valori corretti, applicare la CR:

    kubectl apply -f trident-protect-backup-cr.yaml
Creare un backup utilizzando l'interfaccia CLI
Fasi

  1. Creare il backup, sostituendo i valori tra parentesi con le informazioni provenienti dall'ambiente. Ad esempio:

    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>

    È possibile utilizzare il --full-backup flag per specificare se un backup deve essere non incrementale. Per impostazione predefinita, tutti i backup sono incrementali. Quando si utilizza questo indicatore, il backup diventa non incrementale. È consigliabile eseguire periodicamente un backup completo, quindi eseguire backup incrementali tra un backup completo e l'altro, in modo da ridurre al minimo il rischio associato ai ripristini.

Annotazioni di backup supportate

Nella tabella seguente vengono descritte le annotazioni che è possibile utilizzare durante la creazione di un CR di backup:

Annotazione Tipo Descrizione Valore predefinito

protect.trident.netapp.io/full-backup

stringa

Specifica se un backup deve essere non incrementale. Impostato su true per creare un backup non incrementale. È consigliabile eseguire periodicamente un backup completo e poi eseguire backup incrementali tra un backup completo e l'altro, per ridurre al minimo i rischi associati ai ripristini.

"falso"

protect.trident.netapp.io/snapshot-completion-timeout

stringa

Tempo massimo consentito per il completamento dell'intera operazione di snapshot.

"60 metri"

protect.trident.netapp.io/volume-snapshots-ready-to-use-timeout

stringa

Tempo massimo consentito affinché gli snapshot del volume raggiungano lo stato pronto all'uso.

"30 metri"

protect.trident.netapp.io/volume-snapshots-created-timeout

stringa

Tempo massimo consentito per la creazione di snapshot del volume.

"5m"

protect.trident.netapp.io/pvc-bind-timeout-sec

stringa

Tempo massimo (in secondi) di attesa affinché i nuovi PersistentVolumeClaim (PVC) creati raggiungano il Bound fase prima del fallimento delle operazioni.

"1200" (20 minuti)

Creare un piano di data Protection

Una policy di protezione protegge un'app creando snapshot, backup o entrambi secondo una pianificazione definita. È possibile scegliere di creare snapshot e backup orari, giornalieri, settimanali e mensili e specificare il numero di copie da conservare. È possibile pianificare un backup completo non incrementale utilizzando l'annotazione full-backup-rule. Per impostazione predefinita, tutti i backup sono incrementali. L'esecuzione periodica di un backup completo, insieme a backup incrementali intermedi, aiuta a ridurre il rischio associato ai ripristini.

Nota

  • È possibile creare pianificazioni solo per gli snapshot impostando backupRetention a zero e snapshotRetention a un valore maggiore di zero. Collocamento snapshotRetention a zero significa che tutti i backup pianificati creeranno comunque degli snapshot, ma questi saranno temporanei e verranno eliminati immediatamente dopo il completamento del backup.

  • Le risorse soggette a ambito cluster sono incluse in un backup, in uno snapshot o in un clone, se fanno riferimento esplicitamente nella definizione dell'applicazione o se hanno riferimenti a uno qualsiasi dei namespace delle applicazioni.
Creare una pianificazione utilizzando una CR
Fasi

  1. Creare il file di risorse personalizzate (CR) e assegnargli un nome trident-protect-schedule-cr.yaml.

  2. Nel file creato, configurare i seguenti attributi:

    • metadata.name: (required) il nome di questa risorsa personalizzata; scegliere un nome univoco e sensibile per il proprio ambiente.

    • Spec.dataMover: (Optional) stringa che indica quale strumento di backup utilizzare per l'operazione di backup. Valori possibili (distinzione tra maiuscole e minuscole):

      • Restic

      • Kopia (impostazione predefinita)

    • Spec.applicationRef: Il nome Kubernetes dell'applicazione di cui eseguire il backup.

    • Spec.appVaultRef: (required) il nome dell'AppVault in cui devono essere memorizzati i contenuti di backup.

    • spec.backupRetention: (Obbligatorio) Numero di backup da conservare. Zero indica che non devono essere creati backup (solo snapshot).

    • spec.backupReclaimPolicy: (Facoltativo) Determina cosa succede a un backup se il CR di backup viene eliminato durante il periodo di conservazione. Dopo il periodo di conservazione, i backup vengono sempre eliminati. Valori possibili (con distinzione tra maiuscole e minuscole):

      • Retain (impostazione predefinita)

      • Delete

    • spec.snapshotRetention: (Obbligatorio) Numero di snapshot da conservare. Zero indica che non devono essere creati snapshot.

    • spec.snapshotReclaimPolicy: (Facoltativo) Determina cosa succede a uno snapshot se il CR dello snapshot viene eliminato durante il periodo di conservazione. Dopo il periodo di conservazione, gli snapshot vengono sempre eliminati. Valori possibili (con distinzione tra maiuscole e minuscole):

      • Retain

      • Delete(predefinito)

    • spec.granularity: frequenza di esecuzione della pianificazione. Valori possibili, insieme ai campi associati obbligatori:

      • Hourly(richiede che tu specifichi spec.minute )

      • Daily(richiede che tu specifichi spec.minute E spec.hour )

      • Weekly(richiede che tu specifichi spec.minute, spec.hour , E spec.dayOfWeek )

      • Monthly(richiede che tu specifichi spec.minute, spec.hour , E spec.dayOfMonth )

      • Custom

    • spec.dayOfMonth: (Facoltativo) Il giorno del mese (1 - 31) in cui la pianificazione deve essere eseguita. Questo campo è obbligatorio se la granularità è impostata su Monthly . Il valore deve essere fornito come stringa.

    • spec.dayOfWeek: (Facoltativo) Il giorno della settimana (0 - 7) in cui deve essere eseguita la pianificazione. I valori 0 o 7 indicano domenica. Questo campo è obbligatorio se la granularità è impostata su Weekly . Il valore deve essere fornito come stringa.

    • spec.hour: (Facoltativo) L'ora del giorno (0 - 23) in cui la pianificazione deve essere eseguita. Questo campo è obbligatorio se la granularità è impostata su Daily , Weekly , O Monthly . Il valore deve essere fornito come stringa.

    • spec.minute: (Facoltativo) Il minuto dell'ora (0 - 59) in cui la pianificazione deve essere eseguita. Questo campo è obbligatorio se la granularità è impostata su Hourly , Daily , Weekly , O Monthly . Il valore deve essere fornito come stringa.

      Esempio di YAML per la pianificazione di backup e snapshot:

      ---
apiVersion: protect.trident.netapp.io/v1
kind: Schedule
metadata:
  namespace: my-app-namespace
  name: my-cr-name
spec:
  dataMover: Kopia
  applicationRef: my-application
  appVaultRef: appvault-name
  backupRetention: "15"
  snapshotRetention: "15"
  granularity: Daily
  hour: "0"
  minute: "0"

      Esempio di YAML per la pianificazione solo snapshot:

    ---
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"

  3. Dopo aver popolato il trident-protect-schedule-cr.yaml file con i valori corretti, applicare la CR:

    kubectl apply -f trident-protect-schedule-cr.yaml
Creare una pianificazione utilizzando l'interfaccia CLI
Fasi

  1. Creare il programma di protezione, sostituendo i valori tra parentesi con le informazioni provenienti dall'ambiente. Ad esempio:

    Nota È possibile utilizzare tridentctl-protect create schedule --help per visualizzare informazioni dettagliate sulla guida per questo comando. 
    tridentctl-protect create schedule <my_schedule_name> \
  --appvault <my_appvault_name> \
  --app <name_of_app_to_snapshot> \
  --backup-retention <how_many_backups_to_retain> \
  --backup-reclaim-policy <Retain|Delete (default Retain)> \
  --data-mover <Kopia_or_Restic> \
  --day-of-month <day_of_month_to_run_schedule> \
  --day-of-week <day_of_week_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> \
  --snapshot-reclaim-policy <Retain|Delete (default Delete)> \
  --full-backup-rule <string> \
  -n <application_namespace>

    Puoi impostare l' --full-backup-rule`indicatore su `always per un backup completo costante o personalizzarlo in base ai tuoi requisiti. Ad esempio, se si sceglie la granularità giornaliera, è possibile specificare i giorni feriali in cui deve essere eseguito il backup completo. Ad esempio, utilizzare --full-backup-rule "Monday,Thursday" per pianificare il backup completo il lunedì e il giovedì.

    Per pianificazioni solo snapshot, impostare --backup-retention 0 e specificare un valore maggiore di 0 per --snapshot-retention .

Annotazioni di pianificazione supportate

Nella tabella seguente vengono descritte le annotazioni che è possibile utilizzare durante la creazione di una CR di pianificazione:

Annotazione Tipo Descrizione Valore predefinito

protect.trident.netapp.io/full-backup-rule

stringa

Specifica la regola per la pianificazione dei backup completi. Puoi impostarlo su always per un backup completo costante o personalizzarlo in base alle tue esigenze. Ad esempio, se si sceglie la granularità giornaliera, è possibile specificare i giorni feriali in cui deve essere eseguito il backup completo (ad esempio, "Monday,Thursday" ).

Non impostato (tutti i backup sono incrementali)

protect.trident.netapp.io/snapshot-completion-timeout

stringa

Tempo massimo consentito per il completamento dell'intera operazione di snapshot.

"60 metri"

protect.trident.netapp.io/volume-snapshots-ready-to-use-timeout

stringa

Tempo massimo consentito affinché gli snapshot del volume raggiungano lo stato pronto all'uso.

"30 metri"

protect.trident.netapp.io/volume-snapshots-created-timeout

stringa

Tempo massimo consentito per la creazione di snapshot del volume.

"5m"

protect.trident.netapp.io/pvc-bind-timeout-sec

stringa

Tempo massimo (in secondi) di attesa affinché i nuovi PersistentVolumeClaim (PVC) creati raggiungano il Bound fase prima del fallimento delle operazioni.

"1200" (20 minuti)

Eliminare uno snapshot

Eliminare le snapshot pianificate o on-demand non più necessarie.

Fasi

  1. Rimuovere l'istantanea CR associata all'istantanea:

    kubectl delete snapshot <snapshot_name> -n my-app-namespace

Eliminare un backup

Eliminare i backup pianificati o on-demand non più necessari.

Nota Assicurati che la politica di recupero sia impostata su Delete per rimuovere tutti i dati di backup dall'archiviazione degli oggetti. L'impostazione predefinita del criterio è Retain per evitare la perdita accidentale di dati. Se la politica non viene modificata in Delete , i dati di backup rimarranno nell'archivio oggetti e richiederanno l'eliminazione manuale.
Fasi

  1. Rimuovere il CR di backup associato al backup:

    kubectl delete backup <backup_name> -n my-app-namespace

Controllare lo stato di un'operazione di backup

È possibile utilizzare la riga di comando per verificare lo stato di un'operazione di backup in corso, completata o non riuscita.

Fasi

  1. Utilizzare il seguente comando per recuperare lo stato dell'operazione di backup, sostituendo i valori nei brackes con le informazioni dal proprio ambiente:

    kubectl get backup -n <namespace_name> <my_backup_cr_name> -o jsonpath='{.status}'

Abilitare backup e ripristino per operazioni Azure-NetApp-Files (ANF)

Se hai installato Trident Protect, puoi abilitare la funzionalità di backup e ripristino a basso consumo di spazio per i backend di archiviazione che utilizzano la classe di archiviazione azure-netapp-files e sono stati creati prima di Trident 24.06. Questa funzionalità funziona con volumi NFSv4 e non consuma spazio aggiuntivo dal pool di capacità.

Prima di iniziare

Verificare quanto segue:

  • Hai installato Trident Protect.

  • Hai definito un'applicazione in Trident Protect. Questa applicazione avrà funzionalità di protezione limitate finché non avrai completato questa procedura.

  • È stata azure-netapp-files selezionata come classe di archiviazione predefinita per il backend di archiviazione.

Espandere per la procedura di configurazione

  1. Se il volume ANF è stato creato prima dell'aggiornamento a Trident 24,10, procedere come segue in Trident:

    1. Abilitare la directory snapshot per ogni PV basata su file Azure-NetApp e associata all'applicazione:

      tridentctl update volume <pv name> --snapshot-dir=true -n trident

    2. Confermare che la directory snapshot è stata abilitata per ogni PV associato:

      tridentctl get volume <pv name> -n trident -o yaml | grep snapshotDir

      Risposta:

    snapshotDirectory: "true"

    +
    Quando la directory degli snapshot non è abilitata, Trident Protect sceglie la funzionalità di backup normale, che consuma temporaneamente spazio nel pool di capacità durante il processo di backup. In questo caso, assicurarsi che nel pool di capacità sia disponibile spazio sufficiente per creare un volume temporaneo delle dimensioni del volume sottoposto a backup.

Risultato

L'applicazione è pronta per il backup e il ripristino tramite Trident Protect. Ogni PVC può essere utilizzato anche da altre applicazioni per backup e ripristini.