Skip to main content
NetApp Backup and Recovery

Back up Kubernetes applications now using custom resources in Backup and Recovery

Contributors netapp-mwallis
PDFs

NetApp Backup and Recovery enables you to manually back up Kubernetes applications using custom resources (CRs).

Back up a Kubernetes application now using custom resources

Manually create a backup of a Kubernetes application to establish a baseline for future backups and snapshots, or to ensure the most recent data is protected.

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.

Create a local snapshot using a custom resource

To create a snapshot of your Kubernetes application and store it locally, use the Snapshot custom resource with specific attributes.

Steps

  1. Create the custom resource (CR) file and name it local-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: local-snapshot-cr
spec:
  applicationRef: my-application
  appVaultRef: appvault-name
  reclaimPolicy: Retain

  3. After you populate the local-snapshot-cr.yaml file with the correct values, apply the CR:

    kubectl apply -f local-snapshot-cr.yaml

Back up an application to an object store using a custom resource

Create a Backup CR with specific attributes to back up your application to an object store.

Steps

  1. Create the custom resource (CR) file and name it object-store-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, mutually exclusive with spec.appVaultTargetsRef) If you use the same bucket to store the snapshot and backup, this is the name of the AppVault where the backup contents should be stored.

    • spec.appVaultTargetsRef: (Required, mutually exclusive with spec.appVaultRef) If you use different buckets to store the snapshot and backup, this is the name of the AppVault where the backup contents should be stored.

    • spec.dataMover: (Optional, required for clusters migrated from Trident Protect) A string indicating which backup tool to use for the backup operation. If this cluster has been migrated to Backup and Recovery from Trident Protect, the value is case sensitive and must be CBS.

    • spec.reclaimPolicy: (Optional) Defines what happens to the backup contents (metadata/volume data) when the Backup CR is deleted. Possible values:

      • Delete

      • Retain (default)

    • spec.cleanupSnapshot: (Required) Ensures that the temporary snapshot created by the Backup CR is not deleted after the backup operation completes. Recommended value: false.

      Example YAML when using the same bucket to store the snapshot and backup:

      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: CBS
  reclaimPolicy: Retain
  cleanupSnapshot: false

      Example YAML when using different buckets to store the snapshot and backup:

      apiVersion: protect.trident.netapp.io/v1
kind: Backup
metadata:
  namespace: my-app-namespace
  name: object-store-backup-cr
spec:
  applicationRef: my-application
  appVaultTargetsRef: appvault-targets-name
  dataMover: CBS
  reclaimPolicy: Retain
  cleanupSnapshot: false

  3. After you populate the object-store-backup-cr.yaml file with the correct values, apply the CR:

    kubectl apply -f object-store-backup-cr.yaml

Create a 3-2-1 fanout backup using a custom resource

Backing up using a 3-2-1 fanout architecture copies a backup to secondary storage as well as to an object store. To create a 3-2-1 fanout backup, create a Backup CR with specific attributes.

Steps

  1. Create the custom resource (CR) file and name it 3-2-1-fanout-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.appVaultTargetsRef: (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. The value is case sensitive and must be CBS.

    • spec.reclaimPolicy: (Optional) Defines what happens to the backup contents (metadata/volume data) when the Backup CR is deleted. Possible values:

      • Delete

      • Retain (default)

    • spec.cleanupSnapshot: (Required) Ensures that the temporary snapshot created by the Backup CR is not deleted after the backup operation completes. Recommended value: false.

    • spec.replicateSnapshot: (Required) Instructs Backup and Recovery to replicate the snapshot to secondary storage. Required value: true.

    • spec.replicateSnapshotReclaimPolicy: (Optional) Defines what happens to the replicated snapshot when it is deleted. Possible values:

      • Delete

      • Retain (default)

        Example YAML:

        apiVersion: protect.trident.netapp.io/v1
kind: Backup
metadata:
  namespace: my-app-namespace
  name: 3-2-1-fanout-backup-cr
spec:
  applicationRef: my-application
  appVaultTargetsRef: appvault-targets-name
  dataMover: CBS
  reclaimPolicy: Retain
  cleanupSnapshot: false
  replicateSnapshot: true
  replicateSnapshotReclaimPolicy: Retain

  3. After you populate the 3-2-1-fanout-backup-cr.yaml file with the correct values, apply the CR:

    kubectl apply -f 3-2-1-fanout-backup-cr.yaml

Supported backup annotations

The following table describes the annotations you can use when creating a backup CR.

Annotation Type Description Default value

protect.trident.netapp.io/full-backup

string

Specifies whether a backup should be non-incremental. Set to true to create a non-incremental backup. It is best practice to perform a full backup periodically and then perform incremental backups in between full backups to minimize the risk associated with restores.

"false"

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

string

The maximum time allowed for the overall snapshot operation to complete.

"60m"

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

string

The maximum time allowed for volume snapshots to reach the ready-to-use state.

"30m"

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

string

The maximum time allowed for volume snapshots to be created.

"5m"

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

string

Maximum time (in seconds) to wait for any newly created PersistentVolumeClaims (PVCs) to reach the Bound phase before the operations fails.

"1200" (20 minutes)