December 14, 2016 at 2:31 pm
Exactly my YMMV point (your mileage may vary).
Regards, Dave.
December 14, 2016 at 3:06 pm
If the two servers are located on-premises, like in the same rack or server room, then perhaps you can connect them directly using a crossover network cable.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
December 15, 2016 at 8:56 am
how bout this?
In the Prod environment, create an application specific userid with permissions to read the directory where your production backup is written.
In the Dev environment set up a windows scheduler task to use the prod credentials, and copy the file over to dev, load the backup to your dev server.
December 16, 2016 at 9:57 pm
Pass through authentication (already suggested by a few respondents) can solve this problem, if network control allows. But, I have to wonder what is the purpose of the current lack of trust between prod and test? Is the lack of trust designed to protect production data from test? If so, I do not understand why it is permissible to move production data into test.
We resolved that dilemma by making the load test servers member of the prod domain. Now our load test is protected just as strongly as production data.
Why was robocopy (aka robust file copy) found unreliable? Changing domains will not resolve or overcome networking/connectivity/hardware failures.
December 17, 2016 at 12:58 am
Eric M Russell (12/14/2016)
If the two servers are located on-premises, like in the same rack or server room, then perhaps you can connect them directly using a crossover network cable.
This is perhaps the simplest and most practical answer of them all! It would be interesting to see a response from the OP as to whether it is practical....
Viewing 5 posts - 16 through 19 (of 19 total)
You must be logged in to reply to this topic. Login to reply