Skip to main content

How Nutanix Snapshots Work and Reclaim Storage Space

  • Nov 1, 2026 1:21 PM UTC
  • 1 reply
  • 22 views

Muhammad_Magdy

What actually happens?

Traditional backups copy entire files or virtual disks, which takes time and slows down your system. Nutanix uses a Redirect-on-Write (RoW) architecture combined with instantaneous metadata pointers.

1๏ธโƒฃ ๐˜›๐˜ฉ๐˜ฆ ๐˜—๐˜ฐ๐˜ช๐˜ฏ๐˜ต๐˜ฆ๐˜ณ๐˜ด ๐˜๐˜ณ๐˜ฆ๐˜ฆ๐˜ป๐˜ช๐˜ฏ๐˜จ (๐˜๐˜ฏ๐˜ด๐˜ต๐˜ข๐˜ฏ๐˜ต):
- Instead of copying your data blocks, Nutanix copies the metadata map (the index or map that tells the system where your data blocks live on the physical disks).
* The Process: The system takes a snapshot of this map, which takes milliseconds because metadata is incredibly small.
* The Result: The original data blocks become read-only for that specific point in time.

2๏ธโƒฃ ๐˜›๐˜ฉ๐˜ฆ ๐˜™๐˜ฆ๐˜ฅ๐˜ช๐˜ณ๐˜ฆ๐˜ค๐˜ต-๐˜ฐ๐˜ฏ-๐˜ž๐˜ณ๐˜ช๐˜ต๐˜ฆ ๐˜”๐˜ฆ๐˜ค๐˜ฉ๐˜ข๐˜ฏ๐˜ช๐˜ด๐˜ฎ (๐˜•๐˜ฐ ๐˜–๐˜ท๐˜ฆ๐˜ณ๐˜ฉ๐˜ฆ๐˜ข๐˜ฅ):
- The moment after the recovery point is created, your Virtual Machine (VM) keeps running and writing new data.
* Old Data: Stays exactly where it was, safely frozen as your recovery point.
* New Data: Instead of overwriting old data, any new changes are written to completely new locations on the storage array. The VMs active metadata map is updated to point to these new locations.
* Because no data was moved or copied during the creation phase, there is zero impact on VM performance and no waiting time.

3๏ธโƒฃ ๐˜ž๐˜ฉ๐˜บ ๐˜™๐˜ฆ๐˜ค๐˜ญ๐˜ข๐˜ช๐˜ฎ๐˜ข๐˜ฃ๐˜ญ๐˜ฆ ๐˜š๐˜ฑ๐˜ข๐˜ค๐˜ฆ ๐˜š๐˜ฉ๐˜ฐ๐˜ธ๐˜ด 0 ๐˜‰:
- The Reclaimable Space column displays the unique data blocks that would be physically deleted and freed up from the storage pool if only that specific snapshot were deleted.
- Because Nutanix snapshots use a Redirect-on-Write (RoW) and pointers architecture, consecutive recovery points share overlapping blocks. If the data inside the VM hasnt changed much between snapshots, or if those blocks are still referenced by other active recovery points in the chain, deleting just this snapshot yields 0 bytes of extra capacity back to the cluster

๐—ง๐—ต๐—ฎ๐˜ ๐—บ๐—ฎ๐—ธ๐—ฒ๐˜€ ๐˜๐—ต๐—ฒ ๐—ถ๐—ป๐—ถ๐˜๐—ถ๐—ฎ๐—น ๐˜€๐—ป๐—ฎ๐—ฝ๐˜€๐—ต๐—ผ๐˜ ๐—ผ๐—ฝ๐—ฒ๐—ฟ๐—ฎ๐˜๐—ถ๐—ผ๐—ป ๐—ฒ๐˜…๐˜๐—ฟ๐—ฒ๐—บ๐—ฒ๐—น๐˜† ๐—ณ๐—ฎ๐˜€๐˜, ๐—ฟ๐—ฒ๐—ด๐—ฎ๐—ฟ๐—ฑ๐—น๐—ฒ๐˜€๐˜€ ๐—ผ๐—ณ ๐˜„๐—ต๐—ฒ๐˜๐—ต๐—ฒ๐—ฟ ๐˜๐—ต๐—ฒ ๐—ฉ๐—  ๐—ถ๐˜€ ๐Ÿฑ๐Ÿฌ ๐—š๐—•, ๐Ÿฑ๐Ÿฌ๐Ÿฌ ๐—š๐—•, ๐—ผ๐—ฟ ๐˜€๐—ฒ๐˜ƒ๐—ฒ๐—ฟ๐—ฎ๐—น ๐—ง๐—•.

1 reply

Nice writeup. One side effect of that ownership model that people donโ€™t use enough: reclaimable space is also a rough record of how much data got overwritten or deleted after each snapshot. A block only becomes exclusive to a snapshot once the live VM rewrites or deletes it. So if a VM normally changes at a steady pace and one snapshot suddenly shows far more reclaimable space than the ones around it, something rewrote a lot of data right after that point. Could be a big patch or a database rebuild, but itโ€™s also exactly what mass encryption looks like.

Two caveats. The number comes from the periodic background scans, so it can sit on Processing for hours and itโ€™s no good as a live alert. And it shifts when you delete a neighbouring snapshot or clone from one, so if you ever need it after an incident, write the numbers down before anyone starts deleting snapshots to free space. Itโ€™s a cheap first look at where the change started, before you open the files themselves and decide which point to bring the VM back from.

Disclosure: Iโ€™m founder and CEO of CyberSnap.