Skip to main content

Protect applications using Trident protect

Contributors netapp-mwallis netapp-aruldeepa

You can protect all apps managed by Trident protect by taking snapshots and backups using an automated protection policy or on an ad-hoc basis.

Note You can configure Trident protect to freeze and unfreeze filesystems during data protection operations. Learn more about configuring filesystem freezing with Trident protect.

Create an on-demand snapshot

You can create an on-demand snapshot at any time.

Note Cluster-scoped resources are included in a backup, snapshot, or clone if they are explicitly referenced in the application definition or if they have references to any of the application namespaces.
Steps
  1. Create the custom resource (CR) file and name it trident-protect-snapshot-cr.yaml.

  2. In the file you created, configure the following attributes:

    • metadata.name: (Required) The name of this custom resource; choose a unique and sensible name for your environment.

    • spec.applicationRef: The Kubernetes name of the application to snapshot.

    • spec.appVaultRef: (Required) The name of the AppVault where the snapshot contents (metadata) should be stored.

    • spec.reclaimPolicy: (Optional) Defines what happens to the AppArchive of a snapshot when the snapshot CR is deleted. This means that even when set to Retain, the snapshot will be deleted. Valid options:

      • Retain (default)

      • 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
        YAML
  3. After you populate the trident-protect-snapshot-cr.yaml file with the correct values, apply the CR:

    kubectl apply -f trident-protect-snapshot-cr.yaml
    Console

Create an on-demand backup

You can back up an app at any time.

Note Cluster-scoped resources are included in a backup, snapshot, or clone if they are explicitly referenced in the application definition or if they have references to any of the application namespaces.
Before you begin

Ensure that the AWS session token expiration is sufficient for any long-running s3 backup operations. If the token expires during the backup operation, the operation can fail.

Steps
  1. Create the custom resource (CR) file and name it trident-protect-backup-cr.yaml.

  2. In the file you created, configure the following attributes:

    • metadata.name: (Required) The name of this custom resource; choose a unique and sensible name for your environment.

    • spec.applicationRef: (Required) The Kubernetes name of the application to back up.

    • spec.appVaultRef: (Required) The name of the AppVault where the backup contents should be stored.

    • spec.dataMover: (Optional) A string indicating which backup tool to use for the backup operation. Possible values (case sensitive):

      • Restic

      • Kopia (default)

    • spec.reclaimPolicy: (Optional) Defines what happens to a backup when released from its claim. Possible values:

      • Delete

      • Retain (default)

    • Spec.snapshotRef: (Optional): Name of the snapshot to use as the source of the backup. If not provided, a temporary snapshot will be created and backed up.

      ---
      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
      YAML
  3. After you populate the trident-protect-backup-cr.yaml file with the correct values, apply the CR:

    kubectl apply -f trident-protect-backup-cr.yaml
    Console

Create a data protection schedule

A protection policy protects an app by creating snapshots, backups, or both at a defined schedule. You can choose to create snapshots and backups hourly, daily, weekly, and monthly, and you can specify the number of copies to retain.

Note Cluster-scoped resources are included in a backup, snapshot, or clone if they are explicitly referenced in the application definition or if they have references to any of the application namespaces.
Before you begin

Ensure that the AWS session token expiration is sufficient for any long-running s3 backup operations. If the token expires during the backup operation, the operation can fail.

Steps
  1. Create the custom resource (CR) file and name it trident-protect-schedule-cr.yaml.

  2. In the file you created, configure the following attributes:

    • metadata.name: (Required) The name of this custom resource; choose a unique and sensible name for your environment.

    • spec.dataMover: (Optional) A string indicating which backup tool to use for the backup operation. Possible values (case sensitive):

      • Restic

      • Kopia (default)

    • spec.applicationRef: The Kubernetes name of the application to back up.

    • spec.appVaultRef: (Required) The name of the AppVault where the backup contents should be stored.

    • spec.backupRetention: The number of backups to retain. Zero indicates that no backups should be created.

    • spec.snapshotRetention: The number of snapshots to retain. Zero indicates that no snapshots should be created.

    • spec.granularity: The frequency at which the schedule should run. Possible values, along with required associated fields:

      • hourly (requires that you specify spec.minute)

      • daily (requires that you specify spec.minute and spec.hour)

      • weekly (requires that you specify spec.minute, spec.hour, and spec.dayOfWeek)

      • monthly (requires that you specify spec.minute, spec.hour, and spec.dayOfMonth)

    • spec.dayOfMonth: (Optional) The day of the month (1 - 31) that the schedule should run. This field is required if the granularity is set to monthly.

    • spec.dayOfWeek: (Optional) The day of the week (0 - 7) that the schedule should run. Values of 0 or 7 indicate Sunday. This field is required if the granularity is set to weekly.

    • spec.hour: (Optional) The hour of the day (0 - 23) that the schedule should run. This field is required if the granularity is set to daily, weekly, or monthly.

    • spec.minute: (Optional) The minute of the hour (0 - 59) that the schedule should run. This field is required if the granularity is set to hourly, daily, weekly, or monthly.

      ---
      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: <monthly>
        dayOfMonth: "1"
        dayOfWeek: "0"
        hour: "0"
        minute: "0"
      YAML
  3. After you populate the trident-protect-schedule-cr.yaml file with the correct values, apply the CR:

    kubectl apply -f trident-protect-schedule-cr.yaml
    Console

Delete a snapshot

Delete the scheduled or on-demand snapshots that you no longer need.

Steps
  1. Remove the snapshot CR associated with the snapshot:

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

Delete a backup

Delete the scheduled or on-demand backups that you no longer need.

Steps
  1. Remove the backup CR associated with the backup:

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

Check the status of a backup operation

You can use the command line to check the status of a backup operation that is in progress, has completed, or has failed.

Steps
  1. Use the following command to retrieve status of the backup operation, replacing values in brackes with information from your environment:

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

Enable backup and restore for azure-netapp-files (ANF) operations

If you have installed Trident protect, you can enable space-efficient backup and restore functionality for storage backends that use the azure-netapp-files storage class and were created prior to Trident 24.06. This funtionality works with NFSv4 volumes and does not consume additional space from the capacity pool.

Before you begin

Ensure the following:

  • You have installed Trident protect.

  • You have defined an application in Trident protect. This application will have limited protection functionality until you complete this procedure.

  • You have azure-netapp-files selected as the default storage class for your storage backend.

Expand for configuration steps
  1. Do the following in Trident if the ANF volume was created prior to upgrading to Trident 24.10:

    1. Enable the snapshot directory for each PV that is azure-netapp-files based and associated with the application:

      tridentctl update volume <pv name> --snapshot-dir=true -n trident
      Console
    2. Confirm that the snapshot directory has been enabled for each associated PV:

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

      Response:

      snapshotDirectory: "true"

      When the snapshot directory is not enabled, Trident protect chooses the regular backup functionality, which temporarily consumes space in the capacity pool during the backup process. In this case, ensure that sufficient space is available in the capacity pool to create a temporary volume of the size of the volume being backed up.

Result

The application is ready for backup and restore using Trident protect. Each PVC is also available to be used by other applications for backups and restores.