Hi there,
out of curiosity and technical interest to understand our FAS2240/7-Mode 8.2.5 better, I have an intricate question based on an incident/problem I had.
I recovered 4 Exchange database LUNs in one go from tape via Backup Exec 20.3 to an empty NetApp volume I had specifically provisioned for this task. Thus I selected "different location" and - as a default - Backup Exec (and I) chose to "preserve directory structure".
After restore everything looked fine and dandy first - except the NetApp/System Manager denied to see/find the restored LUN files (named .lun). Offlining/onlining the volume to no avail.
I realized that Backup Exec re-created what were originally Qtrees as file system directories on the volume. Then I read in NetApp documentation that LUNs must be placed in the root of a volume or within a qtree.
Fine, I thought, but creating proper Qtrees and moving the LUN files there had no effect, offlining and onlining the volume again didn't help either.
Then I found this old Veritas support article: https://www.veritas.com/support/en_US/article.000036463
And low and behold, disabling the checkbox for directory structure (which now exists in Backup Exec, no Registry fiddling necessary) and restoring all files again to proper Qtrees directly worked flawlessly. LUNs could be seen and mapped afterwards. But I had to restore each LUN file separately to the Qtree of my chosing.
In my case it was manageable but just imagine you restore one or more super-large VM cluster LUNs accidentally walking into the same trap - what makes a NetApp think that a particular file is a LUN? Would there be any way in the CLI, diagnostics CLI or BSD system console to remedy such a situation and mark a file as LUN? Or is restoring "properly" the only solution?
Thanks and best regards
Markus