A neighbor called me two summers ago in a mild panic. She had opened a spreadsheet, deleted three columns by accident, saved, and closed it before she noticed. The file was gone in the way that matters most: the good version was overwritten by a bad one.
Her NAS had been quietly saving old copies of that file for months. She just did not know it, and had no idea how to get one back.
That gap is what this piece is about. NAS file versioning is one of those features that sits switched on in the background, doing something useful, while most people never learn what it actually does or how far back it reaches.
What file versioning really means
Versioning is not the same thing as a backup, and mixing the two up causes real heartache. A backup is a copy of your data on separate hardware. Versioning is a record of what a file looked like at different points in time.
Think of it like the undo history in a word processor, except it survives closing the file, rebooting the machine, and days passing. Every time a file changes, the system can stash the previous state before writing the new one.
So nas file versioning gives you a small stack of past copies for each file. Delete a paragraph on Tuesday, and Monday's version is still sitting there waiting.
Where the versions actually live
The first time I hit this, I assumed versions were scattered invisibly next to each file. They are not. Most NAS systems store them in a hidden area tied to the shared folder or the sync job.
On a Synology using Snapshot Replication, versions are read-only point-in-time snapshots of the whole Btrfs volume, tucked away where normal browsing cannot touch them. On a QNAP, the same idea runs through their snapshot engine. If you sync files with something like Synology Drive or Nextcloud, that software keeps its own separate version stack per file.
This matters because the two approaches behave differently. A folder snapshot captures everything at once, every 15 minutes or every hour. A file-level version stack only records a copy when that specific file is saved.
Snapshots versus per-file versions
Snapshots are efficient and broad. Per-file versioning is precise and easy for a normal person to browse through in a right-click menu.
Plenty of home setups run both, and honestly that is a good place to be.
Incremental versus full: why your disk survives
Here is the part that surprises people. If your NAS kept 30 full copies of a 2 GB video project, that would be 60 GB for one file. Multiply that across a household and the math gets ugly fast.
It does not work that way, because good versioning is incremental. The system stores the first full copy, then for each later version it only records the blocks that changed.
Edit two paragraphs in a 40 MB document and the new version might cost a few kilobytes, not another 40 MB. This is the same block-level trick that modern backup tools use, and it is why 30 days of history often costs less space than you would guess.
| Approach | What it stores per version | Disk cost over 30 versions |
|---|---|---|
| Full copies | The entire file, every time | Very high, grows with each change |
| Incremental (block-level) | Only the changed blocks | Low, roughly the size of edits |
| Copy-on-write snapshots | Shared blocks plus deltas | Low until old blocks change |
Filesystems like Btrfs and ZFS take this further with copy-on-write. Old and new versions share the same underlying blocks until something actually changes, so a snapshot of a 500 GB volume can cost almost nothing at the moment you take it. You can read more about how copy-on-write works on Wikipedia's copy-on-write page.
Retention: how you hold exactly 30 days
Retention is the rulebook that decides which versions to keep and which to throw away. Without it, versions pile up until the disk is full and the NAS starts complaining.
Most systems give you two knobs. One caps the number of versions per file (keep the last 32, say), and the other caps the age (delete anything older than 30 days).
For a clean 30-day window, lean on the age rule and set version counts generously.
A sensible starting recipe
- Take a snapshot every hour during the day, or every time Drive syncs a change.
- Keep hourly versions for 24 hours, so recent mistakes are easy to undo.
- Keep one daily version for 30 days, giving you the month of history you wanted.
- Optionally keep one weekly version for a few months if space allows.
This tiered pattern, sometimes called a retention schedule, thins out old versions instead of keeping every single one. You still get Tuesday from three weeks ago, just not all 400 saves you made that Tuesday.
Setting it up without regret
Turn versioning on before you need it, because it cannot recover changes made before it was enabled. A mistake I see constantly is someone switching it on the day after they lose a file, then being furious it did not travel back in time.
Pick the folders that hold documents, photos being edited, and project files. Skip huge folders of finished media that never change, since versioning them just wastes space for no benefit.
Then test a restore on purpose. Edit a throwaway file, wait for a version to be captured, then recover the old copy so you know the exact clicks before a real emergency.
When versioning quietly eats your space anyway
Even incremental systems can balloon. The usual culprit is a huge file that changes constantly, like a database, a disk image, or a video project that rewrites the whole file on every save.
For those, a small edit can force a large new version, since the changed blocks are enormous. If your snapshot storage keeps climbing, sort by folder and look for one or two heavy hitters rather than assuming the whole system is broken.
The fix is usually to exclude those folders from versioning, or shorten their retention to a few days. Save the long 30-day history for the documents where it genuinely rescues you.
Getting a file back
Recovery is the payoff, and it is refreshingly simple once versioning is running. On a Windows PC connected to a Synology or QNAP share, right-click the file, choose Properties, and open the Previous Versions tab, which reads directly from the NAS snapshots.
Pick a date, hit Restore or Copy, and the old contents come back. Through a web interface like Synology Drive, you click the version history icon next to the file and preview each saved copy before restoring.
My neighbor got her spreadsheet back in under two minutes once I walked her to the Previous Versions tab. The columns she deleted were sitting there in Monday's copy, exactly as she left them.
A quiet safety net worth understanding
Versioning is one of the few NAS features that saves you from the most common disaster of all, which is you. Not a hacker, not a lightning strike, just a bad save on a busy afternoon.
Spend twenty minutes turning it on, set a 30-day retention rule, run one test restore, and then forget about it. The day you need it, you will be very glad the past is still sitting on your NAS, waiting.
Frequently asked questions
Is NAS file versioning the same as a backup?
No. Versioning stores past copies of files on the same NAS, protecting you from bad saves, deletions, and ransomware edits. A backup lives on separate hardware or off-site and protects you from drive failure, theft, or fire. You want both, since a dead volume takes your version history with it.
How much disk space does 30 days of versions actually use?
Far less than 30 full copies. Modern systems store versions incrementally, keeping only the changed blocks, and copy-on-write filesystems like Btrfs and ZFS let versions share unchanged data. For typical documents and photos, a month of history often adds only a small percentage on top of the live files.
How do I set versioning to keep exactly 30 days?
Use the age-based retention setting rather than the version-count limit. On Synology, set snapshot or Synology Drive retention to keep versions for 30 days and set the per-file version count generously. A tiered schedule (hourly for a day, daily for 30 days) gives clean history without keeping every single save.
Can I recover a file from before I turned versioning on?
No. Versioning only records changes made after it is enabled, so it cannot travel back to states it never captured. Turn it on early, before you have a problem, and confirm it is working with a quick test restore.
Why is my version storage filling up so fast?
Usually one or two large files that change often, such as a database, a disk image, or a video project that rewrites itself on every save. Each small edit forces a large new version. Exclude those folders from versioning or give them a short retention period, and keep long history for documents.
How do I restore an old version of a file?
On Windows, right-click the file on the NAS share, choose Properties, and open the Previous Versions tab, then pick a date and restore or copy it. In a web interface like Synology Drive, click the version history icon next to the file and preview each saved copy before restoring the one you want.
