Grandfather-Father-Son retention sheme for Snapshots

Feature Requests
1

Problem/Justification

The Grandfather-Father-Son (GFS) retention scheme is a foundational backup strategy that balances granular short-term recovery with efficient long-term data protection.

  • Protection Against Delayed Threat Detection: Ransomware, silent bitrot, or unnoticed file deletions often go undetected for weeks. High-frequency short-term backups alone will quickly overwrite clean copies with corrupted ones, whereas GFS guarantees clean recovery points months or years in the past.

  • Storage Efficiency: Keeping every daily snapshot indefinitely exhausts storage capacity. GFS exponentially thins out older snapshots—maintaining hourly/daily precision for immediate rollbacks while preserving only key weekly, monthly, and yearly milestones for the long haul.

Even if zfs snapshots are very space efficient, in case of regularly changing data (DB), many snapshots can take massive amount of space.

This creates significant management overhead and potential points of failure:

  • UI & Task Bloat: Managing 10 datasets with a standard GFS strategy requires 40 distinct snapshot tasks in the GUI.

  • Complex Replication Setup: To replicate these snapshots offsite, replication tasks must be manually configured using complex pattern matching (also_include_naming_schema or regex) to ensure every tier is captured. Missing a schema breaks offsite retention for that tier.

  • Redundant Snapshot Overlaps: When multiple tasks trigger at the same time window (e.g., midnight on the first of the month), the system creates duplicate snapshots under different names unless meticulously scheduled.

Impact

  • Benefits & Advantages:

    • 1 Dataset = 1 Task: Simplifies snapshot management across both UI and CLI/API.

    • Seamless Replication: Target systems automatically inherit multi-tier GFS retention rules when retention_policy: SOURCE is used, eliminating manual schema matching.

    • Enterprise Best Practices Out of the Box: Makes proper long-term backup retention intuitive for both beginners and enterprise administrators.

  • Disadvantages:

    • Requires updates to the web interface, API (pool.snapshottask), and underlying replication scheduler (zettarepl) logic to process multi-tier retention rules per task object.

User Story

  1. A TrueNAS user opens Data Protection > Periodic Snapshot Tasks > Add.

  2. They select a dataset (e.g., SSD/dockerconfig) and check a new Enable GFS Retention option.

  3. They set their desired tiers within the single task interface:

    • Daily: Keep 10 Days

    • Weekly: Keep 7 Weeks

    • Monthly: Keep 6 Months

    • Yearly: Keep 1 Year

  4. The user saves the task. TrueNAS creates a single automated schedule that handles snapshot generation and prunes snapshots according to their respective GFS tier lifetime.

  5. The user creates a Replication Task to a remote server. The replication job automatically syncs all GFS snapshots and applies the exact same retention rules on the destination system without requiring manual naming schema matching.

2

Snapshots aren’t backups — worth separating those concepts here. GFS (grandfather-father-son) is a tape-era backup rotation scheme: full backups plus incrementals, stored on separate media, rotated on a schedule. It’s designed around a distinct copy of data existing independently of the source.

ZFS snapshots are just point-in-time references on the same pool. They protect against “oops I deleted/changed a file” and give you rollback, but if the pool dies, the array fails, or ransomware/hardware corrupts things at a low enough level, your snapshots go with it. They don’t give you an independent copy of your data.

So the retention curve you want (daily/weekly/monthly/yearly, thinning with age) is a reasonable idea — but it’s a snapshot retention policy, not a GFS backup scheme. If the goal is real ransomware/bitrot protection, you still need actual backups (replication to a separate system, or better, an offsite/air-gapped copy) — snapshots alone don’t accomplish that, no matter how you tier the retention.

3

I am aware about the difference.

The problem: my Data is changing often, so snapshots cannot be made for half a year daily, so I set it to two weeks.

However, the oops happened 4 months ago.

A GFS retention would have saved me.

I have backups with GFS, but only since 3 months.

I really do not see, why a GFS would not be useful for snapshots.

Greetings,

Hendrik

4

I doubt this will ever be implemented in TrueNAS in the foreseeable future. It would require major code changes in zetarepl. If not implemented in zetarepl, they would need to create their own solution from scratch or adopt another tool and modify it to work with TrueNAS.

1 Like
5

You can have that right now, but you need to create a different snapshot task for each retention value. Daily/weekly/monthly tasks can even use the same naming scheme and go through a single common replication task—in my experience it works very well with PULL replication; PUSH replication may yield undesired effects if you come back to edit the tasks.

So your request boils down to having an interface to generate the multiple tasks in one go.

6

…and have them appear as a single task in the list.