The truenas snapshot schedule best practices that hold up at home come down to three or four tiered tasks: hourly snapshots kept for two days, daily kept for 30 days, weekly kept for eight weeks, and optionally monthly kept for six months, applied only to datasets whose data changes and matters, then replicated to a second machine.
That plan keeps under 100 snapshots per dataset, far below the thresholds TrueNAS warns about. The schedule is rarely what fails. What fails is hourly snapshots of a downloads dataset, pruning that silently stopped months ago, and the month-nine discovery that every snapshot lived on the pool that just died. Menu paths below are from TrueNAS 25.10 “Goldeye”.
What schedule should a home TrueNAS run?
Run several stacked periodic snapshot tasks on the same dataset, each with its own schedule and lifetime, instead of one task trying to do everything. A frequent, short-lived tier catches “I just saved over that spreadsheet.” Sparse, long-lived tiers catch “this file has been quietly broken since March.” Each tier is its own task under Data Protection > Periodic Snapshot Tasks > Add, as the TrueNAS 25.10 periodic snapshot task guide describes.
| Tier | Schedule | Snapshot Lifetime | Roughly kept per dataset |
|---|---|---|---|
| Hourly | 0 8-23 * * * | 2 days | 32 |
| Daily | 0 0 * * * | 30 days | 30 |
| Weekly | 0 0 * * 0 | 8 weeks | 8 |
| Monthly | 0 0 1 * * | 6 months | 6 |
Three decisions are baked into that table.
Hourly only while people are awake. Pick the Hourly preset and the Begin and End fields appear, per the Periodic Snapshot Tasks screen reference. Nothing on a family share changes at 4 a.m., so don’t snapshot it. The docs note that administrators commonly snapshot as often as every 15 minutes, even on large and busy pools, because a snapshot copies nothing. That’s defensible for a documents share edited all day. Everywhere else, hourly is plenty.
Keep the default naming schema on every tier. The default is auto-%Y-%m-%d_%H-%M, and the task guide says to stick with it if the snapshots will feed incremental replication. Because the name is built from the timestamp, the daily and weekly tasks firing at midnight on Sunday produce the same name: one snapshot, not two. TrueNAS “preserves snapshots when at least one periodic task requires it,” so that snapshot lives as long as the weekly tier wants it.
Budget for the lag. Lifetime is a floor, not a deadline. An expired snapshot is only removed when its task next runs and looks for obsolete snapshots, so the docs warn that a two-week lifetime on a weekly task can mean deletion three weeks later. Every tier carries roughly one extra interval of snapshots, and of deleted data.
Which datasets deserve the full stack?
Only datasets people edit by hand and cannot re-download get all four tiers. Replaceable bulk data gets a weekly tier or nothing, and scratch space gets excluded. Snapshots are free to create, but each one pins the blocks that existed when it was taken, and the docs note a snapshot’s size grows to reflect later changes. On a dataset that churns large files, deleted data stays on disk until the last snapshot referencing it expires.
- Documents, photos, SMB home shares: the full stack. This is what snapshots are for.
- App data: daily for 30 days plus weekly, and a manual snapshot before every app update. Apps using Host Path storage keep data in datasets you chose, so point the task at those; ixVolume storage lands in the hidden
.ix-appsdataset introduced in 24.10, covered in the k3s to Docker apps migration guide. Small config datasets, like the one behind a CUPS print server app, cost next to nothing to keep for months. - Databases and VM zvols: OpenZFS defines a snapshot as “a consistent image of a dataset at a specific point in time” covering every completed system call (zfs-snapshot(8)). That’s crash-consistent, the same state as pulling the plug. PostgreSQL and SQLite are built to recover from that. For anything you’d genuinely mourn, schedule a dump into the dataset a few minutes before the daily snapshot.
- Media libraries: weekly with a four-week lifetime, or nothing. Replace a large file under a 30-day daily tier and that space doesn’t come back for a month.
- Downloads, transcode cache, scratch: excluded.
The tidy setup is one recursive task on a parent dataset with the junk listed under Exclude, which the screen reference says works with recursive snapshots. OpenZFS creates recursive snapshots of every child at the same moment. Settle exclusions before building replication: the advanced replication docs say a replication task using a periodic snapshot task as its source “must have the same values in Recursive and Exclude Child Datasets.”
How many snapshots is too many on TrueNAS?
The middleware’s ceilings are 512 snapshots per dataset and 10,000 across the system, the values max_count and max_total_count return in the TrueNAS CLI reference. The plan above keeps about 80 per dataset, so thirty datasets land near 2,400. The per-dataset number is really a Windows number, and an aggressive frequent tier breaks it easily.
The alert source in the TrueNAS middleware only raises the per-dataset warning for SMB shares, with the text “File Explorer may not display all snapshots in the Previous Versions tab.” The Managing Snapshots docs go further: past File Explorer’s limit, File Explorer shows no snapshots at all. A 15-minute tier kept for a week is 672 snapshots on one share, which quietly empties Previous Versions for every Windows user. The system-wide alert is the performance one; it warns “performance or functionality might degrade.”
On datasets that sit idle for days, clearing Allow Taking Empty Snapshots stops the task producing zero-change snapshots that still count toward both limits. Check where you stand from a shell:
# every snapshot on the system
zfs list -H -t snapshot -o name | wc -l
# snapshots on one dataset, not its children
zfs list -H -t snapshot -o name -d 1 tank/documents | wc -l
# the limits your release uses
midclt call pool.snapshottask.max_count
midclt call pool.snapshottask.max_total_countIf you inherited thousands, clean up in batches. Creating a snapshot is instant; deleting one is I/O intensive because ZFS reviews allocated blocks before freeing them, per the Managing Snapshots page. The zfs-destroy(8) % syntax deletes an inclusive range, and a blank end means oldest or newest, so a stray trailing % takes out everything after it. Run every range with -nv first: -n is a dry run that deletes nothing and -v lists what would go, so a typo costs you a re-read instead of three months of history.
Why aren’t expired snapshots being deleted?
Retention is calculated from the tasks that exist right now, not stored on the snapshot. An iXsystems developer explained on the TrueNAS forums that snapshots subject to deletion “are calculated from existing periodic snapshot tasks and replication tasks,” matched on naming schema and on creation times aligned with the task’s schedule. Break that match and pruning stops.
- Deleting a task orphans its snapshots. The same developer confirmed that deleting every task for a naming schema stops those snapshots being deleted. Recreate the task and retention resumes; there is no hidden deletion list.
- Changing a schedule can do the same. Move the daily task from midnight to 02:00 and old midnight snapshots may no longer line up with any task. Recount a few days after any edit.
- Manual and app-created snapshots are never pruned by periodic tasks.
- Failing replication holds snapshots on purpose when Save Pending Snapshots is on.
Snapshots are not backups, so where should they go?
Snapshots live on the same pool as the data they protect, so a failed pool, a house fire, or an attacker with admin on the NAS takes out both. Replicate them to a second box. For the ransomware side of that threat model, TechSentinel tracks the broader security news.
Build it under Data Protection > Replication Tasks with the periodic snapshot tasks as the source. Leave Run Automatically on and replication starts right after the related snapshot task completes. Then set three things deliberately:
- Snapshot Retention Policy: Same as Source. The destination keeps each snapshot for the source task’s lifetime. Custom applies one lifetime to everything the task sends, so a one-year Custom policy on a task carrying hourlies keeps a year of hourlies. None never deletes anything on the destination.
- Save Pending Snapshots: on. The docs recommend it when replication has difficulty completing; it stops the source deleting snapshots that failed to replicate, preserving the common snapshot incremental sends depend on. The cost is a pile-up on the source while replication is broken, so make sure failure alerts reach a phone.
- Never roll back a replicated dataset. The Managing Snapshots page calls rollback “a dangerous operation that causes any configured replication tasks to fail,” because incremental replication depends on snapshot order. Clone the snapshot or copy files out instead.
The destination doesn’t need to be impressive. Any small box running TrueNAS with a mirrored pair of drives, parked at a relative’s house and reached over Tailscale rather than a port-forwarded SSH port, is enough for a household’s documents and photos.
A snapshot you have never restored from is a hypothesis, so drill it. Monthly, browse the hidden, read-only .zfs/snapshot/ directory at the root of a share, copy one file back and open it. Quarterly, clone last night’s snapshot on the destination, confirm the app configs are inside, then delete the clone.
FAQ
how often should i take snapshots on truenas
Hourly during waking hours is the right frequency for most home datasets, with daily, weekly and monthly tiers layered underneath. TrueNAS documentation notes that administrators commonly snapshot as often as every 15 minutes, but on an SMB share that pace crosses the 512-snapshot Previous Versions threshold within a week unless the lifetime is short.
how long should i keep truenas snapshots
Keep frequent snapshots for days and sparse ones for months: two days of hourlies, 30 days of dailies, eight weeks of weeklies and six months of monthlies covers most home mistakes. Going longer mostly costs space, because every retained snapshot keeps deleted and overwritten blocks on the pool until it expires.
do truenas snapshots use disk space
Yes, but only for data that changes after the snapshot is taken. Creating a snapshot copies nothing, so a fresh one is nearly free. As files are modified or deleted, the snapshot keeps the old blocks, and its size grows to match. Heavy churn, like replacing large media files, is where snapshots quietly eat a pool.
should i snapshot my truenas app data
Yes, snapshot app data daily and take a manual snapshot before every app update, since an update that migrates a database or rewrites config is exactly what you will want to undo. Apps using Host Path storage keep data in datasets you chose, which makes them easy to target from a periodic snapshot task.
Related across the network
- How to Set Up TrueNAS SCALE: From Bare Metal to First Share — truenasguide.com
- How to Set Up an iSCSI Target on TrueNAS: Zvol to Login — iscsihub.com
