Skip to main content

Quick Tip: Why does a Nutanix Recovery Point show 0 B and Create Instantly, Regardless of VM Size?

  • Oct 7, 2026 6:39 AM UTC
  • 1 reply
  • 52 views

MMagdy
Nutanix Employee

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

Good explanation of the ownership model. One more use for that column: reclaimable space is also a rough record of how much data was overwritten or deleted after each snapshot, because a block only becomes exclusive to a snapshot once the live VM rewrites or drops it. If a VM changes at a steady pace and one snapshot suddenly shows far more than its neighbours, something rewrote a lot of data right after that point. Could be a big patch or a database rebuild, but itโ€™s also what mass encryption looks like. Caveat: the figure comes from periodic background scans, so it can sit on Processing for hours and is no use as a live alert, and it shifts when you delete a neighbouring snapshot. If you ever need it after an incident, write the numbers down before anyone deletes snapshots to free space. It tells you where to start looking before you open the files and decide which point to bring the VM back from. Disclosure: Iโ€™m founder and CEO of CyberSnap, which looks at existing snapshots for signs of encryption and file tampering.