SnapVault alternative?

[tyrone_owen_1]

Hi,

ONTAP 9.6

I'm currently using the following solution:

• Async SnapMirror A => B
• SnapVault A => C

No issues here with maintaining SV relationships when I fail over from A to B and B to A. However, I want to introduce SnapMirror Synchronous. I can do this:

• SnapMirror Synchronous A => B
• SnapVault A => C

But every time I fail over from A to B and B to A, I will have to re-establish and re-baseline all of my SV relationships due to the fact that SM-S does not replicate the baseline snapshot.

Is anyone using a non-NetApp alternative that will fit into the solution which will copy file data from the primary (A or B) down to C? My plan is to then use local snapshots on C to maintain the required retetnion.

• SnapMirror Synchronous A => B
• Non-NetApp Alternative? A => C

Thanks

[GidonMarcus]

Hi

Careful with 3rd party vendor - some of them will use NDMP which i believe not supported. you need something that is purely file based.

• Tape backup or restore using dump and SMTape on the destination volume

• Tape based restore to the source volume

https://library.netapp.com/ecm/ecm_download_file/ECMLP2811525

How about just enabling AGGR dedup on the dest, and always maintain the two relationships?

Another idea i had is to maybe put another layer on top of the volume, like an ONTAP select (which will have the snapvault out). or a windows file server/cluster that will be backed up by traditional backup software you maybe already have...

Also - Just wondering also, why are you avoiding metrocluster over IP? cost?

Sorry if it's not really answering your question - just thinking out loud.

[tyrone_owen_1]

Thanks for the reply

Why SnapVault works so well is related to the data set, i.e. lots of small files, so traditional methods of backup are not really a workable option

I've looked at MetroCluster, however cost and complicaiton of changing the current solution is a bit of a blocker.

I'm not sure how maintaining two copies of the data set would work if you think through the failover scenarios.

I'm not too familiar with ONTAP Select, how that fit into the solution?

[GidonMarcus]

Hi

So about the two relationship. i didn't try it - and never worked on Cdot sync volumes. However, reading in the docs, you are allowed to snapvault from the source, and allowed to cascade the dst to snapvault.  so i assume you can have two relationships going to the 3rd cluster. Having Aggregate level deduplication - will assure that you minimize the space loss of having the duplicate dataset. 

As for the failover scenario - for my understanding, you will maintain the original reference snapshots on each Sync volume regardless of it's state  (broken, reversed or active)- so you should be able to resume the snapvault at any given time from both volumes once they are online.

As for ONTAP select, this is ONTAP virtual machine running on VMWare, but can be stored on your physical ONTAP. it was just a long shot idea, along with the Windows/linux VM in case you already have the virtualization and backup facilities.

Now thinking on this all - I really suggest taking it to NetApp/partner, and see what they see the best option for you. I'm pretty sure a 3rd party will need to be file based, and i agree with you this is not ideal at all (for the backup itself - and more important for a restore) .

[tyrone_owen_1]

Thanks for your time. I have spoken to NetApp, which is why I am looking for a recommedation on an alternative approach, i.e. a reliable and efficient file sync method.

SM-S does not replicate scheduled, manual or application (SnapCenter/SnapManager) triggred snapshots, this includes async SM or SV baseline snapshots. So every time you fail over to the destination SM-S volume, like in a DR, in order to maintain SV you would have to complete a new baseline transfer.

Thanks

[GidonMarcus]

i think it's incorrect for the two relationship scenario i suggested. in this case i don't see why re-baseline will be required. snapshots will be maintained on the src and dst at any time (different snapshots - not the same one) 

[tyrone_owen_1]

Perhaps I'm misunderstanding your solution, or you are misundertsanding SM-S in ONTAP 9.5/9.6. In this scenario (ONTAP 9.6):

•  A -> B SM-S
•  A -> C SnapVault

If you lose 'A' (SV source / SM-S source) and run from the SM-S destination  'B' (new SV source), the base snapshot required to maintain the SV relationship to 'C' is not present in 'B'. This is because SM-S does not replicate the SV baseline snapshot. You have to re-baseline from 'B' to 'C'.

It's the same in the scenario below for async SM, the base snapshot is not replicated by SM-S, so to maintain the async to C you would need to baseline the whole thing:

•  A -> B SM-S
•  A -> C Async SM

If you fail from A to B, you lose the async relationship to C. If you fail from A to C, B becomes redundant.

[GidonMarcus]

Hi.

i think we still not aligned. The idea is:

A ----------------- Ca-\
|         A-Sync        \
|                        \
|  SM                     \  Single Physical Copy
| Sync                    /    With AGGR Dedup
|                        /
|         A-Sync        /
B ----------------- Cb-/

At any given time you have two separate set of snapshots.

The one on A that sync to Ca.

And the one on B that sync to Cb

if A going down for a week - the base snapshot used to Ca is kept.

After a week ahe A<>B SM sync is re-syncing, and a new snapvault from A>Ca is running. it will create new snapshot and replicate the changes happened on the volume from the last snapshot happen on A.  (regardless to hat happen on B on that timeframe - in Snapvault perspective it was just been changes on the live file system between the old snapshot to the new...)

Same if B going offline.

In this design - you never cross the Cx volumes from A to B. they just stop sync every time A<>B SM sync get broken. and resume when it's back online, in this case i don't think you'll ever need to do a re-baseline. Unless you for some reason loosing the A/B volumes or the base snapshot kept on A/B.  (and again - re base line will be storage efficient due to AGGR dedup, so the only loss is bandwidth)

[tyrone_owen_1]

OK, I see what you are saying.

If you lose A or B, you are still in the realms of having to re-baseline Ca or Cb becasue losing A or B means losing the base snapshot in the source, however where you gain in this model is that Ca and Cb will benefit from aggregate deduplication so there is no negative impact on capacity.

Let's say for example I lose A and have to re-baseline to Ca, I was under the impression that I also lose the snapshots that I want retained at Ca to support the SLA for snapshot retention.

---

@GidonMarcus wrote:

if A going down for a week - the base snapshot used to Ca is kept.

---

Is that really the case if you SM-S (re)sync B to A?

[GidonMarcus]

---

@tyrone_owen_1 wrote:

Is that really the case if you SM-S (re)sync B to A?

---

i don't really know - never tested it. just had a read. Worth doing a dry test on a new volume or ask NetApp to confirm. .

---

@tyrone_owen_1 wrote:

Let's say for example I lose A and have to re-baseline to Ca, I was under the impression that I also lose the snapshots that I want retained at Ca to support the SLA for snapshot retention.

If you loss (not temporarily stop) vol A and re baseline Ca you would loss Ca snapshots. but you will have the Cb snapshots.  and if you really want - You can keep the Ca legacy volume, and just baseline to Ca1 until the retention of Ca snapshots are expired.  

[tyrone_owen_1]

I'm still thinking a third party option would be cleaner. I will have no concern over re-baseline activities, or over having to manage retention on volumes which are no longer subject to SV/SM relationships.

Good conversation though - thanks