How much space do snapshots use in ZFS?
I created a pool and want to create a volume. I don't know how much space snapshots will occupy. Is there any way or formula exist to compute space requirements for snapshots?
Asked
Active
Viewed 1.2k times
4 Answers
4
The actual meta-data of snapshots are negligible.
As a copy-on-write file system, ZFS snapshots only require space for modified data; creating a snapshot does not immediately duplicate everything. If you have a snapshot of given size, and then add or modify files summing up to 100GB, the snapshot will "cost" you 100GB.
It might even be a little bit smaller because of compression and deduplication.
Jens Erat
- 5,131
- 7
- 33
- 37
1
Prior to emperically testing this, I also believed what other answers said, namely that ZFS snapshots only consume disk space when blocks change, and snapshots taken where no blocks change at all consume no space (or only a very small amount of metadata for the snapshot name and an empty lst of changed blocks)
To my surprise when I tested this recently I discovered that the space usage was much larger than I expected: while still small, it was between 1.8 - 4 MiB per snapshot, which was significantly larger than I would have expected. (My guess would have been less than 1 KiB, so this result was over 4000x larger than I expected). See my Server Fault question for the details, but essentially I created a totally empty 200GiB zpool and was able to fill it up with 50,698 snapshots (and no data at all)
What everyone else says is accurate: ZFS snapshots only store changed blocks and their space consumed depends on how many blocks change. But the minimum is not zero bytes, is's a handful of megabytes. (Where "handful" translates" to "somewhere between 1 and 10 depending on pool size and other factors")
Whether or not this amount is "very negligible" or not is an opinion question.
Josh
- 473
1
A snapshot initially takes a very negligible amount of space.
Its size grows later when existing data in the snapshotted dataset is updated or deleted.
The maximum size of a snapshot is the size of the original dataset unless compression and/or deduplication is enabled in which case you might have a snapshot smaller or larger than its parent dataset.
jlliagre
- 5,983
0
The size that it takes actually varies by quite a bit.
I set up an Ubuntu 22.04 VM in TrueNAS Scale and then the ZFS pool that stores the VM disk, I set that up to take a snapshot every hour.
Even with the VM idling, ZFS was still seeing about 1.7-ish MiB delta between the previous snapshot and the current one.
So, for the hours that I was completely away from the system, and letting the VM sit at idle, which means nothing should be changing in said Ubuntu VM, but as it turns out, that's not exactly entirely true, according to the theory and the ZFS documentation.
cf. my thread on Lawrence System's forums
(You can read the thread itself for more details about what I actually did to test this.)
Conversely, now I am running a different test, but with a Win11 VM instead. The OS disk itself is formatted to be 100 GiB, and again, I have set the ZFS pool to take a snapshot hourly and to only retain a week's worth of snapshots.
There, I've got about 165 snapshots right now, (started the test on Sep 1, 2024) taking a total of about 37 GiB of space, which means that on average, each snapshot is about 229 MiB, even when I'm at work, and again, where the Win11 VM is allow to sit at idle, doing literally nothing. (Not even Windows updates in the background.)
I would understand there being blocks that ZFS thinks changed, and therefore; would cause the USED column to be non-zero, if I was actively using the VM(s).
But you'd also think, based on the theory of operation, that for a VM that's idle, where nothing is changing, that the amount of space used by the snapshot would be zero or very very close to it.
But in practice, based on my running some very simple tests with idle VMs, that does not appear to be the case, and that makes trying to plan for the amount of extra space that I will need, virtually impossible.
