hesela.devZFS snapshot hold
A ZFS snapshot hold is a named user reference that blocks ordinary destruction of a snapshot while the hold remains.
Hold lifecycle: each snapshot has its own tag namespace. zfs holds lists its references, userrefs counts them, and zfs release removes a specified tag. A hold causes ordinary destruction to fail with EBUSY. [1] [2]
Pending deletion: zfs destroy -d can mark a held or cloned snapshot for automatic removal once eligible. The snapshot remains visible while marked; inspect defer_destroy as well as holds and clone dependencies before releasing protection. [3]
Protection scope: a releasable hold is not immutable retention against an actor authorized to release it, nor a copy outside the source pool. This is a scope inference from the documented operations. [1] [4]
Release boundary: releasing the final user hold can destroy a snapshot already marked for deletion when no clones remain. A new hold delays eligibility but does not cancel the request; inspect defer_destroy before changing references. The release permission is itself documented as potentially destructive. [5] [3]
Relations
- related
- Storage snapshot, ZFS dataset clone, ZFS bookmark, Storage immutability, Backup, ZFS deferred snapshot destruction
Citations
- OpenZFS v2.3: zfs-hold(8), named holds and release
- OpenZFS v2.3: zfsprops(7), origin, clones, userrefs and defer_destroy
- OpenZFS v2.3: zfs-destroy(8), dependent and deferred destruction
- OpenZFS v2.3: zfsconcepts(7), dataset clones and block cloning
- OpenZFS v2.3: zfs-allow(8), release permission may destroy a snapshot
Sources & caveats
- Source review of OpenZFS v2.3 documentation; no pool, promotion or recovery experiment was performed.