Problem / Justification
When using recursive ZFS replication for disaster recovery, deleting a child dataset on the source does not remove the corresponding replicated child dataset on the destination. Snapshot retention policies such as “Same as Source” do not solve this, so stale datasets can remain indefinitely and consume significant backup capacity.
This makes the destination dataset hierarchy diverge from the source and requires administrators to periodically compare both sides and manually remove orphaned replicated datasets.
Proposed functionality
Add an optional setting to replication tasks such as:
“Prune destination datasets removed from source”
The option should be disabled by default and could provide:
-
configurable grace period, e.g. 7/14/30 days
-
pruning only after a successful replication
-
no pruning if the source pool/dataset is unavailable
-
preview/dry-run showing datasets that would be removed
-
protection against mass deletion
-
pruning strictly limited to the configured replication destination subtree
-
logging/audit trail of deleted datasets
Impact
This would improve storage efficiency and reliability of long-running recursive replication tasks, particularly for disaster-recovery environments with frequently created and removed datasets, VMs, applications, or project datasets.
User Story
As an administrator maintaining a recursive disaster-recovery replica, when a child dataset is intentionally removed from the source and remains absent beyond a configurable grace period, I want TrueNAS to remove the corresponding replicated child dataset after a successful replication so that the destination accurately reflects the source hierarchy without manual cleanup.