I'd like to consider the use of DRBD for data replication between a primary and secondary location. The initial plan is to establish a VPN tunnel between the two; the primary end using a slice of a dual T1 link and the secondary location setting on a cable / dsl line.

The secondary will exist for DR only - it will "never" replicate back to the primary.

Has anyone done/tired/using something like this and what are your experiences with it.

Linbit also has a (Paid) DRBD Proxy product that is supposed to be designed for operating across WAN type links (compression, multiple peers). Anyone tried this out?

2 Answers 2


I can't speak for DRBD Proxy, but the regular DRBD will not like this much.

With even limited activity, you could easily saturate a dual T1 (2x 1.5Mbps; for round numbers, 300KB/s). 300KB/s could be taken up by application logging alone, let alone doing anything interesting on your server. This rules out synchronous replication (Protocol C), let alone adding the over-the-vpn latency into the equation.

Async replication (Protocol A) might technically work, but I would expect the secondary to be so far out of date as to not be usable in the case of a failure (the replica might be hours behind during the day)

Memory synchronous (Protocol B) won't help as it's still constrained by the bandwidth issue.

I expect DRBD Proxy will still suffer with similar issues, primarily causing replication delay due to the limited bandwidth.

I recommend you re-evaluate your DR strategy to work out what you are mitigating against; hardware failure or site failure.

In the case of protecting against site failure, you may get better mileage out of lower bandwidth / higher density transfers in the case of one (or both) bandwidth constrained site. Some examples of this technique are rsync (over-the-wire transfers are limited to changes in files between runs - rather than per-change for every change - plus some protocol overhead; can be run over SSH to encrypt and compress traffic further) and database log shipping (transferring compressed database logs to replay on the DR box may use less bandwidth than transferring a full database dump).

If you're protecting against hardware failure, a local DRBD replica connected with a GigE crossover will work just fine, allow for fully synchronous updates, and permit online verification to prove the data is consistent on both nodes. You can still combine this option with limited file replication to an DR site to protect against a primary site failure.

  • Thanks Greg. I've actually spoke with Linbit since posting the question and the proxy product sounds very promising. It specifically address latency, loss of connection, and lower bandwidth pipes. They use it internally between their US and overseas location across a 200ms latency line (not sure on the bandwidth though). I've got a demo next week to get more details. The solution needs to be block level so ssh / rsync don't fit. Jun 11, 2009 at 15:43
  • I'd be really interested in hearing the outcome of your demo. Good luck!
    – Greg Work
    Jun 12, 2009 at 8:36
  • 2
    The proxy product is 'more-or-less' a RAM based buffer with compression. The key is having enough RAM(and bandwidth) to handle the data's rate of change. So, great idea for office documents, low transaction db's and small data things, probably not good for multimeda, virtual machine images, and other large data changes. Jul 23, 2009 at 15:31

DRBD-Proxy will work fine provided that you are not saturating the T1 links all the time. We ship lots of 2TB files across a DRBD-Proxy connection (granted with 100 megabit link) with no issues. Provided you have enough RAM for the proxy and the quantity of writes is not so high your T1 can't cope this should work fine. You would want to use Async mode for replication though.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .