<?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: NetApp solution with Zero RPO for mission-critical volume in ONTAP Discussions</title>
    <link>https://community.netapp.com/t5/ONTAP-Discussions/NetApp-solution-with-Zero-RPO-for-mission-critical-volume/m-p/434019#M40430</link>
    <description>&lt;P&gt;Think of sync it as best effort, if it can't see the other side, it will still allow the application IO on the primary side, with strict it'll fail.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;A href="https://docs.netapp.com/us-en/ontap/data-protection/snapmirror-synchronous-disaster-recovery-basics-concept.html#modes-of-operation" target="_blank" rel="noopener"&gt;Here's more detail from the docs:&amp;nbsp; &amp;nbsp;&amp;nbsp;&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;&lt;P&gt;&lt;STRONG&gt;Sync mode&lt;/STRONG&gt;&lt;/P&gt;&lt;DIV class=""&gt;&lt;P&gt;In Sync mode, an I/O to primary storage is first replicated to secondary storage. Then the I/O is written to primary storage, and acknowledgment is sent to the application that issued the I/O. If the write to the secondary storage is not completed for any reason, the application is allowed to continue writing to the primary storage. When the error condition is corrected, SnapMirror Synchronous technology automatically resynchronizes with the secondary storage and resumes replicating from primary storage to secondary storage in Synchronous mode.&lt;/P&gt;&lt;/DIV&gt;&lt;DIV class=""&gt;&lt;P&gt;In Sync mode, RPO=0 and RTO is very low until a secondary replication failure occurs at which time RPO and RTO become indeterminate, but equal the time to repair the issue that caused secondary replication to fail and for the resync to complete.&lt;/P&gt;&lt;/DIV&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;&lt;STRONG&gt;StrictSync mode&lt;/STRONG&gt;&lt;/P&gt;&lt;DIV class=""&gt;&lt;P&gt;SnapMirror Synchronous can optionally operate in StrictSync mode. If the write to the secondary storage is not completed for any reason, the application I/O fails, thereby ensuring that the primary and secondary storage are identical. Application I/O to the primary resumes only after the SnapMirror relationship returns to the&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;InSync&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;status. If the primary storage fails, application I/O can be resumed on the secondary storage, after failover, with no loss of data.&lt;/P&gt;&lt;/DIV&gt;&lt;DIV class=""&gt;&lt;P&gt;In StrictSync mode RPO is always zero, and RTO is very low.&lt;/P&gt;&lt;/DIV&gt;&lt;/LI&gt;&lt;/UL&gt;</description>
    <pubDate>Wed, 13 Apr 2022 12:02:34 GMT</pubDate>
    <dc:creator>SpindleNinja</dc:creator>
    <dc:date>2022-04-13T12:02:34Z</dc:date>
    <item>
      <title>NetApp solution with Zero RPO for mission-critical volume</title>
      <link>https://community.netapp.com/t5/ONTAP-Discussions/NetApp-solution-with-Zero-RPO-for-mission-critical-volume/m-p/434017#M40429</link>
      <description>&lt;P&gt;Hi there,&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I have a question, if SnapMirror Synchronous in both StrictSync and Sync mode can ensure zero RPO. For StrictSync mode is it quit straightforward, but what about SnapMirror Synchronous in Sync mode? Does it depend on the snapmirror schedule?&lt;/P&gt;</description>
      <pubDate>Wed, 04 Jun 2025 10:02:04 GMT</pubDate>
      <guid>https://community.netapp.com/t5/ONTAP-Discussions/NetApp-solution-with-Zero-RPO-for-mission-critical-volume/m-p/434017#M40429</guid>
      <dc:creator>Jerry2</dc:creator>
      <dc:date>2025-06-04T10:02:04Z</dc:date>
    </item>
    <item>
      <title>Re: NetApp solution with Zero RPO for mission-critical volume</title>
      <link>https://community.netapp.com/t5/ONTAP-Discussions/NetApp-solution-with-Zero-RPO-for-mission-critical-volume/m-p/434019#M40430</link>
      <description>&lt;P&gt;Think of sync it as best effort, if it can't see the other side, it will still allow the application IO on the primary side, with strict it'll fail.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;A href="https://docs.netapp.com/us-en/ontap/data-protection/snapmirror-synchronous-disaster-recovery-basics-concept.html#modes-of-operation" target="_blank" rel="noopener"&gt;Here's more detail from the docs:&amp;nbsp; &amp;nbsp;&amp;nbsp;&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;&lt;P&gt;&lt;STRONG&gt;Sync mode&lt;/STRONG&gt;&lt;/P&gt;&lt;DIV class=""&gt;&lt;P&gt;In Sync mode, an I/O to primary storage is first replicated to secondary storage. Then the I/O is written to primary storage, and acknowledgment is sent to the application that issued the I/O. If the write to the secondary storage is not completed for any reason, the application is allowed to continue writing to the primary storage. When the error condition is corrected, SnapMirror Synchronous technology automatically resynchronizes with the secondary storage and resumes replicating from primary storage to secondary storage in Synchronous mode.&lt;/P&gt;&lt;/DIV&gt;&lt;DIV class=""&gt;&lt;P&gt;In Sync mode, RPO=0 and RTO is very low until a secondary replication failure occurs at which time RPO and RTO become indeterminate, but equal the time to repair the issue that caused secondary replication to fail and for the resync to complete.&lt;/P&gt;&lt;/DIV&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;&lt;STRONG&gt;StrictSync mode&lt;/STRONG&gt;&lt;/P&gt;&lt;DIV class=""&gt;&lt;P&gt;SnapMirror Synchronous can optionally operate in StrictSync mode. If the write to the secondary storage is not completed for any reason, the application I/O fails, thereby ensuring that the primary and secondary storage are identical. Application I/O to the primary resumes only after the SnapMirror relationship returns to the&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;InSync&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;status. If the primary storage fails, application I/O can be resumed on the secondary storage, after failover, with no loss of data.&lt;/P&gt;&lt;/DIV&gt;&lt;DIV class=""&gt;&lt;P&gt;In StrictSync mode RPO is always zero, and RTO is very low.&lt;/P&gt;&lt;/DIV&gt;&lt;/LI&gt;&lt;/UL&gt;</description>
      <pubDate>Wed, 13 Apr 2022 12:02:34 GMT</pubDate>
      <guid>https://community.netapp.com/t5/ONTAP-Discussions/NetApp-solution-with-Zero-RPO-for-mission-critical-volume/m-p/434019#M40430</guid>
      <dc:creator>SpindleNinja</dc:creator>
      <dc:date>2022-04-13T12:02:34Z</dc:date>
    </item>
    <item>
      <title>Re: NetApp solution with Zero RPO for mission-critical volume</title>
      <link>https://community.netapp.com/t5/ONTAP-Discussions/NetApp-solution-with-Zero-RPO-for-mission-critical-volume/m-p/434195#M40462</link>
      <description>&lt;P&gt;Both are synchronous, just as &lt;a href="https://community.netapp.com/t5/user/viewprofilepage/user-id/67570"&gt;@SpindleNinja&lt;/a&gt; mentioned one fences source side i/o and the other doesn't if the data cannot be written to destination in a timely fashion.&lt;/P&gt;</description>
      <pubDate>Tue, 19 Apr 2022 15:38:17 GMT</pubDate>
      <guid>https://community.netapp.com/t5/ONTAP-Discussions/NetApp-solution-with-Zero-RPO-for-mission-critical-volume/m-p/434195#M40462</guid>
      <dc:creator>paul_stejskal</dc:creator>
      <dc:date>2022-04-19T15:38:17Z</dc:date>
    </item>
    <item>
      <title>Re: NetApp solution with Zero RPO for mission-critical volume</title>
      <link>https://community.netapp.com/t5/ONTAP-Discussions/NetApp-solution-with-Zero-RPO-for-mission-critical-volume/m-p/442263#M41884</link>
      <description>&lt;P&gt;NS0-527 &lt;span class="lia-unicode-emoji" title=":winking_face:"&gt;😉&lt;/span&gt;&lt;/P&gt;</description>
      <pubDate>Wed, 08 Mar 2023 16:57:58 GMT</pubDate>
      <guid>https://community.netapp.com/t5/ONTAP-Discussions/NetApp-solution-with-Zero-RPO-for-mission-critical-volume/m-p/442263#M41884</guid>
      <dc:creator>Guss</dc:creator>
      <dc:date>2023-03-08T16:57:58Z</dc:date>
    </item>
  </channel>
</rss>

