What makes a LUN a LUN on WAFL? (out of curiosity)

[PROFESSORE79]

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

[marcusgross · Accepted solution]

Hi,

a LUN is represented as a file in a volume.  You can see the lun using priv set diag; ls /vol/$volume/(qtree)

The LUN is registered during creation in the filers repository. 

If you restore a LUN (as file) as writing it using some sort of copy process into the volume, you have to register the LUN to Ontap using lun create -f.

If you already have a FAS environent, I don't see any reasons not to use snapvault to protect data.

In your example, you clone the snapshot on the secondary side and map to the VM Cluster. Start the VMs on it, create a new datastore on the primary side and move the VMs online from Nearstore to primary storage.

Up and running in 10 minutes 😉

Marcus

[PROFESSORE79]

Thanks a lot, it is often the simple things that get missed  - "lun create" had that cling of "overwrite" in my ears, I was not aware that creation of LUNs can also be based on existing files. I only knew the way of creating LUNs from scratch preferrably in System Manager. I'll have to try that as an exercise some time.

So you know, I DO use all the plethora of SnapVault/SnapManager products there are, like SnapManager Hyper-V, Exchange and SQL and also a few OSSV agents. However, this issue arose during a crime investigation and having a backup-to-disk-to-tape strategy. I do not have sufficient disk space to retain snapshots for more than about half a year especially on CSV mirrors - where the higher capacity of our dedicated backup FAS is of no help.

If it had just been for a recent mailbox then mounting a snapshot using SnapDrive and using SMBR would have been a no-brainer - but not for data from 2016 😉

Regards, Markus