Hi all,
again I have a question / problem regarding DFPM dynamic referencing, which still annoys me up to the current (5.1) version. This question came up at different customer installs.
Example: Assume a dataset with "Backup" (vault) policy. I configure one volume (which houses a couple of qtrees) as the primary ressource. PM "conforms" it, provisions secondary vol, and initializes a number of SnapVault relationships (one for each qtree plus one for non-qtree-data).
Work fine so far. After that the dynamic referencing works, so if customer adds another qtree to the primary vol (using system manager, CLI or the NMC Provisioning component), then a backup relationship is automatically created and monitored. Very nice.
However, the problem comes with "dynamic DEreferencing"... As an example I assume primary qtrees named qt1, qt2, qt3 and qt4. As soon as qt5 is created, dynamic referencing kicks in and protects this qtree. Fine.
But if one of these qtrees in being DELETED (e.g. by using system manager - even when using then Provisioning component in NMC), there is no automatic de-referencing.
Why is that? My customers sometimes archive / delete old shares / qtrees - yes they do 😉 some of them do it regulary 🙂
What happens then is:
- On next monitoring interval, DFM discovers that the qtree has been deleted, and marks it as deleted in the DB (without checking for dependent relationships)
- DFPM quietly "forgets" about the relationship, which it has once created.
- The relationship is silently removed from the dataset, and does not show up in external relationships (probably it cannot be mapped by DFM monitor because the primary qtree object is "marked deleted").
- However, both source and destination Filers still know about the relationship! "snapvault status" on both primary and secondary system still shows it. And they both have a common snapshot for it.
- There's no way from within OnCommand to "clean up" (or even "see") this relationship anymore. It just sits there on the Filers, gets old, and after weeks somebody notices the "too old snapshots" alert.
- A manual look into CLI or system manager then shows the reason: a "too old vault relationship"
My current workaround/cleanup method is:
- Do manual "snapvault release" for the deleted qtree on the source filer
- Delete old baseline snap on source if still there after release
- Do manual "snapvault stop" for the deleted qtree on the destination
- Delete old baseline snap if still there after stop
So:
How useful is dynamic referencig without dynamic DE-referencing??
How useful is a "unified" monitoring / backup system that does not clean up or even show backup relationships (which were created by itself) where the primary ressource has been deleted...?
My main question is:
Will that finally be fixed in OCUM 5.2 ??