NetApp
Feature Request: Allow custom naming of ONTAP snapshots via TridentSnapshot CRD
Description
Currently, when snapshots are created using Kubernetes backup tools such as Velero, Trident Protect, or others, the resulting ONTAP snapshot names follow a fixed format like snapshot-xxxxxxxxxxxxxxx. This naming convention prevents integration with NetApp tools such as BlueXP, which rely on snapshot name patterns (e.g., daily.xxx, monthly.xxx) to apply replication and retention policies as part of a 3-2-1 backup strategy.
Without meaningful snapshot names, these policies cannot be applied, limiting the usefulness of ONTAP’s native data protection features.
Proposed Feature
Introduce support for custom snapshot naming in Trident, ideally through an extension of the TridentSnapshot CRD (tridentsnapshots.trident.netapp.io). This could include:
- A new field to specify the desired snapshot name.
- Validation to ensure name compatibility with ONTAP.
- Optional templating support to dynamically generate names based on schedule type, PVC name, timestamp, etc.
This would align well with existing functionality in Trident Protect, where snapshot schedules already define granularity (e.g., hourly, daily, weekly).
Benefits
- Enables integration with NetApp BlueXP and other ONTAP-native tools
- Supports automated replication and retention policies
- Improves visibility and traceability of snapshots
- Aligns snapshot naming with organizational backup strategies
Environment
- Trident version: 25.02.1
- Kubernetes version: 1.32
- ONTAP version: 9.16.1P4
Additional Context
This feature would be especially valuable in enterprise environments with strict backup and disaster recovery policies. Let me know if a configuration example or use case diagram would help clarify the request.
This enhancement would significantly improve alignment with enterprise backup strategies, especially in environments governed by strict disaster recovery policies. It would also enable better visibility, traceability, and automation of data protection workflows.
Could you please let me know if this feature is currently being considered or added to the roadmap? If any additional context or configuration examples would help clarify the use case, I’d be happy to provide them.
Looking forward to your feedback.
Hello, @ecthelion77. I assume you mean the name of the snapshot on the storage system, since you already have control of the VolumeSnapshot name and CSI sets the name of the VolumeSnapshotContent. So my first question is how the snapshot name would be communicated to Trident; using the TridentSnapshot CRD isn't appropriate as that is not an input to Trident but is instead Trident's internal record of the snapshot. Perhaps an annotation on the VolumeSnapshot? And other tools like Trident Protect would have to be modified to set that, no? I know that Trident Protect is working on a 3-2-1 backup strategy, and they haven't asked us for this (yet). The short answer is no, this isn't currently on the roadmap. We're not opposed to adding such a feature, but we would need more info about how it would be consumed, and as a non-trivial effort it would have to be prioritized with everything else. For more attention, I suggest you follow up with a formal request to NetApp support and/or your NetApp account team.
Thank you for your reply and for clarifying the distinction between Trident’s internal CRDs and Kubernetes VolumeSnapshot objects. Let me reframe the request more precisely:
The issue is not with the Kubernetes VolumeSnapshot resource or its associated VolumeSnapshotContent, but with the actual ONTAP snapshot created on the storage array. Today, Trident generates snapshots with generic names such as snapshot-xxxxxxxxxxxxxxx. These names are not meaningful to ONTAP-native tools (e.g., BlueXP), which apply replication and retention policies based on snapshot name patterns (e.g., daily.xxx, weekly.xxx).
The result is that, while CSI-based snapshots can be created successfully, they cannot participate in ONTAP’s native data protection workflows. For example, in a 3-2-1 backup strategy managed by BlueXP, snapshots without recognizable names are excluded from retention and replication policies.
The proposal would therefore be to introduce a mechanism allowing Trident to set a custom snapshot name at the ONTAP level. Possible approaches could include:
An annotation on the VolumeSnapshot to pass a desired snapshot name to Trident.
A templating mechanism to construct names dynamically (e.g., {pvc}-{schedule}-{timestamp}).
Validation to ensure the requested name is compatible with ONTAP naming rules.
This would allow tools like Velero or Trident Protect to trigger CSI/Trident snapshots while ensuring that the resulting ONTAP snapshots integrate seamlessly with BlueXP policies.