Resizing a DRBD backing disk increases the block storage available to an existing replicated resource after the lower-level device has been enlarged on every node. It is useful when an LVM logical volume, virtual disk, storage LUN, or similar device behind a resource needs more capacity without rebuilding the replication pair.
DRBD grows the replicated device after it reexamines the lower-level devices. The safe growth path is to extend the backing device on each node first, run drbdadm resize for the resource, wait for any required synchronization to finish, and only then resize the filesystem through the DRBD device or its mounted filesystem.
Start with an existing, healthy resource and keep the same size on every lower-level device before DRBD is told to grow. Replace resource names, backing devices, DRBD minors, and mount points with the production values for each node, and avoid running filesystem tools directly against lower-level devices.
$ sudo drbdadm status r0
r0 role:Primary
disk:UpToDate
node-b role:Secondary
peer-disk:UpToDate
Do not resize during split-brain, disconnected replication, or unknown disk state unless a DRBD recovery plan already identifies the authoritative node.
$ lsblk /dev/drbd0 /dev/vgdata/r0 NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS drbd0 147:0 0 100G 0 disk /srv/data vgdata-r0 253:0 0 100G 0 lvm
Run the same check on every node that owns a backing device for the resource.
$ sudo drbdadm dump-md r0 > r0-drbd-metadata.txt
Keep the metadata dump outside the backing device being changed.
Related: How to back up DRBD metadata before a change
$ sudo lvextend --size +20G /dev/vgdata/r0 Size of logical volume vgdata/r0 changed from 100.00 GiB to 120.00 GiB. Logical volume vgdata/r0 successfully resized.
This example uses LVM. Use the storage platform's own grow operation for partitions, SAN LUNs, virtual disks, ZVOLs, or cloud volumes.
$ sudo lvextend --size +20G /dev/vgdata/r0 Size of logical volume vgdata/r0 changed from 100.00 GiB to 120.00 GiB. Logical volume vgdata/r0 successfully resized.
DRBD can refuse to reconnect to a peer whose lower-level device is still smaller than the resized resource.
$ lsblk /dev/vgdata/r0 NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS vgdata-r0 253:0 0 120G 0 lvm
$ sudo drbdadm resize r0
Use the default resize path unless the added area is known to be identical or unimportant on every node. The lower-level --assume-clean option skips resynchronizing added space, and --assume-peer-has-space is only for peer devices that are not connected but have already been grown.
$ sudo drbdadm status r0
r0 role:Primary
disk:UpToDate
node-b role:Secondary
replication:Connected peer-disk:UpToDate
A large grow can show a temporary synchronization state before the peer disk returns to UpToDate.
Related: How to verify DRBD synchronization state
$ lsblk /dev/drbd0 NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS drbd0 147:0 0 120G 0 disk /srv/data
$ sudo resize2fs /dev/drbd0 resize2fs 1.47.2 (1-Jan-2025) Filesystem at /dev/drbd0 is mounted on /srv/data; on-line resizing required old_desc_blocks = 13, new_desc_blocks = 15 The filesystem on /dev/drbd0 is now 31457280 (4k) blocks long.
Run filesystem resize tools against /dev/drbd0 or the mounted filesystem, not against the lower-level backing device.
For XFS, grow the mounted filesystem with sudo xfs_growfs /srv/data instead of resize2fs.
$ df --human-readable /srv/data Filesystem Size Used Avail Use% Mounted on /dev/drbd0 118G 41G 72G 37% /srv/data