2018-05-17 08:04 AM - edited 2018-05-17 08:06 AM
this should be a rather easy question.
since I came to the conclusion : no it won't work.
scope/request is: Cluster>Cluster vol migrate
I should migrate DP date from one backup filer to the other, and preserve as most meta data as possible (snapshots, shares, xdp-snapmirror-relations)
Nice to have: snapvault(xdp)/snapvault(XDP) cascading.
but this is not supported
finally I came to the conclusion: I will reinitialize a new relationship.
-or do you know of any better solution?
perfect world scenario: vol move cluster > cluster.
request for enhancement: frame work for datamigration cluster to cluster (as old dpm)
information: snapmirror is not licensed
2018-05-17 10:31 AM
> vol move cluster > cluster.
I do not see this as a transparent operation in other method since the IP addresses associated with the mount would also need to move. What you expect to happen if volumes A and B were both mounted on 192.168.1.1 on your source clsuter and you did a cluster > cluster move for volume A?
2018-05-18 05:10 AM - edited 2018-05-18 05:46 AM
well I do have:
I have snapm xdp A > B
I want volume move from B > C
I want to have snapm xdp A > C (same relation as the former A > B)
2018-05-22 03:38 AM
Cascading the snapmirror/vault (xdp) finally did work. (maybe lack of vserver peers prevented the first try)
having now a snapmirror (XDP) A>B>C. phase: initializing...
after this I will dispose Cluster B, and rebuild all relations.
- still would be nice to have a tool set for this.
maybe some simple powershell scripts can do this.