Hold option for snapshots
Description
Problem/Justification
Impact
clones
is cloned by
relates to
Activity

Vladimir Vinogradenko August 12, 2022 at 11:25 AM
it will not affect the replication performance. I’ll double check how we support handling held snapshots deletion (skipping them in batch deletion operations), I remember adding support for that.

Vladimir Vinogradenko April 18, 2022 at 8:57 PM
current UI does not support retrieving metadata for a single snapshot (like on attached screenshot). We either only list names or check "Show extra columns" and retrieve metadata for all snapshots.
Should we ask UI team to get this feature back?
If so, and if we decide to stick with the user's proposed implementation, the following issues arise:
ZFS holds snapshots with tags. Tags are named so we must specify a tag name when holding a snapshot. Should we always use something like "truenas" or should we ask the user?
If user held their snapshot using CLI with a custom tag, should we also remove that tag when clicking "unhold"?
Should we display the list of custom tags under the snapshot hold state?
Holds can be recursive, how do we handle that?
It seems to be that "hold" operation UX is more complicated than just toggling a switch. When user wants to hold a snapshot, we might ask: what will be the hold name? Do you want to hold children too? Same with unhold operation.

Winnie Linnie September 23, 2021 at 2:17 PM
Let me know if there's any feedback or ideas of implementing this. I realize it must integrate into TrueNAS "as a whole".
Details
Details
Assignee

Reporter

The "hold" feature for zfs snapshots is significant enough that it should have its own checkmark. This is especially true for automically generated snapshots created by a Periodic Snapshot task.
Attached is a mock screenshot of what this would look like.