What version of EMCOPY are you using?  What is the source Celerra DART version?  What is the destination ISILON OneFS version?

Can you post some errors from your EMCOPY attempts? 

Karl,

I did not have any specific errors. I used emcopy 4.17, Celerra Dart version is 6, and the Isilon version is 7.0.2.10 and I was able to migrate the data. The issue I had is that some files came over corrupted. They are image files and the complete file did not migrate. When I try to view the file in Adobe Bride there are lines in the image. Some files do not display a thumbnail and when it is opened in Adobe Photoshop the format is not readable. As of now I have deleted the files migrated to the Isilon and I will migrate them again with the md5 switch. This worked on a small subset. The problem now is that my production application has been migrated and I cannot delete those files. Is there a way to have emcopy migrate the files again and over write the files if they are already migrated and leave the new files added? The files I deleted were not part of the production application.

Oh sorry. So many things are going on. I did not solve the issue I just have a workaround. ☺

Karl,

I used those and it did not make a difference. I am solving my issue manually. You can close this SR.

Thank you,

Can you be a bit more specific about your DART version?  6.0.47-3?  6.0.51?  There are always a few "gotchas" with the subversions you can glean from the release notes.  I'm curious to see if you're hitting one of those.

On the EMCOPY side, You might try the /d or the /de flags - these leverage the modification times on the files:

The "/d" option provides to copy only source files which have the LAST MODIFICATION time greater than the existing target copy.

The "/de" option provides to copy the source file when its last modification time is not equal to the destination file's modification time or when files size are different.

Would these be useful?

Let us know if that helps!

Karl

Congrats!  Glad to hear you solved your issue, but I'm not with EMC Support. 

Good luck with your migration!

Karl

I am doing a similar migration, but am using a PC inbetween with both TeraCopy and Robocopy doing the copy tasks. Occasionally, but more often than I wish, I get copy failures, with error messages that say the source server is "paused" and other hints that the source server is not keeping up with copy task. I have to go back to the file causing the message and try it again manually. Sometimes it takes several tries, but eventually the file comes across clean. I have also tried having the copy software retry an unlimited number of times. In this case, it just hangs rather than actually retrying the way a manual copy does. This has made the migration much slower than it should have been because of the need to validate all file movements and watch the logs. We have millions of files to copy and I have seen this behavior with hundreds of files. Some files were also compressed by the Rainfinity appliance, which might be the reason for some slowness, as those files need to be rehydrated prior to the copy. Keep logs and be sure to set verification on so you can see what might have happened.

Russ,

I used the emcopy tool to migrate the stubs. There is not any specific characteristics the files are random that do not render properly. The file is there with the correct data size and date it just does not have the complete data. The files seems as though the data did not completely copy. Some of the images display with lines across the images and some do not display a thumbnail. I am trying to configure the CTA for migration to test but I am having issues with the XML API not resolving the path. I have another discussion open for that issue.

emcopy64.exe
source
source>
destination
adestination> /localsidsource “SID” /s /d /o /i /sdd /secfix /r:0 /w:0 /q /preserveSIDh /ignoredhsm /cm md5 log:”local path”

Can you provide more specific details of the migration; source system and data, the tool and the switches being used and the detailed error messages you are seeing.

Have you identified any common characteristics of the files that fail; size, source location, application use, file status;compressed, stubbed etc etc.. This may help identify the primary issue here.

I'm adding links to two Isilon migration docs that provide additional guidance if you haven't seen them also:

https://www.emc.com/collateral/white-papers/h12212-smb-file-migration-emc-isilon-wp.pdf

http://www.emc.com/collateral/white-papers/h12517-wp-emc-nfs-file-migration.pdf

Have you checked on the Windows server that you use for the migration if there was any error during the copy (Event viewer, System)

Claude

It looks like you are running emcopy with /ignoredhsm which would suggest at least version 4.16, but we would suggest running 4.17 if you are not currently.

Also have you run these without the /cm md5 switches as this can place additional load on the source/target and migration host while executing the copy.

Maybe also attempt the copy using a lower number of threads, because the source file is having to be recalled maybe throttling the emcopy job will benefit the process here.

  /th nb  Number of working thread, by default 64 working threads are created.

           Working thread count must be in the range 1 to 256.

Also can you provide the log out for failed files with the exact errors it is producing. 

thx

russ

Hello Russ,

I am using 4.17 and initially I did not use the md5 switch. I can try the lower thread count to see if that helps.

Thanks