DRBD
DRBD (Distributed Replicated Block Device) is an open-source software solution for Linux that enables synchronous replication of block devices across multiple networked nodes, providing high availability and data redundancy in clustered environments.[1] As a kernel module, it creates virtual block devices that mirror data in real time between hosts, operating transparently to upper-layer applications and file systems.[2] This shared-nothing architecture ensures that data remains consistent and accessible even in the event of node failure, making DRBD a foundational component for building resilient storage systems.[3] DRBD supports three replication protocols to balance performance, reliability, and potential data loss: Protocol A for asynchronous replication, Protocol B for semi-synchronous operation with minimal buffering, and Protocol C for fully synchronous mirroring that guarantees no data loss on single-node failures.[3] It leverages TCP/IP or RDMA (Remote Direct Memory Access) transports for efficient data transfer, including support for InfiniBand, iWARP, and RoCE, allowing deployment in both local high-performance setups and wide-area disaster recovery scenarios.[1] User-space tools such asdrbdadm for administration, drbdsetup for configuration, and drbdmeta for metadata management facilitate setup and monitoring, while the core driver avoids user-space overhead for optimal I/O performance.[3]
Originally developed in 1999 by Philipp Reisner, with Lars Ellenberg joining the development in 2003, DRBD has evolved over more than two decades, maintained by LINBIT, with version 9.0 introducing multi-node support for up to 16 replicas and integration with cloud-based storage pools.[4] Released under the GNU General Public License version 2 (GPLv2), it is freely available and widely integrated into distributions like Ubuntu and SUSE for high-availability extensions.[5] Key use cases include failover clustering for databases and messaging systems, live migration of virtual machines, and software-defined storage solutions that prioritize data durability without shared hardware.[1]
Introduction
Overview
DRBD, or Distributed Replicated Block Device, is an open-source Linux kernel module that provides real-time mirroring of block-level storage across networked nodes, functioning as a shared-nothing replicated storage solution.[3] Its primary purpose is to enable high availability (HA) and disaster recovery by replicating data synchronously or asynchronously between nodes, ensuring data redundancy and minimal downtime in the event of hardware failure or site outage.[1] This replication occurs at the block device level, making DRBD transparent to upper-layer applications and file systems.[3] Key features of DRBD include support for various block devices, such as physical disks or Logical Volume Manager (LVM) volumes, allowing it to integrate with existing storage infrastructures without requiring specialized hardware.[3] It offers flexible replication protocols that prioritize either strict data consistency in synchronous mode or higher throughput in asynchronous mode, with additional capabilities like online verification and quorum mechanisms to prevent data corruption.[3] DRBD also integrates with cluster managers such as Pacemaker, enabling automated resource management and failover in multi-node environments.[3] Development of DRBD began in 1999 by Philipp Reisner, with LINBIT founded in 2001 to further its development under the GNU General Public License version 2 (GPL v2), promoting widespread adoption in open-source ecosystems.[6][7] As of November 2025, the latest stable version is 9.2.15, which includes enhancements for performance—such as Remote Direct Memory Access (RDMA) transport—and scalability, supporting up to 32 nodes in replication topologies.[8]History and Development
DRBD originated from the work of Philipp Reisner, who began developing it in 1999 as part of his master's thesis at the Vienna University of Technology, initially focusing on tools for email handling that evolved into a distributed replicated storage system for Linux. In November 2001, Reisner co-founded LINBIT in Vienna, Austria, where DRBD was established as a core project to provide high availability (HA) storage replication solutions. Lars Ellenberg joined LINBIT in 2003 to lead the research and development efforts, contributing significantly to DRBD's maturation alongside Reisner.[6][9] Early development saw the release of initial versions in the early 2000s, with DRBD 0.5 marking a foundational milestone around 2002, enabling basic block device replication over networks. A major advancement came with DRBD 8 in January 2007, which broke previous performance barriers and introduced support for active/active clustering, allowing shared access to replicated storage in HA setups. In 2007, DRBD Proxy was introduced to address wide area network (WAN) replication challenges by buffering writes in memory, mitigating latency and bandwidth limitations for long-distance scenarios. That same year, on December 8, 2009, DRBD was officially merged into the Linux kernel (version 2.6.33), enhancing its accessibility and integration within the ecosystem.[9][10][11] DRBD 9, first released in 2015, brought substantial enhancements, including support for multi-node replication (up to 32 peers per resource), improved kernel compatibility, and better scalability for larger software-defined storage deployments, moving beyond traditional two-node HA clusters. In March 2025, LINBIT released DRBD Proxy version 4, a complete rewrite in a modern programming language that optimized performance for distributed environments, marking the first major update to the proxy in over a decade.[12][13] LINBIT continues to maintain DRBD as an open-source project under the GNU General Public License version 2, with ongoing community contributions through its GitHub repository and mailing lists. The company provides enterprise-grade support and extensions via its Software Defined Storage (SDS) platform, which integrates DRBD with LINSTOR for automated management in production environments. As of 2025, recent updates have emphasized compatibility with emerging technologies, including enhanced NVMe over Fabrics (NVMe-oF) support for high-speed storage replication and integration with container orchestration systems like Kubernetes through CSI drivers for persistent volumes.[1][14][15][16]Core Functionality
Mode of Operation
DRBD functions as a kernel module that presents a virtual block device to the upper layers of the Linux I/O stack, enabling transparent replication of data between nodes. In its core operational model, the primary node handles all read and write operations to the underlying physical block device, while simultaneously mirroring writes to one or more secondary nodes over a network connection using configurable transports such as TCP/IP or RDMA, ensuring real-time data synchronization either synchronously or asynchronously depending on the configuration.[3] Resource configuration in DRBD is managed through structured files in the /etc/drbd.d/ directory, where each resource—representing a replicated block device—is defined with parameters such as the resource name, the backing store (typically a physical partition like /dev/sda or an LVM logical volume), and network-related metadata including connection endpoints and transport protocols. Administrators initialize metadata on the backing devices using the drbdadm create-md command, which stores essential replication state information on the devices themselves to facilitate recovery and synchronization. This configuration approach allows for flexible setup of multiple resources on the same nodes, each operating independently.[3] Failover in DRBD relies on role management between primary and secondary nodes, where the drbdadm utility enables manual or scripted switching—such as promoting a secondary node to primary with drbdadm primaryReplication Protocols
DRBD implements three primary replication protocols—A, B, and C—that dictate the level of synchronicity between the primary and secondary nodes, balancing data consistency, performance, and tolerance to network latency.[17] These protocols are configured per resource in the DRBD configuration file (drbd.conf) under the net section using the protocol directive (e.g., protocol A;), allowing administrators to select the appropriate mode based on application requirements and infrastructure constraints.[17] The choice of protocol directly influences the system's Recovery Point Objective (RPO), which measures potential data loss, and Recovery Time Objective (RTO), which affects failover speed; asynchronous modes generally yield higher RPO but lower RTO, while synchronous modes minimize RPO at the cost of increased latency.[17]
Protocol A operates in an asynchronous manner, where a write operation on the primary node completes immediately after the data is written to the local disk and placed into the TCP send buffer for transmission to the secondary node, without waiting for any acknowledgment from the peer.[17] This approach is particularly suitable for environments with high network latency, such as geo-distributed setups, as it minimizes application wait times and maximizes throughput, though it carries the risk of data loss if the primary fails before the secondary receives and applies the changes.[17] In terms of trade-offs, Protocol A prioritizes performance over strict consistency, resulting in a higher RPO (potentially up to the volume of unacknowledged data in flight) but facilitating quicker failovers and lower RTO due to the absence of synchronization delays.[17]
Protocol B, often termed semi-synchronous or memory-synchronous replication, acknowledges writes after the local disk commit and confirmation that the secondary node has received the data packet (via TCP acknowledgment), but before the peer writes it to its disk.[17] This ensures the data is buffered on the secondary without blocking on disk I/O, providing a compromise between the speed of Protocol A and the reliability of stricter modes.[17] It reduces the risk of data loss compared to Protocol A—limited primarily to simultaneous failures of both nodes or network partitions—but introduces moderate latency from network round-trips, yielding a balanced RPO (minimal loss if the secondary survives) and RTO that is neither the fastest nor the slowest.[17] Protocol B is ideal for scenarios where some tolerance for minor inconsistencies is acceptable to maintain good performance.
Protocol C employs fully synchronous replication, where write acknowledgments are issued only after both the primary and secondary nodes confirm the data has been durably written to their respective disks, enforcing strict consistency across the cluster.[17] This mode guarantees zero data divergence on single-node failures, making it the default and preferred choice for high-availability applications demanding strong durability guarantees, such as financial systems or critical databases.[17] However, it incurs the highest latency due to the full round-trip including remote disk synchronization, which can impact throughput in bandwidth-constrained or high-latency networks, leading to the lowest RPO (effectively zero for surviving writes) but potentially elevated RTO from the added overhead during normal operations.[17]
Beyond the core protocols, DRBD includes advanced features to enhance efficiency and integrity. Trimming support, enabled automatically since DRBD 8.4.3 for underlying storage that handles TRIM/Discard commands (common on SSDs), allows efficient handling of unused blocks during synchronization and resynchronization, significantly reducing initial sync times—for instance, from hours to minutes for multi-terabyte volumes—without affecting runtime replication.[18] Online verification provides a mechanism for periodic integrity checks, where block-level cryptographic digests (configurable via verify-alg options like sha1, md5, or crc32c in the net section) are compared between nodes using commands like drbdadm verify <resource>, enabling detection of silent data corruption without downtime; this is typically scheduled via cron for weekly or monthly runs to maintain long-term data fidelity.[19]
In DRBD 9.2 (stable release 9.2.14 as of June 2025), additional enhancements include support for encrypted replication using kernel TLS (kTLS) over the TCP transport for secure data transfer without substantial performance penalties, and load balancing across multiple network paths per connection to aggregate bandwidth and provide link failover.[20]