[DRBD-user] Using DRBD for asychronous off-site disaster recovery replication

James R. Leu jleu at inoc.com
Fri Jan 2 23:53:02 CET 2009


Hello Larry,

We have been using DRBD for replication to our DR site across a 25 Mbps metro
ethernet for over 2 years now.  So I have some decent experience with what
you're trying to accomplish.

See the rest of my comments in-line.

On Fri, Jan 02, 2009 at 04:10:02PM -0600, Lawrence Weeks wrote:
> Hi,
> 
> I have a couple questions about using DRBD to solve our problem. We are replicating disk based backups to a disaster recovery (DR) server, and also will copy that data to a remote site. We are looking for the best method to accomplish this. I'd like to get some feedback on using DRBD for this. The replication of the data definitely need not be synchronous, as the link will be fast Ethernet, or slower (VPN over public Internet). We don't mind if the replication of the DR copy of the backups takes a good bit of time to copy over.
> 
> We may want to use DRBD rather than rsync because the backup data consists of a huge number of small files, with hard links from one backup session to another. This isn't an ideal situation for rsync to manage, though using inotify as well is an option that we may test.

We've found that block level replication is the lowest level common
denominator for all of our replication needs.  Sure there are other
ways to replicate various types and sources of data, but for simplicity
we use just DRBD.

There is a performance hit on your primary nodes when doing 'protocol C'
across long/slow links.  So make sure you are willing to take that hit
if you plan to keep DRBD connected/replicated at all times.

Also, make sure you know exactly what types and the amount of block
updates that are occurring with your filesystems.  (ie noatime, nodiratime)

> 
> Another question is what facility is there with DRBD to "bootstrap" the data? If we replicate the two nodes, and then ship the second node to the remote site, is it best to write no data to the local DRBD node in the interim, or will it safely queue the replication up until the remote node is available?

When we bring new system on-line that has existing data, that is exactly
what we do.  A DRBD node that is primary and disconnected from it's
peer will keep track of the blocks that have been updated.  Once you
reconnect the secondary, they will begin the process of syncing the
changed blocks.  During this process additional writes to the primary
node are also replicated.  Also, you can control the rate at which the
changed blocks are synced.

> Thank you.
> 
> Larry
> -- 
> Lawrence Weeks
> larry at 01.com
> 888 663 3250 x119
> 847 693 0806 mobile
> ____________________
> http://www.01.com
> 
> The #1 Email Solution for Teamwork (TM)
> Premier Zimbra Partner & Blackberry Alliance Partner
> _______________________________________________
> drbd-user mailing list
> drbd-user at lists.linbit.com
> http://lists.linbit.com/mailman/listinfo/drbd-user

-- 
James R. Leu
Software Architect
INOC
608.204.0203
608.663.4555 fax
jleu at inoc.com
www.inoc.com

*** DELIVERING UPTIME ***
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.linbit.com/pipermail/drbd-user/attachments/20090102/5fc3eb33/attachment.pgp 


More information about the drbd-user mailing list