Data Backup and Recovery

SnapVault alternative?

tyrone_owen_1
5,094 Views

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

10 REPLIES 10

GidonMarcus
5,041 Views

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.

Gidi Marcus (Linkedin) - Storage and Microsoft technologies consultant - Hydro IT LTD - UK

tyrone_owen_1
5,036 Views

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
5,022 Views

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) .

Gidi Marcus (Linkedin) - Storage and Microsoft technologies consultant - Hydro IT LTD - UK

tyrone_owen_1
4,935 Views

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
4,888 Views

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) 

Gidi Marcus (Linkedin) - Storage and Microsoft technologies consultant - Hydro IT LTD - UK

tyrone_owen_1
4,855 Views

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
4,841 Views

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)

 

Gidi Marcus (Linkedin) - Storage and Microsoft technologies consultant - Hydro IT LTD - UK

tyrone_owen_1
4,831 Views

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
4,816 Views

@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.  

 

 

Gidi Marcus (Linkedin) - Storage and Microsoft technologies consultant - Hydro IT LTD - UK

tyrone_owen_1
4,617 Views

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

Public