Proteggi le applicazioni con Trident Protect
Puoi proteggere tutte le app gestite da Trident Protect creando snapshot e backup con policy di protezione automatizzate o su base ad-hoc.
|
È possibile configurare Trident Protect per bloccare e sbloccare i file system durante le operazioni di protezione dei dati. "Ulteriori informazioni sulla configurazione del blocco del filesystem con Trident Protect". |
Crea un'istantanea on-demand
Puoi creare uno snapshot on-demand in qualsiasi momento.
|
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 il file di risorse personalizzate (CR) e assegnargli un nome
trident-protect-snapshot-cr.yaml
. -
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
-
-
-
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 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.
|
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. |
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.
-
Per ulteriori informazioni sulla verifica della scadenza corrente del token di sessione, fare riferimento "Documentazione di API AWS" al .
-
Per ulteriori informazioni sulle credenziali con le risorse AWS, fare riferimento al "Documentazione di AWS IAM".
-
Creare il file di risorse personalizzate (CR) e assegnargli un nome
trident-protect-backup-cr.yaml
. -
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.
-
metadata.annotations.protect.trident.netapp.io/full-backup : (Facoltativo) Questa annotazione viene utilizzata per specificare se un backup deve essere non incrementale. Per impostazione predefinita, tutti i backup sono incrementali. Tuttavia, se questa annotazione è impostata su
true
, il backup diventa non incrementale. Se non specificato, il backup segue l'impostazione di backup incrementale predefinita. È 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.Esempio 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
-
-
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 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.
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.
|
|
-
Creare il file di risorse personalizzate (CR) e assegnargli un nome
trident-protect-schedule-cr.yaml
. -
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: Numero di backup da conservare. Zero indica che non devono essere creati backup (solo snapshot).
-
Spec.snapshotRetention: Il numero di snapshot da conservare. Zero indica che non è necessario creare snapshot.
-
spec.granularity: frequenza di esecuzione della pianificazione. Valori possibili, insieme ai campi associati obbligatori:
-
Hourly
(richiede che tu specifichispec.minute
) -
Daily
(richiede che tu specifichispec.minute
Espec.hour
) -
Weekly
(richiede che tu specifichispec.minute, spec.hour
, Espec.dayOfWeek
) -
Monthly
(richiede che tu specifichispec.minute, spec.hour
, Espec.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
, OMonthly
. 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
, OMonthly
. Il valore deve essere fornito come stringa. -
metadata.annotations.protect.trident.netapp.io/full-backup-rule: (Optional) questa annotazione viene utilizzata per specificare la regola per la pianificazione del backup completo. Puoi impostarlo 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.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 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"
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"
-
-
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 il programma di protezione, sostituendo i valori tra parentesi con le informazioni provenienti dall'ambiente. Ad esempio:
È 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> --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>
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
.
Eliminare uno snapshot
Eliminare le snapshot pianificate o on-demand non più necessarie.
-
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.
|
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.
|
-
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.
-
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 è stato installato Trident Protect, è possibile abilitare una funzionalità di backup e ripristino efficiente in termini di spazio per backend di storage che utilizzano la classe di storage Azure-NetApp-Files e che sono stati creati prima di Trident 24,06. Questa funzionalità funziona con volumi NFSv4 e non occupa spazio aggiuntivo dal pool di capacità.
Verificare quanto segue:
-
Trident Protect è stato installato.
-
È stata definita un'applicazione in Trident Protect. Questa applicazione dispone di funzionalità di protezione limitate fino al completamento di questa procedura.
-
È stata
azure-netapp-files
selezionata come classe di archiviazione predefinita per il backend di archiviazione.
Espandere per la procedura di configurazione
-
Se il volume ANF è stato creato prima dell'aggiornamento a Trident 24,10, procedere come segue in Trident:
-
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
-
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 snapshot non è abilitata, Trident Protect sceglie la normale funzionalità di backup, che consuma temporaneamente spazio nel pool di capacità durante il processo di backup. In questo caso, verificare che nel pool di capacità sia disponibile spazio sufficiente per creare un volume temporaneo delle dimensioni del volume di cui si desidera eseguire il backup. -
L'applicazione è pronta per il backup e il ripristino utilizzando Trident Protect. Ciascun PVC è inoltre disponibile per essere utilizzato da altre applicazioni per backup e ripristini.