Copy volume data to LUN on same filer

[FractalSystems]

I'm trying to copy a volume "/vol/Archive_chi" to a LUN (volume = /vol/ArchiveLUN_chi ; LUN = ArchiveLUN ; LUN PATH = /vol/ArchiveLUN_chi/ArchiveLUN).

I tried ndmpcopy /vol/Archive_chi /vol/ArchiveLUN_chi and ndmpcopy /vol/Archive_chi /vol/ArchiveLUN_chi/ArchiveLUN without any success.

I found snap-mirror/-vault to be to impractical in our current environment/setup.

I am now trying to use vol copy start /vol/Archive_chi /vol/ArchiveLUN_chi or vol copy start /vol/Archive_chi /vol/ArchiveLUN_chi/ArchiveLUN but those are erroring out with "Volume doesn't exist: /vol/ArchiveLUN_chi" and "Volume doesn't exist: /vol/ArchiveLUN_chi/ArchiveLUN" respectively.

I was able to get it only after using vol copy start Archive_chi ArchiveLUN_chi (volume to volume), but vol copy start Archive_chi ArchiveLUN or vol copy start Archive_chi ArchiveLUN_chi/ArchiveLUN (volume to LUN) I get "Volume doesn't exist:" error.

I've seen a variety of formats used online and in the KB. How can I copy a volume to a LUN? Which formatting should I use? I'm on 7-mode.

Any help is appreciated. Thanks

[bobshouseofcards · Accepted solution]

Just to be sure I understand what you are asking...

You have a volume "Archive_chi", that contains general file data shared out to users via CIFS/NFS.

You have/are trying to create a second volume "ArchiveLUN_chi" which will contain a LUN "ArchiveLUN".

You want to run a command on the controller to copy the files from the original volume into the LUN as a single unit (meaning the LUN is a single unit).

Just want to make sure I have your intent straight.

You can't do this at the NetApp controller itself, which is why your attempts to do this failed.  Accesses into a LUN require something to use the appropriate SCSI varient protocol to initiate block level reads and writes.  You will have to create the LUN, mount the LUN to a server/workstation as a disk, format the disk appropriately based on the OS of the server/workstation, access the shared files on the original volume, and start a manual copy using the external server as a conduit between the files on a share and the LUN.

In the NetApp WAFL file system, everything (even LUNs) are files.  LUNS generally are big files, but just files.  Data Ontap itself doesn't interpret the contents of the files directly.  Rather it creates/reads/writes/deletes/etc. blocks of the files in response to access protocol requests - SCSI via FC/iSCSI, CIFS, NFS, etc.  Other operations such as SnapMirror/FlexClone etc. work on either an entire volume or an entire file at a time (leaving out cDot subfile cloning for the moment).

So the idea that the controller can take a series of files and write them into a logical disk format with an OS specific file-system (like NTFS) that an external server can then treat as a disk image just doesn't exist.  You'll have to do this the brute force way.

[FractalSystems]

That's what I was afraid of. I have that all setup how you pictured it. I guess I'll just robocopy it over; amazing this feature doesn't exist.

Thanks for your insight.

[bobshouseofcards]

Yes it's in theory a doable thing but not very practical.  Remember that the controller doesn't know anything about things like NTFS in terms of direct implementation, nor would it want to.  That would require a lot of extra engineering for very little gain.  Everything is implemented on top of the WAFL file structure - all appearance as anything else is emulation.  So a CIFS share is NTFS semantics emulated on top of WAFL file layouts.  An NFS share is *nix style semantics, as extended through NFS, emulated on top of the WAFL flie layouts.  Same with LUNs - that's disk block semantics as implemented through the SCSI protocol set emulated on top of WAFL again.

The storage system is all about presentation to a consuming client and translating protocol requests into the most primitive file system constructs.  Interpretation of that presentation especially in the case of a LUN is 100% up to the client.  That's why you give a client a LUN - a set of raw blocks it can do with as it wishes.  If you started adding "internal" LUN functionality, where would it stop?  Support Windows NTFS as implemented on MBR, GPT, etc?  Any of the many of *NIX file systems?  Disk partitioning?  Logical volume formatting?  ESX VMFS?  If you started it for one system, every other supported system would want it.  And then of course you have to support it exactly as the manufacturer supports it...you'd be forever chasing bugs that are too rare a use case to justify the support expense and Data Ontap overhead.