<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Snapshots in ONTAP Discussions</title>
    <link>https://community.netapp.com/t5/ONTAP-Discussions/Snapshots/m-p/24548#M5783</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;The NetApp is based on the WAFL (Write Anywhere File Layer) at any given time a file or object is stored via a map of the blocks on the underlying WAFL filesystem. When you make a change to the object the changed block(s) are written into that map. In a heavily simplified example a snapshot is simply a copy of that map at a given time. If blocks subsequently change, there are stored in the current object map. If blocks haven't changed changed than the two maps would be identical in contents. If one block is released in the current map the snapshot would still retain it.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Space wise, a snapshot is a static reference to the blocks on the underlying filesystem. This would effectively make those blocks read-only. A changed block is written elsewhere (and refrenced back by pointers). In a simple world. all writes would only be written to empty blocks, and only after the WAFL determines that they are no longer referenced by an map would they be released for reuse. So in short as long as there is a snapshot map, filesystem map, or even a lun map holding onto an pointer, the data won't be lost or overwritten.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;PRE __jive_macro_name="quote" class="jive_text_macro jive_macro_quote"&gt;&lt;P&gt;1. Now will the snap we took before get these changes or is it necessary to take snaps everytime there is a change in the LUN?&lt;/P&gt;&lt;/PRE&gt;&lt;P&gt;no the underlying snap is always representative of when the snap was taken, no changes, adds or deletes in subsequent snaps or the current volume are seen between snaps&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;PRE __jive_macro_name="quote" class="jive_text_macro jive_macro_quote"&gt;&lt;P&gt;2. What if the data itself is lost in the LUN?&lt;/P&gt;&lt;/PRE&gt;&lt;P&gt;A snapshot (if any exist) would have a previous copy of the data in the LUN&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;PRE __jive_macro_name="quote" class="jive_text_macro jive_macro_quote"&gt;&lt;P&gt;What is the point in having the data pointers when recovery isn't possible when the actual data itself is lost ??&lt;/P&gt;&lt;/PRE&gt;&lt;P&gt;As long as there are still pointers, the data wont be released and would be recoverable &lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Wed, 20 Feb 2013 01:17:15 GMT</pubDate>
    <dc:creator>AWOODWARD</dc:creator>
    <dc:date>2013-02-20T01:17:15Z</dc:date>
    <item>
      <title>Snapshots</title>
      <link>https://community.netapp.com/t5/ONTAP-Discussions/Snapshots/m-p/24543#M5781</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 05 Jun 2025 06:09:56 GMT</pubDate>
      <guid>https://community.netapp.com/t5/ONTAP-Discussions/Snapshots/m-p/24543#M5781</guid>
      <dc:creator>RAHULMG05</dc:creator>
      <dc:date>2025-06-05T06:09:56Z</dc:date>
    </item>
    <item>
      <title>Re: Snapshots</title>
      <link>https://community.netapp.com/t5/ONTAP-Discussions/Snapshots/m-p/24548#M5783</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;The NetApp is based on the WAFL (Write Anywhere File Layer) at any given time a file or object is stored via a map of the blocks on the underlying WAFL filesystem. When you make a change to the object the changed block(s) are written into that map. In a heavily simplified example a snapshot is simply a copy of that map at a given time. If blocks subsequently change, there are stored in the current object map. If blocks haven't changed changed than the two maps would be identical in contents. If one block is released in the current map the snapshot would still retain it.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Space wise, a snapshot is a static reference to the blocks on the underlying filesystem. This would effectively make those blocks read-only. A changed block is written elsewhere (and refrenced back by pointers). In a simple world. all writes would only be written to empty blocks, and only after the WAFL determines that they are no longer referenced by an map would they be released for reuse. So in short as long as there is a snapshot map, filesystem map, or even a lun map holding onto an pointer, the data won't be lost or overwritten.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;PRE __jive_macro_name="quote" class="jive_text_macro jive_macro_quote"&gt;&lt;P&gt;1. Now will the snap we took before get these changes or is it necessary to take snaps everytime there is a change in the LUN?&lt;/P&gt;&lt;/PRE&gt;&lt;P&gt;no the underlying snap is always representative of when the snap was taken, no changes, adds or deletes in subsequent snaps or the current volume are seen between snaps&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;PRE __jive_macro_name="quote" class="jive_text_macro jive_macro_quote"&gt;&lt;P&gt;2. What if the data itself is lost in the LUN?&lt;/P&gt;&lt;/PRE&gt;&lt;P&gt;A snapshot (if any exist) would have a previous copy of the data in the LUN&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;PRE __jive_macro_name="quote" class="jive_text_macro jive_macro_quote"&gt;&lt;P&gt;What is the point in having the data pointers when recovery isn't possible when the actual data itself is lost ??&lt;/P&gt;&lt;/PRE&gt;&lt;P&gt;As long as there are still pointers, the data wont be released and would be recoverable &lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 20 Feb 2013 01:17:15 GMT</pubDate>
      <guid>https://community.netapp.com/t5/ONTAP-Discussions/Snapshots/m-p/24548#M5783</guid>
      <dc:creator>AWOODWARD</dc:creator>
      <dc:date>2013-02-20T01:17:15Z</dc:date>
    </item>
  </channel>
</rss>

