Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Our Systems team is implementing Double Take on client machines for live replication to DR servers. Developer's desktops typically have multiple instances of Visual Studio open at all times which generate 4GB of write IO per hour. Even when Visual Studio is idle it appears to generate large spikes of IO every few seconds. Double Take can only replicate about 800MB in that same time period, so it seems to be playing catch up and is pegging one of the CPU cores on the client at 100%. The machine comes to a near full stop, Visual Studio becomes unresponsive as it seems to be competing with Double Take for IO on the same files.

Is there a way to configure Double Take in a way that will make it play nice on a developers machine? Does anyone have any experience or advice on running Double Take on client machines in general? Is there a different solution that might work better for DR? It does not need to necessarily be live replication.

share|improve this question
Double-Take does an asynchronous transfer as it is. It sounds like the async buffer is getting overrun with all the I/O ops Visual Studio is doing and is bursting the entire buffer frequently. Considering the loading here, you may want to look at something that does synchronous writes. Your developers will complain since it'll slow down overall performance, but at least it won't bring things to a halt the way its happening now. – sysadmin1138 Aug 3 '10 at 17:04

AFAIK, DT doesn't have anything that would really apply to your scenario. You can use the DT Connection Manager to limit the transmission window (time and\or queue threshhold based), or you can set a bandwidth limit on how much bandwidth DT is allowed to use. You can also have DT compress the replicated data. None of these options look like they'd work for you.

On a side note, why DT? That's an expensive solution for a development machine.

share|improve this answer
I couldn't agree with you more. – Tion Aug 5 '10 at 13:19

The question you should be asking here (IMO) is why you're putting time and effort into covering client workstations in a DR scenario. What's on those client machines that's critical, and why isn't it stored on the network?

There's likely to be more issues lurking under the surface here. Client workstations are not designed for high availability. There's no redundancy across most of the components.

I suspect even if you get doubletake working for the client replication, you're still putting a sticking plaster over a much deeper problem.

share|improve this answer
I was looking for a voice of reason, thank you. – Tion Aug 5 '10 at 13:19
all the code that is critical is obviously in source control and is stored on the network with HA, real time DR, scheduled backups etc. – Tion Aug 5 '10 at 13:22

I'm late to the party, but Visual Studio makes a whole lot of noise in TEMP space on the developer workstation. If you could exclude common temporary file areas from your replication, it might save you.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.