Emcopy open files - Warning

The log file is pretty huge and it never completed, so i just ran it again for a moment and attached the output

Can you attach the log?  Most error will be Microsoft Robocopy errors.

A few other things to watch out for:

1. change /r:0 /w:0 to /r:1 /w:1, and retry your copy.  Once in a great while I've seen slow copies when set to zero, because it seems to be waiting for open files, when in fact you want it to just skip them.

2. You're using the /preservesidh switch.  Isilon does not support sidhistory in current releases.  So you are better off to use /sidmapfile, (in version 4.17 or later) and provide it a translation file to fix the ACL's and ownership during the copy operation.  You can read more about this here: https://support.emc.com/kb/88513  (disclaimer I wrote the KB).

3. On the source the account performing the copy needs local administrator, backup operators, to the source CIFS Server, and full control over the source share.

4. On the target (Isilon), the account being used to perform the copy needs to be added to the Backup Admin Role, if you're running OneFS 7.1.1.x or later.  Otherwise, on the target Isilon share you need to give the account performing the copy (and only that account) run as root rights.

5. Number of threads.  Emcopy 4.17 defaults to 64 threads.  That is usually a pretty good number.  If you have small numbers of large files, then decrease this figure, if you have large numbers of small files then potentially increase it.

6. Migration host.  The box that you are running the copy operations from if it is virtual seems to perform better in my testing if it has a vmxnet3 virtual adapater (if you have 10Gbe network interfaces available).

7. Migration host(s).  For larger migrations, it may be advisable to split up copy jobs across multiple windows systems, and make your targets multiple Isilon nodes, or use a smartconnect zone name as the target to distribute the load.  A good common way of accomplishing this is to create a folder on the target isilon cluster like /ifs/emcmigration, and share it out as emcmigration$ .  That way you can scale from 1 to 10 migration hosts, by just logging into another windows server and mapping a network drive to that location.  In there you can store your migration scripts, and all logfiles, to make the proccess easily scale.

8. Source overloading.  One thing that people commonly overlook is that the source box is likely old 3-5 years and is being replaced because odds are it's been depreciated off the company's books.  Therefore it is also slow (by comparison to the new Isilon cluster).  So it is fairly easy to overwhelm a source box (which is frequently the bottleneck) to the point that it becomes almost if you try and push too much IO.

Anyway I hope this helps.  Yes with VNX as a source, you can use isi_vol_copy_vnx, however it is not always the right solution, depending upon how the data is accessed on the source, whether or not filesystem dedupe or dhsm are enabled, etc.

~Chris Klosterman

Senior Solution Architect

EMC Isilon Offer & Enablement Team.

isi_vol_copy_vnx is specifcally for Celerras and VNX File.

Hi Phil, can we use isi_vol_copy or isi_vol_copy_vnx with source other than Netapp.

I checked on authentication status and i am pretty sure Isilon is joined to AD

Try isi_vol_copy_vnx in the meantime.  Robocopy/EMcopy "Error 3" indicates path issue.

Also, the Isilon is not joined to AD.

TH000 : 01:21:04 : WARNING : Unable to retrieve the PDC of the domain CARDINALHEALTH nearby \\VDM02.IL021ISI01.CARDINALHEALTH.NET, error : 1717

TH000 : 01:21:04 : WARNING : The default primary group is set to "domain users"

Do we have to configure anything on celerra side to use isi_vol_copy_vnx as it uses NDMP

Yes a few things:

1. if fs_dedupe is enabled on the Celerra or VNX, you need to change the backup threshold to zero for each filesystem.  This means that when sending the data over NDMP send the full file, not the compressed or de-duped version.  Note, there is a risk here of inflating existing backup sets if they are being done over NDMP.

2. You need an NDMP account on the datamover in question to be able to do the NDMP-based pull.

3. If DHSM is in the mix, then this is not the right tool to choose, because it cannot remove the offline extended file attrib, and you would have to change the backup method for DHSM to a pass-through call.

4. If SIDHistory is in use on the source, then this likewise is not the proper tool.

Those are the things to watch out for.

~Chris

Thanks Chris and Phil

It turns out that huge chunk of data that is not copied are all open files, about 600GB and most of them are copied on closing them. The files that were not copied, i cant copy them manually either to target or desktop, the window that opens with progress of copy keeps loading and never completes. I noticed that the 'Backup Data Threshold' value is 0 and deduplication is suspended and 'space_saved' is 0%.