Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
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>