I am running emcopy with below between Celerra and Isilon and it doesn't copy data anymore at some point and starts giving warnings. I left it running for more than 3 days but it dint complete. Data to be copied is close to 100GB and it really doesn't need so much amount of time to copy.
emcopy <src> <dest> /c /o /secfix /s /d /r:0 /w:0 /preserveSIDh /purge /log:vdm02_dw2_s_1.txt /f /th 256
I tried with 32 threads to see if it is overloading source, but still the same issue.
Any thoughts on what the issue is
Solved! Go to Solution.
The issue was with dedpulication enabled on the FS. It was turned on and then set it to suspended again which was the original state gave access to all data. Not sure why it dint work previously when it was already set to suspended
Try isi_vol_copy_vnx in the meantime. Robocopy/EMcopy "Error 3" indicates path issue.
Also, the Isilon is not joined to AD.
|Server DEST||: VDM02.IL021ISI01.CARDINALHEALTH.NET 6.1 Isilon Server|
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"
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
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.
Senior Solution Architect
EMC Isilon Offer & Enablement Team.
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.
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%.