Snapshot Space Estimator: How Much Storage Do Your Snapshots Really Use?
This estimator works out how much space a NAS snapshot policy keeps, from how much of your data changes each day, how often the same data is rewritten, how often you take snapshots and how long you keep them. If your NAS already reports snapshot space, it projects that measurement instead.
Snapshots on Btrfs (Synology) and ZFS (TrueNAS, QNAP QuTS hero) do not copy your data. They keep old versions of blocks that you have since changed or deleted, so the space they use depends on what you change, how often, and how long you keep history. Use this to plan a policy before it fills your NAS, or to understand why it already has.
Snapshots are not backups. They live on the same storage pool as your data. A redundant RAID pool survives a single drive failure, so one failed drive does not take your snapshots with it, but anything that loses the pool loses both. Keep a separate backup as well: see the 3-2-1 backup strategy guide.
Estimated snapshot space
…
Will it fit?
Same history, other intervals
| Interval | Snapshots kept | Snapshot space |
|---|
Measure it on your system
Not included: growth of your live data (new files you add), snapshots of other shares, and metadata. Check your real snapshot usage after a week or two and switch to "From a measurement".
How we calculate
- Snapshot space = data changed per day × old versions kept per changed block per day × days of history ÷ (compression ratio × deduplication ratio).
- Data changed per day is existing data overwritten or deleted, counted once a day however often it changes. A block that did not exist before has no old version to keep, so new files grow your live data, not your snapshots.
- Old versions kept per changed block per day = the smaller of snapshots per day and rewrites per day. Between two snapshots a block keeps only one old version, so rewrites in between are never captured (the overlap). Data changed once a day keeps one old version a day at any interval; data rewritten constantly keeps one per snapshot.
- Days of history = snapshots kept ÷ snapshots per day, or the days you enter.
- Compression and deduplication divide the result only when you enter a ratio. Both default to 1, no saving.
- From a measurement: snapshot space reported now ÷ days it covers × days you want. A measured figure already reflects compression, deduplication and your real rewrite pattern, so nothing else is applied to it.
- Not modelled: growth of your live data, policies that mix tiers (for example hourly for two days plus daily for a month; add each tier's estimate as a rough guide), metadata, and the time a filesystem takes to reclaim space after a snapshot is deleted. Snapshot space is not capped at the size of your data: rewrite-heavy data can keep more old versions than it has live blocks.
This is a planning model, not an exact account of your filesystem. Real change is uneven (a big copy or a database rebuild arrives in one go), and blocks shared between snapshots are counted once. Use it to choose a policy, then check the space your NAS actually reports.
Worked examples
A typical file share. 2 TB of documents and photos, 1.5% overwritten or deleted a day (30 GB), changed once, daily snapshots, latest 14 kept: 30 GB × 1 × 14 days = 420 GB, about 21% of the data. If your system reports a 1.5 compression ratio for this data: 280 GB.
A VM or database dataset, where frequency matters. 1 TB, 2% changed a day (20 GB), rewritten constantly, 7 days of history: daily snapshots keep 140 GB, every 4 hours 840 GB, hourly (168 snapshots) 3.36 TB, more than the data itself. If the same 20 GB were changed once a day instead, hourly snapshots would keep 140 GB, the same as daily.
From a measurement. A 3 TB dataset whose snapshots use 180 GB for 14 days of daily snapshots grows about 12.86 GB per day of history, so 30 days would use about 385.71 GB. On a 4 TB pool with a 20% planning reserve, the limit is 3.2 TB and data plus snapshots would be 3.39 TB: into the reserve.
One block, from the inside. A block rewritten every hour, 7 days kept: daily snapshots hold 7 old versions of it, hourly snapshots 168. Our tests check the formula against a block-by-block simulation of exactly this.
| Interval | Snapshots kept | Changed once a day | Rewritten constantly |
|---|---|---|---|
| Every 15 minutes | 672 | 140 GB | 3.36 TB |
| Hourly | 168 | 140 GB | 3.36 TB |
| Every 4 hours | 42 | 140 GB | 840 GB |
| Every 6 hours | 28 | 140 GB | 560 GB |
| Every 12 hours | 14 | 140 GB | 280 GB |
| Daily | 7 | 140 GB | 140 GB |
The assumptions behind the lists
| Change rate example | % of data a day |
|---|---|
| 0.5% a day: archives, a media library you rarely edit | 0.5% |
| 1.5% a day: documents and photos you edit or tidy up | 1.5% |
| 4% a day: an active workstation share | 4% |
| 7.5% a day: databases, VM disks, development | 7.5% |
| 15% a day: video projects, build output | 15% |
| Rewrite pattern | Times a day |
|---|---|
| Once: files are edited, replaced or deleted, not rewritten all day | 1 |
| A few times a day: project files saved repeatedly | 4 |
| Constantly: VM disks, databases, anything rewriting the same blocks | 24 |
These are NTK's planning examples, not measurements. Your own measurement beats all of them.
Snapshot space terms
| Term | What it means |
|---|---|
| Live data | The current version of every block in your shares or datasets. |
| Snapshot space | Old block versions that only snapshots still reference: data you have overwritten or deleted since. |
ZFS usedbysnapshots | On ZFS, the usedbysnapshots property is the space that would be freed if all of a dataset's snapshots were destroyed. It is not the sum of each snapshot's used value, because snapshots can share space. (OpenZFS documentation, checked 2026-10-06) |
ZFS snapshot used | On ZFS, a snapshot's used value is the space only that snapshot references. Space shared with other snapshots is not counted, and when a snapshot is destroyed, space it shared can become unique to its neighbours, so their used values change. (OpenZFS documentation, checked 2026-10-06) |
ZFS written | On ZFS, the written property is the space the dataset references that was written since the previous snapshot, meaning space the previous snapshot does not reference. (OpenZFS documentation, checked 2026-10-06) It includes newly added data, so it is not the same as snapshot space. |
| Synology Calculate Size | To see how much space a Synology shared folder's snapshots use: Snapshot Replication > Snapshots, select the shared folder, then Snapshot > Calculate Size, with a time range of at least a week. Only shared folder snapshots can be calculated, and the result is an estimate. (Synology Knowledge Center, checked 2026-10-06) |
| QNAP Pool Guaranteed Snapshot Space | QNAP's Pool Guaranteed Snapshot Space reserves capacity in the pool for snapshots. It is a reservation, not the space snapshots currently use: when it is becoming full, the oldest snapshots are removed automatically so new ones can be taken. (QNAP FAQ, checked 2026-10-06) |
What is not snapshot space
- Total write traffic: rewriting the same blocks many times between two snapshots keeps one old version, not many.
- The number of snapshots on its own: a snapshot taken when nothing changed keeps nothing extra.
- Newly added files: they grow your live data.
- Space reserved for snapshots: a reservation is capacity set aside, not capacity used.
Copy-on-write filesystems such as ZFS and Btrfs write a changed block to a new place and keep the old one while a snapshot references it; nothing is copied before the write. ZFS never modifies a block in place, so keeping an old version of a dataset costs only a reference to the blocks that were live at that moment. (OpenZFS documentation, checked 2026-10-06) On Synology, snapshot files themselves are very small; the space is taken by the data blocks the snapshots preserve. When a file is changed, the change is stored on new blocks and the original blocks stay as part of the snapshots. (Synology Knowledge Center, checked 2026-10-06)
Snapshots and backups
Snapshots undo mistakes quickly: a deleted folder, an overwritten file, some ransomware damage. They share the pool with your data, so more drive failures than your RAID level covers, a failed controller, fire, theft, or someone with administrator access deleting snapshots takes both. Pair them with a separate backup, ideally off site. To plan one, see the Cloud Backup Time Estimator, the Cloud vs NAS calculator and the 3-2-1 backup strategy guide.
Platform facts this page uses
Each fact below is taken from the vendor's or project's own documentation and was re-found at the source on the date shown.
| Fact | Applies to | Source |
|---|---|---|
| ZFS (TrueNAS, Proxmox, QNAP QuTS hero and others) | ||
| ZFS never modifies a block in place, so keeping an old version of a dataset costs only a reference to the blocks that were live at that moment. | OpenZFS (Snapshots, Clones and Bookmarks) | OpenZFS documentation, checked 2026-10-06 |
| Creating a ZFS snapshot is nearly instantaneous and initially uses no extra space; it starts to account for space as the live data diverges from it. | OpenZFS (Snapshots, Clones and Bookmarks) | OpenZFS documentation, checked 2026-10-06 |
| On ZFS, the usedbysnapshots property is the space that would be freed if all of a dataset's snapshots were destroyed. It is not the sum of each snapshot's used value, because snapshots can share space. | OpenZFS (zfsprops manual, master) | OpenZFS documentation, checked 2026-10-06 |
| On ZFS, a snapshot's used value is the space only that snapshot references. Space shared with other snapshots is not counted, and when a snapshot is destroyed, space it shared can become unique to its neighbours, so their used values change. | OpenZFS (zfsprops manual, master) | OpenZFS documentation, checked 2026-10-06 |
| On ZFS, the written property is the space the dataset references that was written since the previous snapshot, meaning space the previous snapshot does not reference. | OpenZFS (zfsprops manual, master) | OpenZFS documentation, checked 2026-10-06 |
| Changing the ZFS compression setting affects only data written after the change. | OpenZFS compression property (zfsprops manual, master) | OpenZFS documentation, checked 2026-10-06 |
| OpenZFS advises not to enable deduplication without a specific reason, calls it the most resource-intensive ZFS feature, and suggests trying compression first. | OpenZFS (Deduplication) | OpenZFS documentation, checked 2026-10-06 |
| OpenZFS says to plan for at least 1.25 GiB of RAM per 1 TiB of stored data for deduplication, and that the real figure depends on block sizes and how much of the data is actually duplicated. | OpenZFS (Deduplication) | OpenZFS documentation, checked 2026-10-06 |
| On ZFS, the pool's dedupratio is the storage that would be needed without deduplication divided by what is actually used. | OpenZFS (Deduplication) | OpenZFS documentation, checked 2026-10-06 |
| Clones and send-based workflows already share blocks without deduplication, as does block cloning. | OpenZFS (Deduplication) | OpenZFS documentation, checked 2026-10-06 |
| Synology DSM | ||
| On Synology, snapshot files themselves are very small; the space is taken by the data blocks the snapshots preserve. When a file is changed, the change is stored on new blocks and the original blocks stay as part of the snapshots. | DSM 7 series, DSM legacy versions, DSM Enterprise (per the article) | Synology Knowledge Center, checked 2026-10-06 |
| To see how much space a Synology shared folder's snapshots use: Snapshot Replication > Snapshots, select the shared folder, then Snapshot > Calculate Size, with a time range of at least a week. Only shared folder snapshots can be calculated, and the result is an estimate. | DSM 7 series, DSM legacy versions, DSM Enterprise (per the article); shared folders only | Synology Knowledge Center, checked 2026-10-06 |
| On Synology, space reclamation runs periodically, so space from deleted snapshots is not released immediately. | DSM 7 series, DSM legacy versions, DSM Enterprise (per the article) | Synology Knowledge Center, checked 2026-10-06 |
| Synology's retention settings offer a Smart Retention policy (keep the latest snapshot of each hour, day, week, month or year for a set period), a number of latest snapshots to keep, or keep all snapshots for a number of days. | DSM 7.4 Snapshot Replication help | Synology DSM Help, checked 2026-10-06 |
| QNAP | ||
| QNAP's Pool Guaranteed Snapshot Space reserves capacity in the pool for snapshots. It is a reservation, not the space snapshots currently use: when it is becoming full, the oldest snapshots are removed automatically so new ones can be taken. | All NAS series, firmware 4.4.1 or above (per the FAQ) | QNAP FAQ, checked 2026-10-06 |
Frequently Asked Questions
What is the difference between snapshots and backups?
A snapshot is a read-only, point-in-time view of your data kept on the same storage pool as the data. It is quick to take and quick to restore from, which makes it good for undoing a deletion, a bad edit or some ransomware damage. A backup is a separate copy on another device or in another place. Because snapshots share the pool with the live data, anything that loses the pool loses both: more drive failures than the RAID level covers, a failed controller, fire, theft, or an attacker with administrator access who deletes snapshots. A single failed drive in a redundant RAID pool does not, because the pool survives it. Use snapshots and a separate backup, ideally off site.
Why are my snapshots using so much space?
On Synology, snapshot files themselves are very small; the space is taken by the data blocks the snapshots preserve. When a file is changed, the change is stored on new blocks and the original blocks stay as part of the snapshots. Space grows with how much existing data is overwritten or deleted while snapshots still reference the old version, and with how long you keep them. Deleted files are a common surprise: the live data shrinks but the blocks stay until no snapshot references them. Data that is rewritten many times a day, such as a VM disk or a database, grows snapshot space faster under frequent snapshots, because each snapshot can keep a different version of the same blocks. New files added after a snapshot do not grow snapshot space on their own.
Do more frequent snapshots use more space?
It depends on the workload and on whether you hold the number of snapshots or the length of history fixed. For the same number of days, data that changes once a day takes the same space whether you snapshot hourly or daily. Data that is rewritten many times a day takes more with frequent snapshots: between two snapshots only one old version of a block is kept, so hourly snapshots can keep up to 24 versions a day where daily snapshots keep one. For the same NUMBER of snapshots, less frequent snapshots cover a longer history and usually keep more. The table on this page shows both effects.
How do I measure how much space my snapshots use?
On ZFS, the usedbysnapshots property is the space that would be freed if all of a dataset's snapshots were destroyed. It is not the sum of each snapshot's used value, because snapshots can share space. On ZFS, a snapshot's used value is the space only that snapshot references. Space shared with other snapshots is not counted, and when a snapshot is destroyed, space it shared can become unique to its neighbours, so their used values change. To see how much space a Synology shared folder's snapshots use: Snapshot Replication > Snapshots, select the shared folder, then Snapshot > Calculate Size, with a time range of at least a week. Only shared folder snapshots can be calculated, and the result is an estimate. QNAP's Pool Guaranteed Snapshot Space reserves capacity in the pool for snapshots. It is a reservation, not the space snapshots currently use: when it is becoming full, the oldest snapshots are removed automatically so new ones can be taken. Enter that figure and the number of days of history it covers in the "from a measurement" mode to project it to a longer or shorter history.
How do I estimate my daily change rate?
The most reliable way is to measure: note the snapshot space your system reports, wait a week with your normal schedule, and divide the growth by seven, or use the measurement mode here. On ZFS, the written property is the space the dataset references that was written since the previous snapshot, meaning space the previous snapshot does not reference. That includes newly added files, which do not grow snapshot space by themselves, so for data that is mostly added to, written per snapshot overstates the change rate. If you cannot measure yet, start from the examples in the change-rate list and treat the result as a rough plan.
Will deleting old snapshots free space immediately?
Deleting a snapshot frees only the blocks that no other snapshot and no live file still references. Deleting one snapshot can free almost nothing if its neighbours share the same old blocks, and the oldest snapshot is not always the one holding the most. On ZFS, a snapshot's used value is the space only that snapshot references. Space shared with other snapshots is not counted, and when a snapshot is destroyed, space it shared can become unique to its neighbours, so their used values change. On Synology, space reclamation runs periodically, so space from deleted snapshots is not released immediately.
Do snapshots slow down my NAS?
Creating a ZFS snapshot is nearly instantaneous and initially uses no extra space; it starts to account for space as the live data diverges from it. We could not find a source for a universal performance cost: it depends on the filesystem, the workload, how many snapshots and how much history you keep, how full the pool is and the hardware. Measure your own workload rather than relying on a fixed percentage. The practical risk is space: a pool that fills up cannot take new writes or new snapshots.
Do compression and deduplication shrink snapshots?
They can, by an amount that depends entirely on your data. Video, photos, archives and encrypted files barely compress; text, databases and VM disks often do. This calculator applies no saving unless you enter a ratio you have seen on your own system, and offers a deduplication ratio only for ZFS-based platforms. Changing the ZFS compression setting affects only data written after the change. OpenZFS advises not to enable deduplication without a specific reason, calls it the most resource-intensive ZFS feature, and suggests trying compression first. OpenZFS says to plan for at least 1.25 GiB of RAM per 1 TiB of stored data for deduplication, and that the real figure depends on block sizes and how much of the data is actually duplicated. Clones and send-based workflows already share blocks without deduplication, as does block cloning.
How much free space should I keep for snapshots?
There is no single rule that suits every filesystem and workload. Keeping more free space gives snapshots room to grow and leaves a margin for a burst of changes; keeping less gives you more usable space but less warning before the pool fills. Pick a planning reserve and check the result against it, then compare it with your NAS vendor's own alerts. QNAP's Pool Guaranteed Snapshot Space reserves capacity in the pool for snapshots. It is a reservation, not the space snapshots currently use: when it is becoming full, the oldest snapshots are removed automatically so new ones can be taken.
Do ZFS and Btrfs copy data before overwriting it?
No. Copy-on-write filesystems write the new version of a block somewhere else and keep the old block for as long as a snapshot references it. Nothing is copied first. ZFS never modifies a block in place, so keeping an old version of a dataset costs only a reference to the blocks that were live at that moment. On Synology, snapshot files themselves are very small; the space is taken by the data blocks the snapshots preserve. When a file is changed, the change is stored on new blocks and the original blocks stay as part of the snapshots.
Last reviewed: 4 September 2026. Platform facts checked 2026-10-06.