NetApp File Copy
It always comes up, how can I copy single files, or large areas directly from the NetApp console? Generally the answer comes back, you can’t, use RoboCopy or rsync or another file migration tool. However there are definitely ways of copying files around directly from the filer itself, and often this is the most efficient way of doing it! However, these aren’t the most intuitive or well documented commands.
There may be other methods, and if you have something you have used in the past or you know of, please feel free to share! Not all methods are suitable for all tasks, but each has it’s own individual uses.
ndmpcopy
This is often overlooked as a file / folder copy command, and is often just used to migrate entire volumes around. In fact it can be used to copy individual folders or filers around, and even better can be used to copy data to other filers! Make sure ndmp is enabled first (ndmpd on). The syntax is quite simple…
ndmpcopy /vol/vol_source_name/folder/file /vol/vol_dest_name/file
Just to break this down, we are choosing to copy a filer from “/vol/vol_source_name/folder” and we want to copy it into “/vol/vol_dest_name”. This isn’t too restrictive, we don’t have to keep the same path, and we can even copy things about in the same volume (such as copying things into QTrees if you need). You can copy things from an entire volume, to a single QTree, down to single folders way down in the directory tree. The only real restriction is you cannot use wildcards, and you cannot select multiple files to copy.
If you want to copy files from one filer to another, we simply extend this syntax…
ndmpcopy -sa <user>:<pass> -da <user>:<pass> source_filer:/vol/vol_source_name/folder/file destination_filer:/vol/vol_dest_name/file
Replace <user> and <pass> with the source filer (-sa) login and the destination filer (-da) login. Here we copy a single file from one location on one filer, to another on another!
We can also define the the incremental level of transfer. By default the system will do a level 0 transfer, but you can define to do a single level 1 or 2 incremental transfer. If the data has changed too much, or too much time has passed since the last copy, this may fail or may take longer than a clean level 0.
This can be very useful, and as the filer is doing this at block level, all ACL’s are completely preserved. Take care to enable that the security style is the same on the destination to prevent ACL’s from being converted however.
ONTAP 7.2.6.1 manual page for this can be found – http://now.netapp.com/NOW/knowledge/docs/ontap/rel7261/html/ontap/cmdref/man1/ndmpcopy.1.htm
mv
This is a “priv set advanced” command, and so apparently reserved for “Network Appliance personnel”. “mv” is very straight forward, give it a source and destination, and a single file will get moved. Remember this is a move, so it is not technically a file copy at all.
mv <file2> <file2>
flex clone
This is a real cheat, but a great cheat! You clone an entire volume based on a snapshot, then you split this volume off from the snapshot. This a great way of getting an entire volume copied with minimal disruption. The clone is almost immediately created, and can then be online and used live. The clone split operation happens in the background so you can move things and be live at the new location in very little time at all.
vol clone create new_vol -s volume -b source_vol source_snap
Where “new_vol” is the new volume you want to create, “-s volume” is the space reservation, “-b source_vol” is the parent volume that the clone will be based on and “source_snap” is the snapshot you want to base the clone on.
vol clone split start new_vol
Will then start the split operation on the “new_vol”
vol copy
Rather than a flex clone, if you haven’t got that licensed, you can do a full vol copy. This is effectively the same as a vol clone, but you need to do the entire operation before the volume is online and available. You need to create the destination volume first and then restrict it so that it is ready for the copy. Then you start the copy process.
vol copy start -s snap_name source_vol dest_vol
“-s snap_name” defines the snapshot you want to base the copy on, and “source_vol” and “dest_vol” define the source and destination for the copy. “-S” can also be used to copy across all the snapshots that are also included in the volume. This can be very useful if you need to copy all backups within a volume as well as just the volume data.
lun clone
If you need to copy an entire LUN, and again you haven’t got flex clone licensed, you can do a direct lun clone, and lun clone split. This is only really useful if you need a duplicate of the LUN in the same volume. It will create a clone based on a snapshot that already exists.
lun clone create clone_path -b parent_path parent_snap
“clone_path” being the new LUN you want to create, “parent_path” being the source LUN you want to clone from and “parent_snap” being a snapshot that already exists of the parent LUN. The you need to split the LUN to become independent with.
lun clone split start clone_path
SnapMirror / SnapVault
You can also use SnapMirror or SnapVault to copy data around. SnapMirror can be useful if you need to copy a large amount of data that will change. You can setup a replication schedule, then during a small window of downtime, you can do a final update and bring the new destination online.
dump and restore
This isn’t really a good way of copying files around, but it certainly a method. If you attach a tape device directly to the filer, you could do a dump, then a restore to a new location or filer. This can be the only method if you have a large amount of data to move to a new site, and no bandwidth or no way of having the 2 systems side by side temporarily.
Nice post, my situation is as follows:
I have one Volume with several qtree’s/ Lun’s for several SQL servers. I need to create seperate volumes for each server and then move the LUN’s from the current vol/qtree to the new volume minus the qtree’s. This is so my Volume restores will not affect every hosts in the Volume.
My question is what is the easiest and least evasive to the hosts solution to move the lun’s? I do have snap mirror.
Thanks,
K2
Hi buddy, glad you found the post useful.
Can I ask why you need to remove the QTree’s? Even if you don’t need to QTree’s, then they should cause no harm by simply being there.
Using the QTree’s, you could do a QTree SnapMirror of each one to it’s own volume. This would be the least disruptive as you could do a baseline, setup a short schedule, then when you are ready to move things across do a final update and then switch the servers across. If you shut down the servers, you should be able to re-map the LUNs to the same initiators with the same ID’s (make careful notes first) and the servers will be oblivous of any change. For SnapDrive connected hosts, re-create the CIFS shares, but this should be fine.
If you do want to get rid of QTree’s, then your options are limited. You could do a ndmpcopy of the LUNs themselves to their new locations. I did this recently for a customer and the job worked fine, however the customer was able to switch the LUNs offline prior to the copy.
Alternatively you could do a host based copy. Create an entire new LUN and then copy the data from the host. Possibly the most awkware way of doing things, but if there is any issues with your existing LUNs, this would be the cleanest.
You will need some sort of downtime, how long is impossible to tell without knowing the size and change rate of your data. I’d personally be inclined to go for an NDMPcopy. It should be incremental so long as you don’t leave too much time between the baseline and the final update. Perhaps do an NDMPcopy in the afternoon then shut the server down out of hours and do a second NDMPcopy (which should be an update, not full copy). I have done this trick a couple of times.
The total impact would then be minimised as you could move each LUN separately. This could take some time depending on how much data you have again.
Let me know how you get along, or if you have any follow up questions. Always happy to help.
Cheers!
@Chris Kranz
Hi,
I need to copy one large folder with lots of files in it (about 250GB) from one volume to another volume.
What would be the best way to go about it? I basically want the files to look at they did before the move if possible, i.e keep the datestamps etc the same.
I also have another folder of a similar size to move that contains MAC OS data and I’m worried that if I move that folder using Windows, it’ll cause issues with the MAC data.
Any suggestions?
Thanks,
Martin
Hi Martin,
For your uses, I’d probably recommend using ndmpcopy. This will copy the data at block level and then copy across all the filer pointers (including the ACL’s), so the data will be viewed identically from the client side. This would work for both the Windows and Mac data (any data in fact). You would need some level of downtime while you change the shares to the new destination. With CIFS shares just simply change the share location.
You could use robocopy, with /mir (there are others ways to achieve this too) and this should preserve all the dates and permissions, but I would prefer doing the copy directly at the filer level.
If the data is already in a specific volume or qtree, you could use snapmirror and this would be the most efficient, but as you said they are in folders, I reckon you’ll be best with an ndmpcopy.
Good article, but you missed one option. I’m using dd (dd if=/vol/… of=/vol/..) in privileged mode.
Regards,
Hi. Thanks for a nice review of various file copying options.
One thing that I would like to know is: How to copy/move cifs shares (say to another aggregate or filer?)
Is there not any better thing to do than to ndmpcopy the share folder to a new path and after that stop and recreate the share (on the new path?)?
Regards
Erling
If you edit the CIFS share config file you can make this a lot easier. Again, my preferred option here would be to SnapMirror to the new location, then when you’re ready to move, disable the CIFS share, break the SnapMirror and repoint the CIFS share. Optionally you could repoint the CIFS share first at which point it’ll be available, but read-only until you’ve broken the mirror. This would lead to very minimal outage.
The CIFS share config file is “/etc/cifsconfig_share.cfg”.
Thanks for feedback. I appreciate that. I also agree to the use of SnapMirror, but without that license (its not free!) we are left with more “primitive” copying, I’m afraid.
Regards
Erling
Great post,
If I had to replicate a fair amount of data (around 7-8TB) from one NetApp array to another in a different location (for a one time migration) over a small link (might only be 100BaseT) what would be the fastest way?
I was thinking of trying to connect the new NetApp to the same network as the current one locally via GigE to ’seed’ it with SnapMirror. Then separate them and re-synch the SnapMirror to catch up on deltas and then plan our cut over.
If standing up the new NetApp in the current data center is not an option, could I do a tape backup of the current NetApp and then tape restore to the new one and THEN SnapMirror the deltas? (seed with tape)? I think this would be an option.
Anyone know how SnapMirror (block based) would perform for a data copy vs. robocopy (file based) if the network and hardware were all the same? Just curious if using the same hardware and network if SnapMirror would be any faster than robocopy?
Thanks!
Sorry for the delay in getting back to your comment!
There’s a couple of ways to do this, you could actually completely cheat! You could add the new disks for the second filer onto the primary system, then do a local SnapMirror. This would copy at 2-4g, depending on your loop speed. Then remove the disks, change the ownership, and plug into the second system and ship out.
If that sounds a bit too tricky, then yes, a local gigabit connection and using SnapMirror should work well. We often do that when we have limited bandwidth or a large amount of data to be transferred.
You can use SnapMirror to tape, and that would give you the option to restore back to a second filer and then resync the changes.
SnapMirror would definitely be quicker than robocopy. The filer already has the ACL’s and the block changes indexed, so there would be no major file scanning, where-as robocopy would have to scan all the data and calculate the ACL’s.
I’m doing some recovery on a customers F820 with data ontap 7.0.3…
It has 2 aggregates, aggr0, and aggr1. aggr1 seems to be corrupted and forces a coredump and reboot when attached to the filer head during normal operation. It seems I have a 10 min window… I’ve tried WAFL_chk, etc but nothing seems to make it come around.
Is there a way to move data or (hopefully) a volume from aggr1 -> aggr0 from maintenance mode? Any help would be appreciated.
Hi David,
I know that in maintenance mode you have limited access to the aggregates, but I’m pretty sure you don’t have access to the actual volumes.
What you probably want to do is boot into maintenance mode, then run WAFL_check or wafliron on the corrupted aggregate. WAFL_check gives you feedback and options on what to commit, where-as wafliron just goes ahead and fixes things, whatever the outcome!
Generally we’d recommend logging a call with NetApp support as they can investigate the output of the WAFL_check much more and let you know any potential impact to fixing the inconsistencies and any potential data loss due to the corruption.
To run WAFL_check, press CTRL+C on boot to get special boot options, then type “WAFL_check” instead of any numbered option. I’ve only done this a few times over my years (testament to RAID-DP), so I’d strongly recommend you consult NetApp Support.
If you have access to NOW, have a read over : https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb20575
Great article!
I have folowing task.
I have many cifs shares on one big volume (in one qtree) and have to split this volume in several smoller. The only possibility i see is to use ndmpcopy to transfer data to new volumes. Then stop cifs, delete old shares and create new using cifsconfig_share.cfg.
I wanted to use robocopy, but it has some limitations (long paths, ACLs etc).
Do you see some better possibility?
Thanks!
This is definitely a tricky situation. Yes you could use ndmpcopy, but if you have a large directory tree, I reckon this will take a very long time!
I might be tempted to cheat here, if the new volumes you are creating are on the same aggregate (or even if not, we can stage them). You’ll want to disable CIFS access before starting, otherwise you’ll have a nightmare trying to synchronise any changes after you start.
Clone the volume in question a number of times (If you don’t have FlexClone, use SnapMirror or vol copy, but you won’t benefit from 0% space usage). However many volumes you want the data separated into at the end, clone it this many times. Do it with no space guarantee on the volume. Now, create a CIFS share for yourself to each of the volumes. Delete all other data that exists in the volume. Deleting data will be quicker than copying as you don’t need to read, interrogate and re-write all the ACL’s and file trees, just delete
. Once this has finished, break the clones (will use less storage now), fix the space guarantee and repoint the CIFS shares.
This is a fairly novel way, but might be your best and quickest method. Alternatively you’ll be looking at specific migration tools which are usually chargable, like Quest Migrator (I think that’s the name).
Cool solution!
Unfortunatly, i can’t do it so, because one of the benefits of the whole action is the feasibility to enable a-sis on new volumes.
I will be able to test, how long ndmpcopy needs to transfer the data an how the performance impact will be on a DR filer.