Skip to main content
NetApp Backup and Recovery

Advanced restore settings for Kubernetes in NetApp Backup and Recovery

Contributors netapp-mwallis
PDFs

Use annotations, namespace settings, and storage options to customize Kubernetes restore operations for your environment.

Namespace annotations and labels during restore and failover operations

During restore and failover, destination namespace labels and annotations are updated to match the source: keys from the source are added to or overwrite destination keys, while keys that exist only in the destination are left unchanged.

Note In Red Hat OpenShift, namespace annotations are important because they ensure restored pods receive the correct security context constraints and permissions, enabling them to access volumes and run without permission errors. For more information, refer to the OpenShift security context constraints documentation.

Set the Kubernetes environment variable

RESTORE_SKIP_NAMESPACE_ANNOTATIONS

before restore or failover to prevent specific destination namespace annotations from being overwritten. For example:

helm upgrade trident-protect -n trident-protect netapp-trident-protect/trident-protect \
  --set-string restoreSkipNamespaceAnnotations="{<annotation_key_to_skip_1>,<annotation_key_to_skip_2>}" \
  --reuse-values
Note During restore or failover, any namespace annotations and labels specified in restoreSkipNamespaceAnnotations and restoreSkipNamespaceLabels are excluded from the restore or failover operation. Ensure these settings are configured during the initial Helm installation. To learn more, refer to Configure additional Trident Protect helm chart settings.

If you used Helm with the --create-namespace flag to install the source application, Trident Protect copies the name label to the destination namespace. If the label value matches the source namespace name, it is replaced with the destination namespace name; if not, it is left as-is.

Example

The following example shows source and destination namespaces with different labels and annotations, and displays the destination namespace before and after the operation to illustrate how keys are added, merged, or overwritten.

Before the restore or failover operation

The following table illustrates the state of the example source and destination namespaces before the restore or failover operation:

Namespace Annotations Labels

Namespace ns-1 (source)

  • annotation.one/key: "updatedvalue"

  • annotation.two/key: "true"

  • environment=production

  • compliance=hipaa

  • name=ns-1

Namespace ns-2 (destination)

  • annotation.one/key: "true"

  • annotation.three/key: "false"

  • role=database

After the restore operation

The following table illustrates the state of the example destination namespace after the restore or failover operation. Some keys have been added, some have been overwritten, and the name label has been updated to match the destination namespace:

Namespace Annotations Labels

Namespace ns-2 (destination)

  • annotation.one/key: "updatedvalue"

  • annotation.two/key: "true"

  • annotation.three/key: "false"

  • name=ns-2

  • compliance=hipaa

  • environment=production

  • role=database

Supported fields

This section describes additional fields for restore operations.

Storage class mapping

The spec.storageClassMapping attribute maps a storage class in the source application to a new storage class on the target cluster. Use this field when migrating applications between clusters with different storage classes or when changing the storage backend for BackupRestore operations.

Example:

storageClassMapping:
  - destination: "destinationStorageClass1"
    source: "sourceStorageClass1"
  - destination: "destinationStorageClass2"
    source: "sourceStorageClass2"

Supported annotations

This section lists the supported annotations for configuring various behaviors in the system. If you do not explicitly set an annotation, the system uses the default value.

Annotation Type Description Default value

protect.trident.netapp.io/data-mover-timeout-sec

string

The maximum time, in seconds, that a data mover operation can remain stalled.

"300"

protect.trident.netapp.io/kopia-content-cache-size-limit-mb

string

The maximum size limit (in megabytes) for the Kopia content cache.

"1000"

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 operation fails. Applies to all restore CR types (BackupRestore, BackupInplaceRestore, SnapshotRestore, SnapshotInplaceRestore). Use a higher value if your storage backend or cluster often requires more time.

"1200" (20 minutes)