TrueNAS Snapshot Schedules: 5 Best Practices

ZFS snapshots are one of the strongest arguments for TrueNAS in mid-sized IT environments: they are atomic, virtually free in terms of storage overhead when data changes little, and they can be rolled back in seconds. But that convenience has a flip side. A poorly planned snapshot strategy on TrueNAS SCALE 25.10 or TrueNAS CORE 13.3 will quickly produce six-figure snapshot counts, drive up pool import times and load the ARC with metadata.

In this article, we share five concrete best practices that we have established in our projects with mid-market customers and with tax and law firms. The goal is a snapshot strategy that meets compliance requirements, is ransomware-resilient and at the same time does not ruin storage performance.

1. GFS retention instead of “keep everything”

The most common mistake in TrueNAS installations is a single Periodic Snapshot Task with long retention — such as “every 15 minutes, keep for 90 days”. The result: about 8,640 snapshots per dataset. With 20 datasets that easily becomes 170,000 snapshots whose metadata must be walked through on every pool import.

Instead, we recommend a classic Grandfather-Father-Son retention (GFS) with four staggered tasks:

Schedule	Interval	Retention	Snapshots per dataset
Hourly	hourly	24 hours	24
Daily	daily 23:00	30 days	30
Weekly	Sundays 23:30	12 weeks	12
Monthly	1st of month 23:45	12 months	12

That totals around 78 snapshots per dataset instead of several thousand. With 20 datasets you stay below 1,600 snapshots — a value that lets TrueNAS come back to production in under 30 seconds even after a reboot.

2. Recursive vs. per-dataset — decide deliberately

In TrueNAS, each Periodic Snapshot Task lets you specify whether child datasets are included recursively. That is convenient, but it can get expensive. A recursive snapshot on tank/data with ten child datasets creates eleven snapshots in the same second — and eleven entries in the replication log.

Our rule of thumb:

• Recursive when the child datasets logically belong together and must be roll-back-consistent (e.g. an application group with app/db, app/files, app/logs).
• Per-dataset when retention requirements differ or when individual datasets should not be in the backup at all (e.g. tank/scratch or tank/temp).

For datasets that should not be snapshotted, also set the ZFS property com.sun:auto-snapshot=false. That way an accidentally recursive task will not pick them up later.

zfs set com.sun:auto-snapshot=false tank/scratch
zfs set com.sun:auto-snapshot=false tank/iscsi/swap

3. Naming convention for traceable snapshots

TrueNAS lets you define a naming schema per task. We consistently use a format that makes the interval, timestamp and source readable. This saves enormous time during audits and restore requests.

The pattern that has proven itself:

auto-<interval>-%Y-%m-%d_%H-%M

Concrete examples from a production environment:

auto-hourly-2026-06-14_09-00
auto-daily-2026-06-14_23-00
auto-weekly-2026-06-08_23-30
auto-monthly-2026-06-01_23-45
manual-pre-update-truenas-25.10

Manual snapshots — for instance before a TrueNAS update or an application migration — are explicitly marked with the prefix manual-. This way no automatic retention will accidentally clean up an important pre-change state.

4. Replication: separate local from remote-backed datasets

Snapshots on the same pool are not a backup. They will not survive a pool-level disaster, nor a ransomware attack that uses elevated privileges to attack the storage directly. So every snapshot strategy must include replication — typically via zfs send | zfs recv to a second TrueNAS system, ideally at a different location.

In the concept we recommend a clear separation:

Dataset class	Local snapshots	Replication	Example
Production data	GFS (78 snaps)	daily, 30 days	tank/fileserver, tank/vm
Compliance-relevant	GFS (78 snaps)	daily, 10 years	tank/dms, tank/accounting
Scratch / cache	off	off	tank/scratch, tank/iscsi-swap
Test / lab	hourly 24h	off	tank/lab

On the replication target we use our own snapshot tasks with a different naming convention (backup-*), so source and target can always be distinguished. Replication itself runs via SSH+Netcat or through a dedicated replication user. If you want to know more about architecture and sizing, our TrueNAS page shows typical setups — complemented by our backup consulting for 3-2-1 concepts.

5. Holds for compliance and critical restore points

Snapshots can be deleted by a Periodic Task as soon as the retention expires. For compliance-relevant states — such as a fiscal year end, a GoBD record date, or a confirmed pre-migration snapshot — this is not acceptable. This is where ZFS holds come in.

A hold prevents a snapshot from being deleted as long as the hold is set. Even a zfs destroy will fail. On the CLI:

# Place a hold on a snapshot
zfs hold gobd-2026 tank/accounting@manual-yearend-2026-12-31

# Show existing holds
zfs holds tank/accounting@manual-yearend-2026-12-31

# Release a hold (e.g. after the retention period has ended)
zfs release gobd-2026 tank/accounting@manual-yearend-2026-12-31

In the TrueNAS web UI, holds can be set under “Datasets -> Snapshots” via the action menu. We combine this with a documented table per client that records every hold together with the reason, owner and expiry date. The pool stays audit-proof without having to disable automatic retention.

Impact on metadata and ARC

One point that is easily overlooked during planning: every snapshot consumes metadata. With 10,000+ snapshots per pool the memory requirement for ZFS metadata rises noticeably — as a rule of thumb we calculate 0.5 to 1 KB per snapshot in the ARC. That sounds little, but it adds up. On a TrueNAS with 64 GB RAM and an aggressive snapshot strategy we have seen setups where several GB of ARC were consumed solely by snapshot metadata — ARC that was missing for read caching of productive data.

With the GFS strategy outlined above this value stays well manageable. We also recommend monitoring the snapshot count, e.g. via a cron script:

zfs list -H -t snapshot -o name | wc -l

Values above 5,000 should be reviewed, above 20,000 it is time to consolidate the retention.

Conclusion

ZFS snapshots in TrueNAS are extremely powerful — but only if the schedule strategy matches the actual data classification. GFS retention, a deliberate choice between recursive and per-dataset, clear naming rules, a cleanly separated replication and targeted holds for compliance states together form a robust backup concept that holds up even under ransomware pressure.

DATAZONE supports you from Neuburg an der Donau in planning and building your TrueNAS snapshot and replication strategy — from data classification through the design of TrueNAS and backup architectures all the way to audit and compliance topics. Get in touch at /en/kontakt/.