I've read that you should avoid using robocopy with the copyall flag as
this apparently sets the NTFS permissions inheritance flag incorrectly.
The alternative I've seen suggested is xcopy, but I haven't seen any
specific command line offered.
In testing I used the following command to prestage a few GB and it
appeared to work, but when I enabled replication on a larger dataset the
initial replication is taking several hours and is logging various
indications that files were not identical, etc.
xcopy \\initial-server\%x$ W:\%x /e /i /h /k /o
Eventlogs are showing multiple 4412 - "The DFS Replication service
detected that a file was changed on multiple servers. A conflict
resolution algorithm was used to determine the winning file. The losing
file was moved to the Conflict and Deleted folder"
I'm replicating between a 2008 Standard x64 server and a 2003 Standard
R2 x64 server.
Am I missing something obvious, or do I just need to be more patient?
Yes you will see a lot of junk but I've found that the "junk" actually
clears up MUCH faster than if you had not prestaged the data.
hth
DDS
"DevilsPGD" <spam_na...@crazyhat.net> wrote in message
news:mfdi645ubfc9ut27e...@4ax.com...
>I use robocopy x:\ z:\ /e /sec /w:3 /r:2 and it works like a charm.
Thanks, I'll give that a shot for the next test.
>You can also use the /LOG switch to see what w
>
>Yes you will see a lot of junk but I've found that the "junk" actually
>clears up MUCH faster than if you had not prestaged the data.
The current share I'm watching has ~48,340 files, 23.8GB, and was
prestaged using my xcopy command line (I'll try your robocopy command
line for the next one and see if that makes a difference)
I'd normally expect my previous sync tool (rsync based) to take less
then an hour to build a list of files that need to sync (and assuming
neither side has changed, that would be the end of the process) after
prestaging. Any ballpark on how long DFS-R will take -- I'm not as much
worried, as just wanting to set reasonable expectations.
Thanks for the input!
>In message <#1xmlbv2...@TK2MSFTNGP04.phx.gbl> "Danny Sanders"
><DSan...@NOSPAMciber.com> wrote:
>
>>I use robocopy x:\ z:\ /e /sec /w:3 /r:2 and it works like a charm.
>
>Thanks, I'll give that a shot for the next test.
I prestaged another share with robocopy and fired up DFS-R, I'm still
seeing some files reporting as having changed. The file most definitely
was not touched between when I ran robocopy and now.
Any idea how to find out what and replicate the change with robocopy, or
should I stop stressing and just let DFS-R do it's thing?
Let DFSR do it's thing.
hth
DDS
"DevilsPGD" <spam_na...@crazyhat.net> wrote in message
news:snmi64162ljc1o2nn...@4ax.com...
I have a 16GB share up next which I'm going to replicate across four
machines, I'm going try prestaging only to one and see how the numbers
and timing look.
Either way, I appreciate all the feedback, I think I just need to be
more patient with the initial replication.
In message <#FHcw642...@TK2MSFTNGP02.phx.gbl> "Danny Sanders"
I prestaged two 16GB shares using exactly the same robocopy command, and
they started at the same time.
One took four hours and replicated under 500MB of data, the other took
over a day and replicated over 12GB of data.
Magic and mystery I tell ya! Either way, I'm just setting it up and not
stressing now, so life is good.
Thanks for all the info!
In message <#FHcw642...@TK2MSFTNGP02.phx.gbl> "Danny Sanders"