I imported an external SnapVault relationship into a dataset. I later removed the relationships from the dataset and made them external again.
The first odd thing I noticed was when I removed the relationships from the dataset. Protection Manager said it was going to delete the relationships (!!!!). dpReaperCleanupMode is set to Orphans. It is my understanding that a setting of "Orphans" will only delete orphaned relationships that had never been imported into a dataset. However, in this case it deleted my manually-created SnapVault relationship that was imported into and exported out of my Dataset. Thanks to Protection manager, there is no SnapVault relationships at this point.
So I manually re-created the exact same SnapVault relationship on the storage controller. After a period of time, my manually-created SnapVault relationship disappears. I suspect that Protection Manager saw the exact same SnapVault relatiopnship that it had deleted previously and decided to delete it again.
First, why is Protection Manager deleteing this orphaned relationship that HAD been imported into a Dataset?
Second, why does Protection manager keep deleting the relationship when I manually re-create it on the controller? How do I prevent it from doing this for this external relationship?
I edited the dataset's primary physical resources and removed the qtrees for the desired relationships. I then edited the Dataset's secondary physical resources and removed the SV secondary volume.
NOTE: For these particular relationships, all the primary qtrees were SnapVaulting to the same secondary volume. The secondary volume was dedicated to these qtrees and nothing else. See earlier output of "dfpm relationship list -a". The secondary volume was chi-ntap-01:/cifs_vol_2
After removing them from the Dataset, Protection Manager moved those relationships to the External Relationships page. Shortly thereafter, the relationships were deleted by Protection manager.
When removing a relationship from a dataset (irrespective of the fact whether the relationship is imported or created by protection manager) always relinquish the relationship from the dataset, then remove the primary followed by the secondary members - so here are the brief steps:
Step - a: Relinquish the relationship from the dataset, so that protection manager can mark the relationship as external
Use the command: "dfpm dataset relinquish <secondary qtree or volume id>"
Step-b: Remove the primary member (just like what you did)
Step-c: Remove the secondary member (just like what you did)
If you follow these steps, PM would never delete the relationships and you don't have to worry about the dpReaperCleanUpMode option.
Interesting thread. I'm running into a similiar issue with one of my customers that is a bit confusing.
Is there any way if you did not dfpm relinquish as the first step to clean up after the fact when the datasets no longer exist? I'm seeing all of the deleted relationships with dfpm relationship list -a on my problem. But, every time we recreate the snapmirrors, within 24 hours or less, the relationships disappear and the snap mirror.conf is edit'd by PM and removes all reference relationships.
Repear is set to Orphan.
I'm looking to see if there is a deeper method to removing these orphans manually before Reaper comes along and whacks the relationship? Will a brandnew baseline with new volumes (same name) work? Because we're going across a WAN, I'm trying to avoid doing this unless absolutely necessary.
I'm hoping for a manual process involving dfpm commands. Relinquish doesn't find anything to remove when I give it the previously deleted paths (datasets are long gone)