An Introduction to DRBD (Distributed Replicated Block Device)

mirror drdb

In a bid to comprehensively document and comprehend business challenges, The University of South Florida St. Petersburg conducted a survey to evaluate various business threats. Through a publication titled “Hidden Threats to Enterprise”, they reported that 80% of businesses which face significant threats usually collapse within the 3 subsequent years. After zeroing in on IT problems, they further found out that 40% of businesses which experience major IT mishaps usually collapse within a single year. Evidently, IT failures are some of the most critical business calamities which can potentially cripple an entire enterprise.

To avoid becoming casualties of such incidents, businesses implement two major strategies:

  • Preventive measures
  • Recovery measures

Preventive measures may be considerably efficient but not entirely efficacious, since 31% of computer users in the US alone claim to have completely lost important data due to unpreventable reasons. Consequently, it’s crucial to additionally implement recovery measures to help you recover and resume operations in case of such occurrences. In fact, according to the Strategic Research Institute, organizations which do not recover from IT disasters within 10 days are very likely to collapse.

Among the most effective recovery measures is DRBD, otherwise referred to as Distributed Replicated Block Device. Essentially built for Linux, it’s a free open source tool which protects data by replicating it to another server. It therefore utilizes two servers- the primary and the secondary one.


Back in the 1990s, Lars Ellenberg and Phillip Resiner both conceived the idea of protecting data through two separate servers that communicate in real time. In the subsequent years, they began working on their concept and eventually gave birth to the DRBD , a revolutionary security tool that would be readily available at a minimum cost and offer optimal data protection.

The reception through the years has been impressive, especially since it’s essentially an open source software which was released and distributed under the GNU General Public License. It has also undergone critical improvements, to evolve into the ultimate Linux based security replication tool. Some of its features include:

  • It’s compatible with all the available versions of Linux. This makes it flexible enough to be effectually adopted in various systems.
  • It supports synchronous data replication between active and passive systems. It can therefore facilitate multidimensional data replication through wide area network, local area network and/or storage area network.
  • The data storage and retrieval process occurs in real-time, enabling it to simultaneously read and write data to both the active and passive systems.
  • It is powered by Heartbeat, which is a cluster management program that automatically runs special scripts on Linux when a system is powered.
  • It facilitates resource level fencing

How it Works

The tool is built to imperceptibly facilitate communication between two servers by minimizing the amount of system resources used- It therefore does not affect system performance and stability. So, how does the actual communication occur? How is data protection optimized by two separate servers?

DRBD facilitates communication by mirroring two separate servers- one server, although passive, is usually a direct copy of the other. Any data written to the primary server is simultaneously copied to the secondary one through a real time communication system. Any change made on the data is also immediately replicated by the passive server.

The passive server only becomes active when the primary one fails and collapses. When such a failure occurs, DRBD immediately recognizes the mishap and shifts to the secondary server. This shifting process however, is optional- it can either be manual or automatic. For users who prefer manual, one is required to authorize the system to shift to the passive server when the primary one fails. Automatic systems on the other hand, swiftly recognize problems within the primary servers and immediately shift to the secondary ones.


To function efficiently, DRBD should be installed by an IT specialist who’s experienced in the software. The setup process usually involves using command line tools to configure the following elements:

  • Location of the Secondary Server: The storage drives or partitions that will serve as the secondary server are dictated through the command line.
  • Resources to Be Replicated: It’s advisable to primarily replicate only the most critical data and processes. The rest of the data should only be chosen if your resources can sufficiently support them.
  • Storage Size of the Secondary Server: To efficaciously mirror all the data between the servers, the storage size of the secondary server should match up to the resources that are to be replicated.
  • Disaster Management: Of course it’s essential to dictate how your servers will respond to a system failure. Will the secondary server kick in automatically- or would you rather manually control the shifting process? What will happen after the primary server is restored?

By making the software open source, Lars Ellenberg and Phillip Resiner have significantly boosted the adoption process by granting businesses the flexibility to adjust some of the software’s elements according to their needs. That’s why IT specialists should comprehensively assess all the business needs and resources before installing the software.

After installing and running DRBD, remember that’s it’s only a replication resource, not a back-up storage. To completely protect your business against collapsing in case both the primary and secondary servers fail (which is very unlikely), you should have a set of backups that hold the most vital data in your organization.

Finally, ensure that the servers are properly maintained through occasional testing and monitoring. This is crucial in identifying any problems which would be detrimental not only to the system, but also to your entire organization.

 Author: Davis Porter

 image courtesy: Dan,