Zerto and Netapp Snap Mirror

Hey Graham,

This would certainly work, but it might not be the most efficient way of achieving the goal. The biggest problem with this setup is that you would have 2 copies of the LUN in the DR site and you are replicating all of the data twice. 1 LUN would be for the Zerto replica data, already mounted by the ESXi hosts, the 2nd would be the replica snapshot LUN, not mounted by any ESXi hosts and simply used for long term backup. You also have the overhead of snapshots on the production VM LUNs in this scenario to be aware of. Quite often running multiple snapshots and dedupe on NetApp production LUNs is enough to kill the controllers and removing snapshots could give them enough capacity to not have to kill the dedupe.

If snapmirror is being used in combination with snapvault then this is still probably a good solution, despite the duplication of data. Zerto would only failover and use its own copy of the data, it will never use the snapmirror replicas.

My biggest problem with using snapshots on storage arrays for long term retention is portability. The storage vendors love them, but as a user you have to keep that storage array to keep your history. When it becomes end of life you are then locked-in to buying the same vendor storage or keep the old array going until the last backup has been expunged. I would therefore propose considering an alternative solution:

It would be far more efficient, and 100x more portable, to use the existing Zerto replica data to create scheduled offsite clones to a 2nd LUN (with dedupe enabled, presented to the ESXi hosts). Yes you are still using double the storage in the DR site, but with dedupe the 2nd LUN would only grow by the differences. The biggest benefits however would be portability, as you just have VMs in a datastore, and you wouldn’t be replicating all of the data twice. Offsite cloning in Zerto takes a copy of the entire VPG and creates full clones of VMs in the datastore from the checkpoint selected. If you use the “Automating Zerto Virtual Replication with PowerShell and REST APIs Whitepaper v2.0.pdf” I wrote, found in the “Technical Documentation” section on MyZerto, you can automate this process end to end, including email reports and automatically removing the VMs from the inventory. Couple this with extending the journal history to enable sufficient time for all the offsite clone jobs to complete and you have a simple, elegant, scalable and importantly transportable solution. I hope this helps and let me know if you have any further questions. Thanks,

Joshua

Btw I love that acronym. IHAC, took me a second but I may have to start using that! Thanks.