We have a temp-cluster setup that mirrors volume from a primary-cluster, so we have a cluster peer etc..
We now want to move this temp-cluster to another location (which isn't the hard part, we have network etc. setup)
We then want to migrate the volumes from temp-cluster to a backup-cluster and then initialize backup-cluster up against primary-cluster and retire temp-cluster. AFAIK this should be a fairly trivial procedure? But I just want to make sure there isn't any gotcha's 🙂 As soon as snapmirror can find a common snapshot it should be able to re-sync... Because this is a fairly large ammount of data (not that many volumes) we plan to snapmirror from temp-cluster to backup-cluster while we continue the relation from temp-cluster to primary-cluster... So that we don't end up with a very large back-lock of snapshots 🙂
#Fooling around with SnapMirror...
austere tundra
dusty viper
Have you thought about snapmirror svm? I used that with a customer that had replication and it moved the replication also. May not work with luns. Something to look at
rocky osprey
Maybe try SVM migrate to get the workload from the temp cluster to the backup cluster: https://docs.netapp.com/us-en/ontap/svm-migrate/index.html
This also supports vols with SM relationships.
austere tundra
Have you thought about snapmirror svm? I used that with a customer that had repl...
Well we have a large flexgroup and afaik sm-svm not supported with that?
austere tundra
Hmm I might have missed a few "classes" in cluster peering 😉 After we physically moved the temp-cluster, we had to change the IP addresses for the cluster peering... which we just did with a "cluster peer modify...." on both ends... yet for some reason the temp-cluster keeps adding the old IP's as it's peers... (they are still in use on the primary-cluster so cannot remove them)... But I cannot seem to find anywhere that I can limit this? Maybe I need to delete the peering and re-create it? But I guess I then have to break the mirror? (btw. the snapmirrors are running OK even though the cluster peering is "partial")
austere tundra
Apparently there is a "difference" between the "Remote Intercluster Addresses" which are correct, and the "Active IP Address" where I can see more IP's which isn't reachable from this cluster...
I am trying to start a snapmirror, and I was able to create it, but as I try to init, after 4-5 mins. I get this SnapMirror Last Transfer Error: Failed to create snapshot snapmirror.807fe459-4b7e-11f0-a40b-00a098e12879_2150747145.2025-06-18_180530 on volume FS05-BACKUP:BG3DLOG_Archive_dest. (Relationship information has been updated and is being propagated. Wait a few minutes and try the command again.)
Last Transfer Error Codes: 6619937, 6619710"
And there is no snapshot created on the source... so it is correct.. but why not? 😉
I think the cluster peering is trying to use other intecluster lifs to communicate with... because cluster peer ping does not work, yet network ping -lif works fine... how to you control which lifs are trying to communicate with the other clusters?
native cloak
Remote intercluster Addresses = These are the IPs you configured when you created the cluster peer.
Active IP Address = These are the discovered remote IC LIFs of the peer cluster.
These should match because it means you're meeting the full-mesh cluster peer requirement which states that all IC LIFs in the IPSpace used for cluster peering must be able to communicate with all remote IC LIFs.
You cannot stop ONTAP from discovering all remote IC LIFs in the IPSpace used for peering.
The only way to segment IC LIFs for different peers is with IPSpaces.
https://kb.netapp.com/on-prem/ontap/DP/SnapMirror/SnapMirror-KBs/How_to_create_and_configure_Cluster_Peering_with_designated_InterCluster_LIFs_using_IPSpaces
austere tundra
Remote intercluster Addresses = These are the IPs you configured when you create...
I thankfully seem to have fixed it with creating some ipspaces. which seperates it...
Now my issue is that I need to snapmirror a FlexGroup snapmirror destination to another destination..., not a problem with a standard flexvolume, but apparently a flexgroup destination is read-only, so the snapmirror process is unable to create a common snapshot to start the transfer.. 😦 any idea how to fix that?
native cloak
Shouldn't be a problem if you're running 9.9.1+ everywhere. In a cascade, the B->C SnapMirror replicates existing Snapshots on B, rather than creating its own.
https://docs.netapp.com/us-en/ontap/flexgroup/create-snapmirror-cascade-fanout-reference.html
Oh and you can't use the GUI.
austere tundra
We are on 9.15+ 🙂 You are right about the GUI... no dice there... and I also cannot create a snapshot manually on the snapmirror destination which lead me to the conclution to why the snapmirror of the destination didn't work... 🙂 I will have a read of the document...
austere tundra
OK... looks promissing... but there are not examples 😉 Here is what I do... 1. Create the destination FlexGroup as a type DP... 2. Create a Protection Policy with "mirror all snapshots"... run snapmirror create with source and destination paths and the policy i created.. then run snapmirror initialize.. and it "starts" with "Transfering"... but as expected it never created any snapshot on the destination (because it is readonly)... and then fails with the error above... not sure what I am doing wrong here?
Never mind... we are pumping data now 😉
...is there any way to see a better progress when doing snapmirror with flexgroups? I can only see that it has created the snapshot on the source, but nothing on the destination.. also the "Total progress" jsut shows 0... The source FlexGroup consists of two volumes (I know it is not ideal) one is much larger than the other... is there a why to determine on which of the two destination "sub" volumes this will "land" ?
dusty viper
You might try using the “-expand” option with snapmirror show