Many developers assume that distributed file systems like GlusterFS or CephFS will solve all their redundancy needs, but there are cases where only block-level replication makes sense:

// Example use cases requiring block replication:
- Database storage (PostgreSQL, MySQL clusters)
- Virtual machine disk images (KVM/Xen)
- Legacy applications requiring raw device access
- Low-latency requirements where file system overhead is prohibitive

DRBD (Distributed Replicated Block Device) has been the de facto standard for Linux block replication since its integration into the mainline kernel. A basic DRBD configuration looks like:

resource r0 {
    protocol C;
    on primary-node {
        device /dev/drbd0;
        disk /dev/sdb1;
        address 192.168.1.10:7788;
        meta-disk internal;
    }
    on secondary-node {
        device /dev/drbd0;
        disk /dev/sdb1;
        address 192.168.1.11:7788;
        meta-disk internal;
    }
}

While DRBD is excellent, it's not the only option:

1. Linux LVM Mirroring

LVM provides built-in mirroring capabilities that can work across network storage:

pvcreate /dev/sdb /dev/sdc
vgcreate vg_mirror /dev/sdb /dev/sdc
lvcreate -L 100G -m1 -n lv_data vg_mirror

2. Ceph RBD Replication

Ceph's RADOS Block Device offers robust replication with self-healing capabilities:

rbd create mypool/myimage --size 1024 --data-pool mypool
rbd feature disable mypool/myimage exclusive-lock, object-map, fast-diff
rbd mirror image enable mypool/myimage journal

3. ZFS Replication

For systems supporting ZFS, its send/receive functionality provides efficient block replication:

# On primary:
zfs snapshot tank/data@monday
zfs send tank/data@monday | ssh backup-server zfs recv backup/data

# Incremental replication:
zfs snapshot tank/data@tuesday
zfs send -i tank/data@monday tank/data@tuesday | ssh backup-server zfs recv backup/data

4. Commercial Solutions

Solutions like EMC VPLEX, Dell EMC PowerMax, or NetApp MetroCluster provide hardware-accelerated block replication, though they come with enterprise price tags.

Here's a simple benchmark script to test replication latency:

#!/bin/bash
# Test block device write latency
device=$1
echo "Testing $device..."

# Sequential write test
dd if=/dev/zero of=$device bs=1M count=1024 oflag=direct status=progress

# Random write test
fio --filename=$device --rw=randwrite --bs=4k --ioengine=libaio --iodepth=16 \
    --runtime=60 --numjobs=4 --time_based --group_reporting --name=randwrite

Consider these factors when selecting a solution:

• Synchronous vs asynchronous replication needs
• Distance between nodes (same rack vs geographical separation)
• Recovery Point Objective (RPO) and Recovery Time Objective (RTO)
• Storage backend compatibility
• Management complexity

For most open-source Linux environments, DRBD remains the most mature solution, but alternatives exist for specific use cases. The best approach is to test several options with your actual workload before committing to production.

---

When file-level solutions like GlusterFS or GFS don't meet your requirements, the search for robust block-level replication begins. While DRBD (Distributed Replicated Block Device) is indeed the most mature and widely adopted solution, it's not the only option available in the Linux ecosystem.

DRBD's popularity stems from its:

• Kernel-level implementation for performance
• Seamless integration with Pacemaker/Corosync
• Proven track record in enterprise environments
• Support for both synchronous and asynchronous replication

A basic DRBD configuration looks like:

resource r0 {
    protocol C;
    on primary {
        device /dev/drbd0;
        disk /dev/sdb1;
        address 192.168.1.10:7788;
        meta-disk internal;
    }
    on secondary {
        device /dev/drbd0;
        disk /dev/sdb1;
        address 192.168.1.20:7788;
        meta-disk internal;
    }
}

1. Ceph RBD (RADOS Block Device)

While typically considered an object storage solution, Ceph's RBD feature provides distributed block storage with replication. Example configuration:

rbd create mypool/myimage --size 1024
rbd map mypool/myimage --name client.admin

2. LVM Mirroring

For simpler setups, LVM's built-in mirroring can provide redundancy:

lvcreate -L 10G -m1 -n lv_mirror vg00

3. BCache + Replication

A more unconventional approach combining BCache with rsync or DRBD for the backing device.

Each solution has distinct performance characteristics:

Solution	Latency	Throughput	Failover Time
DRBD	Low	High	Seconds
Ceph RBD	Medium	Very High	Minutes
LVM Mirror	Low	Medium	Manual

DRBD excels when you need:

• Low-latency synchronous replication
• Tight integration with existing HA stacks
• Simple two-node configurations

Ceph RBD makes sense for:

• Larger scale deployments
• Environments needing multi-site replication
• Scenarios where storage needs might grow unpredictably

For those needing quick-and-dirty redundancy without additional packages, LVM mirroring can be surprisingly effective.

In particularly demanding environments, you might combine several approaches. For example:

# DRBD as primary replication
# LVM on top for volume management
# BCache for performance optimization

lvcreate -L 100G -n lv_data vg_drbd
make-bcache -B /dev/vg_drbd/lv_data -C /dev/nvme0n1p1