A few years back I fat-fingered a delete on a folder of family photos that lived on my TrueNAS box. About 40GB, gone in a single keystroke. My stomach dropped for roughly ten seconds, right up until I remembered I had a snapshot task running every 15 minutes.
I browsed a hidden folder, copied the files back, and the whole recovery took less time than making coffee.
That is the quiet superpower of TrueNAS ZFS snapshots. They are not a backup in the strict sense, but they are the fastest undo button your home server has, and most beginners never turn them on.
What a ZFS snapshot actually is
A snapshot is a frozen, read-only picture of a dataset at one exact moment. ZFS does not copy your data to make one. It just marks the current blocks as "keep these" and lets new writes go elsewhere.
That is why a fresh snapshot takes near-zero space and is created almost instantly, even on a 10TB pool. Space only gets consumed later, as you change or delete files and the old blocks have to stick around because a snapshot still references them.
The practical upshot: you can keep dozens of snapshots without noticing, as long as you are not churning huge amounts of data between them. If you want the deeper mechanics, the ZFS overview on Wikipedia covers the copy-on-write design well.
Step 1: Pick the dataset that matters
You do not snapshot the whole system. You snapshot a specific dataset, which is TrueNAS SCALE's term for a managed folder inside your pool.
In the web interface, go to Datasets in the left menu and look at your tree. Most people have something like tank/media, tank/documents, and tank/photos. The documents and photos ones are where accidental deletes hurt, so those are your priority targets.
Media libraries you can re-rip usually do not need aggressive snapshotting. Irreplaceable stuff does.
One thing worth knowing early: a snapshot captures the dataset, not individual shares or apps. If two SMB shares point at sub-folders of the same dataset, one snapshot task covers both. That is why it pays to think in datasets, not shares, when you plan this out.
Step 2: Create a periodic snapshot task
Here is where the automation lives. Go to Data Protection in the left menu, find the Periodic Snapshot Tasks card, and click Add.
You will fill in a handful of fields. The first time I did this I overthought every one of them, so let me save you the trouble.
- Dataset: pick the one from Step 1, for example
tank/documents. - Recursive: tick this if you want child datasets included too. For a photos folder with sub-folders, yes.
- Snapshot Lifetime: how long each snapshot is kept before ZFS auto-deletes it. Start with 2 weeks.
- Naming Schema: leave the default. It stamps each snapshot with a timestamp.
- Schedule: choose a preset or a custom cron. Hourly is a sane starting point for documents.
Save it, and TrueNAS starts taking snapshots on that schedule automatically. No further babysitting required.
Step 3: Understand what your retention costs
People panic that snapshots will eat their pool. They usually will not, but it depends entirely on how much you change.
A document dataset that gains a few edited files a day might accumulate a few hundred megabytes of snapshot data over two weeks. A dataset where you delete and re-download 50GB nightly is a different story.
Here is a rough sense of typical home usage.
| Dataset type | Change rate | Sensible interval | Snapshot overhead |
|---|---|---|---|
| Documents | Low | Hourly, keep 2 weeks | Under 1GB usually |
| Photos | Low, bursty on imports | Daily, keep 30 days | A few GB after big imports |
| Active project files | Medium | Every 15 min, keep 3 days | Modest, self-clears fast |
| Media rips | High churn | Skip or weekly only | Can balloon, watch it |
You can always check real usage under Datasets, where each dataset shows its used space broken into data and snapshots.
Step 4: Restore a file the fast way with .zfs
This is the part almost nobody teaches, and it is the whole reason snapshots feel magic.
Every dataset has a hidden directory called .zfs sitting at its root. Inside it is a snapshot folder, and inside that is one folder per snapshot, each holding a complete read-only copy of the dataset as it was at that moment.
So if you deleted budget.xlsx from a shared documents folder, you do not need any restore wizard. You just walk into the snapshot and copy the file back out.
From a Windows machine over SMB
The .zfs folder is hidden and does not show up when you browse the share normally. In File Explorer, click the address bar and type the path directly, like truenasdocuments.zfssnapshot and press Enter.
You will see a folder for each snapshot, timestamped. Open the most recent one from before your mistake, find your file, and copy it back to the live share. Done.
From the TrueNAS shell
If you prefer the command line, SSH in and run something like this from the dataset mount point:
ls /mnt/tank/documents/.zfs/snapshot/
Pick the snapshot you want, then copy the file out with cp. The files inside are read-only, so you cannot accidentally damage the snapshot while grabbing what you need.
A couple of habits that keep you out of trouble
First, test a restore before you actually need one. Delete a throwaway file, wait for the next snapshot, then practice pulling it back from .zfs. The first real emergency is a bad time to learn the path. In my experience it takes about 90 seconds start to finish once you have done it once.
Second, keep an eye on snapshot count on high-churn datasets. TrueNAS will happily let you stack thousands of snapshots, and while it handles them fine, listing and managing them gets sluggish past a point.
Third, remember the boundary. Snapshots are local history on the same disks. Pair them with a replication task to a second machine or a cloud sync, because a lightning strike does not care how many snapshots you kept.
Where to go from here
Once your periodic tasks are humming, the natural next move is Replication Tasks, which send those same snapshots to another TrueNAS box or an external drive. That turns your fast local undo button into an actual off-site backup, and it reuses the snapshots you already have. The official TrueNAS SCALE snapshot documentation walks through the replication pairing when you are ready.
Get the snapshot task running today, then go delete a test file and rescue it. The moment you copy something back out of .zfs yourself, this stops being theory and starts being the safety net you actually trust.
Frequently asked questions
Do ZFS snapshots slow down my TrueNAS server?
Creating a snapshot is nearly instant and costs no real performance, because ZFS just marks existing blocks instead of copying data. You might see slight overhead only if you accumulate many thousands of snapshots on a very busy dataset. For typical home use with hourly or daily tasks, you will never notice it.
How much disk space do snapshots use on TrueNAS?
A brand new snapshot uses almost nothing. Space gets consumed over time as you change or delete files, because the old blocks must be retained while a snapshot still references them. A low-change documents dataset might use under a gigabyte over two weeks, while a high-churn media folder can grow much larger.
Where is the .zfs directory on TrueNAS SCALE?
It sits at the root of every dataset but stays hidden from normal browsing. Over an SMB share, type the path directly into File Explorer, such as \truenasdocuments.zfssnapshot. From the shell it lives at /mnt/pool/dataset/.zfs/snapshot/ where each subfolder is one timestamped snapshot.
Are TrueNAS snapshots a replacement for backups?
No. Snapshots live on the same pool as your data, so a drive failure, pool corruption, or theft takes the snapshots with it. They protect brilliantly against accidental deletes and edits, but you still need an off-box copy. Add a Replication Task or cloud sync for real backup coverage.
What is the difference between rolling back and restoring a single file?
Rolling back reverts the entire dataset to an old snapshot and permanently discards every change made after it, which is rarely what you want. Restoring a single file means browsing the .zfs snapshot folder and copying just that file back into the live dataset. For everyday recovery, always copy the file rather than roll back.
