Skip to main content
NetApp Backup and Recovery

Use advanced custom resource restore settings

Contributors netapp-mwallis
PDFs

You can customize restore operations using advanced settings such as annotations, namespace settings, and storage options to meet your specific requirements.

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 available for restore operations.

Storage class mapping

The spec.storageClassMapping attribute defines a mapping from a storage class present in the source application to a new storage class on the target cluster. You can use this 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 an annotation is not explicitly set by the user, the system will use the default value.

Annotation Type Description Default value

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

string

The maximum time (in seconds) allowed for data mover operation to be 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 operations 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)