NetApp solution with Zero RPO for mission-critical volume

[Jerry2]

Hi there,

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?

[SpindleNinja · Accepted solution]

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.

Here's more detail from the docs:    

• Sync mode

  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.

  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.

• StrictSync mode

  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 InSync status. If the primary storage fails, application I/O can be resumed on the secondary storage, after failover, with no loss of data.

  In StrictSync mode RPO is always zero, and RTO is very low.

[paul_stejskal]

Both are synchronous, just as @SpindleNinja mentioned one fences source side i/o and the other doesn't if the data cannot be written to destination in a timely fashion.

[Guss]

NS0-527 😉