Your NAS snapshots are probably disabled, and one mistake will teach you why that matters

Published Jul 17, 2026, 4:00 PM EDT Korbin is a Linux system administrator who spends most of his time in a terminal figuring out how things actually work. Over the last decade he's written hundreds of articles about Linux configuration, troubleshooting weird problems, and using open-source tools in the real world. He also works a lot with Windows systems and networking, especially in mixed environments where things don't always behave the way the documentation says they should. Writing things down is how he makes sense of it all and hopefully saves someone else a few hours. When I started using a NAS, I spent the first couple of years in a false sense of security, believing that redundant drives meant my data was safe. The problem is that RAID (or RAIDZ, if you're running ZFS like I am) protects you from a drive failure, and that's about it. It doesn't help if you overwrite the wrong file or delete something you meant to keep. The redundancy just means that your mistake is synchronized across all the hard drives in the pool. I learned that lesson the hard way when I overwrote an important text file that held all the information about my home lab setup. In the blink of an eye, all my customized options and configuration steps were gone, and my RAIDZ2 pool didn't care in the slightest. At that moment, I realized what the ZFS snapshots button in TrueNAS's GUI was for. It's a checkbox I never bothered to flip on, and it only took one lost file to realize its importance. Snapshots give you a built-in rewind button And ZFS makes this especially easy to set up TrueNAS calls these "Periodic Snapshot Tasks," and they're tucked within the Data Protection menu. Getting automated snapshots set up only takes a few minutes, so there's really no reason not to do it if you care about your files at all. You pick a dataset, a schedule, and a retention period, and TrueNAS handles the rest in the background. I'm running hourly snapshots kept for a day, daily snapshots kept for two weeks, and weekly snapshots kept for two months. That gives me enough granularity to catch recent mistakes without letting old data clutter up the server. ZFS handles snapshots beautifully because it's a copy-on-write filesystem. That means that a snapshot doesn't duplicate any data the moment you take it; it just freezes a reference to the current state of the blocks on disk. Snapshots happen nearly instantly, regardless of how much data you have, and they won't begin consuming any space until the current data starts changing. Once that happens, ZFS needs to preserve the old blocks so that the snapshot has something to reference. On my pool, I'm keeping two months of history, and it's using a surprisingly small amount of disk space. As for recovery, every ZFS dataset has a hidden .zfs/snapshot directory sitting at its root, browsable like any other folder, containing every snapshot that the system has taken. I can go into these folders to find the version I want of any file, and just copy it back out. I initially expected there'd be some kind of hassle with rolling back the dataset, but you don't need to do anything special at all to retrieve a past file. If this setup had been running when I overwrote the file that brought me here, it would've only taken me about 15 seconds to recover it. I can easily go months without needing to browse my old snapshots and recover files, but I'm human and occasionally make mistakes, so it's nice to know that past versions are recoverable when (not if) something actually does happen. Getting a copy somewhere, the mistake can't follow Offsite backups are the last piece of the puzzle Local snapshots solve the problem of accidental overwriting or deletion. But they don't protect against the entire pool dying, so it's important to account for both. If the pool goes down, it'll take all of the snapshots along with it. To address that, I replicate everything offsite. I simply use rsync to back up everything to a remote box, but there are plenty of fancier solutions available that essentially do the same thing for you. My backup script takes a snapshot on the remote server before it starts synchronizing all the recently changed files. Whatever is currently sitting in the backup directory gets hardlinked, and I just use the cp -al command for that. When the rsync command runs, it's not touching the older snapshots, just the current backup. This gives me another layer in case I lose my entire pool and want to recover a file's state from days or weeks ago. Snapshots themselves aren't a backup They're only one piece of a whole backup solution Keep in mind that snapshots on the same storage pool are still tied to the same hardware, so they both share a single point of failure. If the pool goes down because of a dead drive, a power surge, or a dozen other things that commonly kill a NAS, the snapshots will disappear along with your live data. That's why it's important not to conflate snapshots with backups, as they're two separate things that solve different problems. That's exactly why the "one offsite backup" part of the 3-2-1 backup strategy is paramount. Local ZFS snapshots give me fast, granular version history, but it's an incomplete backup without a remote copy in a different location that a local disaster can't reach. With both components in place, I've got real 3-2-1 coverage to ensure my data survives no matter what happens. Now my mistakes have an undo button The only real barrier to getting snapshots up and running was a checkbox inside of TrueNAS's menus. Snapshots consume very little data, unless you have very large files that undergo really frequent changes. If you're running ZFS and don't already have snapshots enabled, don't wait until you overwrite a file, like I did, to check that box.