• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 3936
  • Last Modified:

Robocopy question: Should I run it on the Source or Destination

I have a two part question.

1: When running robocopy should it run on the Source or Destination Server?


2: The source Data is on a Server 2003 32 Bit OS and the destination server is a Server 2008 R2 Standard.  Is it a bad idea to run multi instances of Robocopy to try and expidite the overall sync faster.  I am dealing with close to 6.5 TB worth of data.
I have a script that will loop throught each first level folder and start a Robocopy Job for that folder. This script can run as many instances as I want.  I was thinking 3 to 4 instance.

Examples:
Folder A
Folder B
Folder C
Folder D
Folder F

The script with start an isolated job just on Folder A and all it's sub folders and if the count of Robocopy instances is = 2 than it will move on and do Folder B at the same time while waiting to see if the robocopy instance count drops below 2. If it does it will then start on Folder C and so on.
0
yo_bee
Asked:
yo_bee
2 Solutions
 
strivoliCommented:
I usually run it on the Source Server. In this scenario it is much better to run Robocopy as a Scheduled Task from W2003. This sums two reasons (Source Server and OS) to run it from W2003. I would not run more instances of Robocopy. Net and Disk I/O are the bottlenecks when running robocopy between Servers. More robocopy instances do not speed transfers in these scenarios.
0
 
Paul MacDonaldDirector, Information SystemsCommented:
1) Shouldn't make a difference.

2) You could give it a try and see if it makes a difference.  The bottleneck here will likely be your disk(s) so unless you have these folders spread out among several drives you're unlikely to see a speed increase once you get past running three or four instances of Robocopy.
0
 
oBdACommented:
Run the script on the destination server; robocopy on W2k8R2 supports the /MT option to run a multithreaded copy, so you won't need your own instance monitoring. Default is 8 threads, you can use "/MT:n" to use n threads. This should be faster even if disk or net are bottlenecks, because the role of protocol overhead is reduced.
Does the data consist of rather few but large files, or is this a huge number of files and folders? If it's the latter, you should do an initial run with the option "/create" to prevent directory fragmentation. With this option, robocopy will create the folder and file structure with file sizes of 0 bytes; then copy again without the "/create".
0
 
NetfloCommented:
Hi,

Answer 1. MS recommends in their SBS 2003 - SBS 2011 guide the following to use the destination server, in your case Server 2008R2:

To copy users’ shared folders
1.      On the Destination Server, click Start, right-click Command Prompt, and then click Run as administrator.
2.      On the User Account Control page, click Continue.
3.      At the command prompt, type the following:
Robocopy \\<SourceServerName>\Users \\<DestinationServerName>\UserShares /E /COPY:DATSOU /R:10 /LOG:C:\Copyresults.txt
 Note
RoboCopy is an alternative to Xcopy, and is a standard feature in Windows Server 7. For more information about RoboCopy, see the Robocopy website.
4.      View C:\Copyresults.txt to verify that the files were copied correctly. You can also compare the number and size of the files that were in the users’ shared folders on the Source Server with the number and size of the files that are now on the Destination Server.


Reference: http://technet.microsoft.com/en-us/library/gg563797.aspx

Answer 2: I would not recommend that, just be patient and wait. Move the data in stages and update users mapped drives and shortcuts accordingly via GPO.

Hope this helps.
0
 
yo_beeDirector of ITAuthor Commented:
I choose two solution because I am currently running it from the Dest Server (2008) with /MT:32 switch.

Things seem to be progressing well.

Thanks for the input and Advice
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now