ONTAP Discussions
ONTAP Discussions
Hi,
I am looking for advice and confirmation as to whether this is possible. Here is our current setup.
Primary Site
1x FAS8020 - Test_Volume
DR Site
1x FAS8020 - Test_Volume_sm & Test_Volume_sv
The problem we have with the above setup, is that both the sm and sv at DR have Test_Volume at Primary as the source volume so although this works exactly how we want, it means that the source volume data is sent across the WAN twice. The source volume retains minimal data for example, 4 hourly, 4 daily, 4 weekly & 1 monthly. The vault on DR however stores 10 hourly, 31 daily, 5 weekly, 12 monthly.
To try and solve the issue of duplicating traffic across the WAN I tried amending the vault relationship so that the source volume was the destination volume for the mirror (Test_Volume_sm). This would then create a snapshot however this would be labelled as snapmirror and would not allow us to have the flexibility in configuring keeping hourly, daily, weekly backups. We could only keep a set number of Snapmirror backups.
The original snapshots are created/configured within NetApp VSC 6.0 as it is easier/quicker to restore and we would like to keep it that way. Our reseller confirmed that doing Source-Mirror-Vault allows a snapshot to be created but unfortunatly doesnt follow the naming convention of the VSC snapshots (Hourly, Weekly etc). They did however say that If i amended the setup to perform a SnapMirror of the SnapVault that should work.
I am now a bit stuck as I have created my Vault based on the Primary volume being the source volume and this works, retaining snapshots for a longer period of time. Unfortunately (unless i am doing something wrong) I can't seem to be able to snapmirror the snapvault using the snapvault volume as the source because it is a DP volume.
I wondered if someone has any ideas/solutions to get the results that we want? Our reseller also said that in ONTAP8.3 SnapVault has been changed so that we can configure our own labels (instead of just sm_created) so our original setup would work however I havent come across this in the release notes???
Solved! See The Solution
Yes, I used CLI. I took a quick look, and System Manager does not offer e.g. policy type selection, but when you create Vault policy you get type=vault. I did not get any error when creating SnapVault relationship. It is possible that issue you had was with System Manager itself. Yes, both volumes in SnapVault relationship are of type DP.
... I made a quick test and yes, System Manager (in 8.3) still does not allow selecting another DP volume as source for Vault. I guess you will need to learn a couple of commands.
Now when we know that documentation is incorrect, it is quite likely that all of this is already possible in 8.2. Looks like LoD still offers 8.2 lab; I'll get a look.
... No, it does not work in 8.2.x. What you can do, is explicitly transfer named snapshots, like
snapmirror update ... -source-snapshot your-smvi-snapshot-name
That works. Of course it means a bit of scripting around it, but it porvides workaround in case you cannot update to 8.3 for whatever reasons.
Sorry I should have mentioned that we are using cluster mode and are currently version 8.2.3.
I have been able to vault from a mirror however it does not use custom labels so we arent able to take hourly, daily backups etc. Also I believe that the snapshot that it takes is not an smvi snapshot like the source/mirror snapshots so as a result it wouldn't be as quick to restore from as the smvi snapshots are.
Ideally we either just want the Vault to pull the smvi snapshots from the mirror volume and retain for a longer period or vice versa in that the mirror pulls through smvi snapshots from the Vault and we can configure that to retain less copies than the Vault.
I'm afraid I do not see where the problem is. SnapMirror is one-to-one copy of source volume. If you have SnapVault configuration from source volume you can copy exactly the same snapshots (that are replicated to destination SnapMirror volume) from SnapMirror destination. May be if you show your current configuration for SnapMirror and SnapVault it would be easier to understand.
Hi.
I think you should SnapVault your SnapMirror exisiting copy. not vice vera as you try to do.
i don't get the point of view of your resaller. (maybe i'm missing some aspect related to VSC)
Ideally, you will want it to be:
Main DC-short term snapshots > DR/Local backup-short term snapshots (snapmirror) > remote backup-long term snapshots (snapvault)
You need to remember what each of these copies will allow you to do.
SnapmMirror:
* Will alow you to do a restore, and use locally as read+write copies on your destnation (as a DR site for example of directly mound the data)
SnapVault:
* Will allow you to delete the baseline snapshoot from your source(s), and therefor save space on your source(s).
* Maintain read only 'archive' backup on the snapvaulted copy. this in case a restore (to one of the sources or new machine) is needed.
G
Thank you both GM and Aborzenkov for getting back to me, appreciate it.
Yes orginally that's how I had it configured and how I assumed it should be: source > sm > sv. I have read a lot of NetApp documenation that says this is correct and possible. I'm not sure if we are having the problems because the SM and SV are on the same FAS at the same site?
Our source volume at HQ (Test_volume) contains, as you mentioned, the short term smvi snapshots (4 Hourly, 4 daily, 4 weekly) this was then in a snapmirror to DR where it replicated the snapshots to a volume called test_volume_sm.
Its after that, that I am having issues. I want my SV to use the SM (on the same FAS, same site) as it's source volume, however using labels, i want my SV to hold onto 10 hourly, 31 daily, 5 weekly snapshots.
When I created the SV (using the SM as the source volume) the smvi snapshots changed name and instead i was getting 1 snapshot called snapmirror.---- Because of this I was unable to pull through any hourly snapshots and these snapshots were not smvi snapshots. I read that the Vault would use a hidden label called sm_created however this doesnt allow me to configure hourly, daily, weekly jobs, it just allows me to specify say 50 snapshots and that would take 1 a day until it reaches the 50 threshold.... if that makes sense?
As you mentioned G, the mirror is purely for if HQ became completely unusable so to speak. The source smvi snapshots will be used for short term restoring purposes and then its the Vault which will be used for long term restore jobs.
At the minute it seems I have 2 options 1) have it working the way I want, but both the mirror and vault need to use HQ Test_volume as the source, meaning duplication of data across the WAN or 2) Have either a working mirror or working vault. If no other options were available we would have to go with option 1 as we require both a working mirror and vault. We were just hoping we could avoid duplication of data across the WAN.
OK, I see the problem. Well, NetApp documentation for cDOT is extremely vague. Both 8.2 and 8.3 allow you to define snapshot policies with explicit snapmirror labels. OTOH both 8.2 and 8.3 state that
Only these [sm_created] Snapshot copies are replicated from the mirror to the SnapVault backup.
But then again - 8.3 defines three different types of snapmirror policies - async-mirror, mirror-vault and vault. The first two always include sm_created rule that cannot be removed; the latter does not have sm_created rule by default which makes me believe that in this case it is possible to transfer only named snapshots. Which of course requires as prerequisite that snapmirror labels are replicated from source to destination by SnapMirror (and NetApp is silent on this).
I think your olnly option is to test it 🙂 Use simulator if you can; otherwise speak with your reseller and ask them to setup demo environment so you could test it. It does not really take long. Do you have access to LoD (Lab on Demand) by any chance?
If you got any results I appreciate if you could post them. If I get time I may try to quick test it; I'll update it then.
OK, I can confirm that in 8.3 you can create SnapVault policy that will transfer only named snapshots from SnapMirror destination. Here is configuration:
cluster2::> snapmirror show -fields source-path,destination-path,type,policy source-path destination-path type policy ----------------- ---------------- ---- -------------------- svm_dst1:smv_dst1 svm_dst1:vault XDP Test_Named_Snapshots svm_src1:snap_src1 svm_dst1:smv_dst1 DP MirrorAllSnapshots 2 entries were displayed. cluster2::> snapshot policy show -vserver cluster2 -policy -policy -policy-owner cluster2::> snapmirror policy show Test_Named_Snapshots Vserver Policy Policy Number Transfer Name Name Type Of Rules Tries Priority Comment ------- ------------------ ------ -------- ----- -------- ---------- cluster2 Test_Named_Snapshots vault 2 8 normal - SnapMirror Label: label1 Keep: 15 label2 25 Total Keep: 40 cluster2::> snapshot show -vserver svm_dst1 -volume vault ---Blocks--- Vserver Volume Snapshot Size Total% Used% -------- -------- ------------------------------------- -------- ------ ----- svm_dst1 vault snap_src1 160KB 0% 40% label1.1 124KB 0% 34% label2.1 124KB 0% 34% snapmirror.03770f75-296f-11e4-8232-005056011732_2147484674.2015-07-17_074500 92KB 0% 28% 4 entries were displayed.
So I have SnapMirror from another SVM on another cluster and SnapVault to the second volume in the same destination SVM. SnapVault has policy that transfers only named snapshots. Now try to create a couple more and update destinations.
cluster1::> snapshot create -vserver svm_src1 -volume snap_src1 -snapshot label1.one-more-snapshot -snapmirror-label label1 cluster1::> snapshot create -vserver svm_src1 -volume snap_src1 -snapshot some-other-snapshot -snapmirror-label label2 cluster1::> snapshot show -vserver svm_src1 -volume snap_src1 ---Blocks--- Vserver Volume Snapshot Size Total% Used% -------- -------- ------------------------------------- -------- ------ ----- svm_src1 snap_src1 snap_src1 160KB 0% 14% daily.2014-11-08_0010 284KB 0% 23% weekly.2014-11-23_0015 352KB 0% 27% weekly.2014-11-30_0015 272KB 0% 22% daily.2014-12-03_0010 220KB 0% 18% daily.2014-12-04_0010 112KB 0% 10% hourly.2014-12-04_1205 88KB 0% 8% hourly.2014-12-04_1305 84KB 0% 8% hourly.2014-12-04_1405 84KB 0% 8% hourly.2014-12-04_1505 88KB 0% 8% hourly.2014-12-04_1605 184KB 0% 16% hourly.2015-07-17_0705 104KB 0% 10% label1.1 88KB 0% 8% label2.1 84KB 0% 8% snapmirror.03770f75-296f-11e4-8232-005056011732_2147484674.2015-07-17_074500 84KB 0% 8% snapmirror.03770f75-296f-11e4-8232-005056011732_2147484674.2015-07-17_080000 92KB 0% 9% ---Blocks--- Vserver Volume Snapshot Size Total% Used% -------- -------- ------------------------------------- -------- ------ ----- svm_src1 snap_src1 label1.one-more-snapshot 92KB 0% 9% some-other-snapshot 64KB 0% 6% 18 entries were displayed. cluster2::> snapshot show -vserver svm_dst1 -volume smv_dst1 ---Blocks--- Vserver Volume Snapshot Size Total% Used% -------- -------- ------------------------------------- -------- ------ ----- svm_dst1 smv_dst1 snap_src1 160KB 0% 14% daily.2014-11-08_0010 284KB 0% 22% weekly.2014-11-23_0015 352KB 0% 26% weekly.2014-11-30_0015 272KB 0% 22% daily.2014-12-03_0010 220KB 0% 18% daily.2014-12-04_0010 112KB 0% 10% hourly.2014-12-04_1205 88KB 0% 8% hourly.2014-12-04_1305 84KB 0% 8% hourly.2014-12-04_1405 84KB 0% 8% hourly.2014-12-04_1505 88KB 0% 8% hourly.2014-12-04_1605 184KB 0% 16% hourly.2015-07-17_0705 104KB 0% 10% label1.1 88KB 0% 8% label2.1 84KB 0% 8% snapmirror.03770f75-296f-11e4-8232-005056011732_2147484674.2015-07-17_074500 84KB 0% 8% snapmirror.03770f75-296f-11e4-8232-005056011732_2147484674.2015-07-17_075500 96KB 0% 9% ---Blocks--- Vserver Volume Snapshot Size Total% Used% -------- -------- ------------------------------------- -------- ------ ----- svm_dst1 smv_dst1 snapmirror.03770f75-296f-11e4-8232-005056011732_2147484674.2015-07-17_080000 0B 0% 0% 17 entries were displayed. cluster2::> snapmirror update -destination-path svm_dst1:smv_dst1 Operation is queued: snapmirror update of destination "svm_dst1:smv_dst1". cluster2::> snapshot show -vserver svm_dst1 -volume smv_dst1 ---Blocks--- Vserver Volume Snapshot Size Total% Used% -------- -------- ------------------------------------- -------- ------ ----- svm_dst1 smv_dst1 snap_src1 160KB 0% 14% daily.2014-11-08_0010 284KB 0% 22% weekly.2014-11-23_0015 352KB 0% 26% weekly.2014-11-30_0015 272KB 0% 22% daily.2014-12-03_0010 220KB 0% 18% daily.2014-12-04_0010 112KB 0% 10% hourly.2014-12-04_1205 88KB 0% 8% hourly.2014-12-04_1305 84KB 0% 8% hourly.2014-12-04_1405 84KB 0% 8% hourly.2014-12-04_1505 88KB 0% 8% hourly.2014-12-04_1605 184KB 0% 16% hourly.2015-07-17_0705 104KB 0% 10% label1.1 88KB 0% 8% label2.1 84KB 0% 8% snapmirror.03770f75-296f-11e4-8232-005056011732_2147484674.2015-07-17_074500 84KB 0% 8% snapmirror.03770f75-296f-11e4-8232-005056011732_2147484674.2015-07-17_080000 92KB 0% 9% ---Blocks--- Vserver Volume Snapshot Size Total% Used% -------- -------- ------------------------------------- -------- ------ ----- svm_dst1 smv_dst1 label1.one-more-snapshot 92KB 0% 9% some-other-snapshot 68KB 0% 6% snapmirror.03770f75-296f-11e4-8232-005056011732_2147484674.2015-07-17_080349 0B 0% 0% 19 entries were displayed. cluster2::> snapshot show -vserver svm_dst1 -volume vault ---Blocks--- Vserver Volume Snapshot Size Total% Used% -------- -------- ------------------------------------- -------- ------ ----- svm_dst1 vault snap_src1 160KB 0% 40% label1.1 124KB 0% 34% label2.1 124KB 0% 34% snapmirror.03770f75-296f-11e4-8232-005056011732_2147484674.2015-07-17_074500 92KB 0% 28% 4 entries were displayed. cluster2::> snapmirror update -destination-path svm_dst1:vault Operation is queued: snapmirror update of destination "svm_dst1:vault". cluster2::> snapshot show -vserver svm_dst1 -volume vault ---Blocks--- Vserver Volume Snapshot Size Total% Used% -------- -------- ------------------------------------- -------- ------ ----- svm_dst1 vault snap_src1 160KB 0% 40% label1.1 124KB 0% 34% label2.1 124KB 0% 34% label1.one-more-snapshot 124KB 0% 34% some-other-snapshot 124KB 0% 34% snapmirror.03770f75-296f-11e4-8232-005056011732_2147484674.2015-07-17_080349 84KB 0% 26% 6 entries were displayed. cluster2::>
I did not show buf if I create snapshots without snapmirror label they are not trasnferred to vault (they of course are transferred to SnapMirror destination).
That's great thank you very much Aborzenkov.
From what you have listed there that is exactly what we are hoping to do.
So where you had label1 and label2, I could simply have my hourly (10), daily (31) and weekly (5) and that would pull through the snapshots with those labels and ignore any that don't match those labels.
This may seem like a daft question but I take it that you created your test volume, mirror/vault and label within the command line interface? I am able to configure the exact same within OnCommand Manager aren't I? (sorry if that is a very obvious question, still very new to the infrastructure)
I take it you didn't get any alerts or errors when creating the Vault, using the source as the mirror destination? In 8.2 I have always had the error that in order to create the Vault relationship, the source volume must be a rw volume. However as i want to use the Mirror destination as the source, that is already a DP volume so it doesnt normally show up? I take it you didn't have this issue?
Thank you very much for your help so far you have already cleared up a number of points which makes things clearer for us
Yes, I used CLI. I took a quick look, and System Manager does not offer e.g. policy type selection, but when you create Vault policy you get type=vault. I did not get any error when creating SnapVault relationship. It is possible that issue you had was with System Manager itself. Yes, both volumes in SnapVault relationship are of type DP.
... I made a quick test and yes, System Manager (in 8.3) still does not allow selecting another DP volume as source for Vault. I guess you will need to learn a couple of commands.
Now when we know that documentation is incorrect, it is quite likely that all of this is already possible in 8.2. Looks like LoD still offers 8.2 lab; I'll get a look.
... No, it does not work in 8.2.x. What you can do, is explicitly transfer named snapshots, like
snapmirror update ... -source-snapshot your-smvi-snapshot-name
That works. Of course it means a bit of scripting around it, but it porvides workaround in case you cannot update to 8.3 for whatever reasons.
Sorry for the delay in getting back to you(been on annual leave).
That's great thanks for all your help and support and also the testing you did. We are in the process of getting a new WAN link which will have increased speeds so i think the short term measure will be to put up with the duplication on 8.2.1 for a couple of weeks whilst we upgrade to 8.3
Beforehand I had only been told verbally that it was possible in 8.3 but thanks to your steps at least now I know the process we will need to follow and also that it cannot be done in SystemManager.