ONTAP Discussions

Snapmirror destination, snapvault source and destination on same system

KEVINSNOOK
4,370 Views

We have two NetApp filers for our Exchange environment. One is working as our production filer and the other offsite snapmirror destination. We have a need to retain archived copies of data and the SnapVault product would suit our needs. I can;t work out how to get SnapMirror to work together with SnapVault. What I'm looking to do is use the snapmirror destination volume as a source for a SnapVault relationship and snap it to another volume on this second filer (i.e. the source and destination filer for the SnapVault is the same). Is this possible? I'm sure I did it before but I can;t remember how. Running Ontap 8.0.2 and I have SV Pri and SV_Sec licenses installed on our second filer.

1 ACCEPTED SOLUTION

aborzenkov
4,370 Views

I can’t comment on Protection Manager case (I guess you better ask this specific question on OnCommand forum); but I do not see how primary and secondary on the same system makes any difference in “real men CLI” case ☺

The main problem with SV from SM destination is that SM destination is read-only. So if you use named snapshot to setup SV schedule, this snapshot must be created on SM source. Or you can configure SV to always use the latest SM baseline snapshot for updates.

You say “I can't get the offsite filer to accept a command to create the sanpvault relationship”. Please copy and paste exact command invocation and output.

View solution in original post

5 REPLIES 5

aborzenkov
4,370 Views

TR-3487 gives detailed description how to protect SM destination with SV.

KEVINSNOOK
4,370 Views

Thanks but I've read that end-to-end. What is does not cover is having the primary and secondary on the same filer WITH snapmirror. I can't get the offsite filer to accept a command to create the sanpvault relationship and I can;t get Protection Manager to believe one system can be a primary and secondary for a snapvault backup - if I put it in as a primary it won;t allow me to put it in as a secondary and vice versa. Any clues?

aborzenkov
4,371 Views

I can’t comment on Protection Manager case (I guess you better ask this specific question on OnCommand forum); but I do not see how primary and secondary on the same system makes any difference in “real men CLI” case ☺

The main problem with SV from SM destination is that SM destination is read-only. So if you use named snapshot to setup SV schedule, this snapshot must be created on SM source. Or you can configure SV to always use the latest SM baseline snapshot for updates.

You say “I can't get the offsite filer to accept a command to create the sanpvault relationship”. Please copy and paste exact command invocation and output.

KEVINSNOOK
4,370 Views

Thanks. You led me to the right conclusion. I looked closely at the command on the destination to set up the SV relationship. I knew I'd got it working before so looked at my notes. There's a difference between:

snapvault start source:/vol/vol_name target:/vol/vol_name/qtree

and

snapvault start source:/vol/vol_name/- target:/vol/vol_name/qtree

The latter is the one to use - I assumed wrongly that specifying the volume is sufficient but it needs a qtree explicitly (although a volume is a qtree). The hyphen seems to say "use a qtree that is a volume".

Happy now......

KEVINSNOOK
4,370 Views

This relates to backing up "non-qtree data" as it is termed in SnapVault parlance.

What non-qtree data is:

Non-qtree data is any data on a storage system that is not contained in its qtrees.
Non-qtree data can include the following items:
  • Configuration and logging directories (for example, /etc or /logs) that are not normally visible to clients
  • Directories and files on a volume that has no qtree configured
Public