A DRBD resource defines the replicated block device that two Linux nodes share. Creating one ties a resource name such as webdata to a backing block device, internal metadata, node IDs, and the network addresses that the peers use for replication.

drbdadm reads the skeleton /etc/drbd.conf file and the resource files under /etc/drbd.d. Keep the same .res file on every participating node, and make each on section match the node's hostname output so DRBD can select the correct local disk and address.

Creating metadata writes DRBD control data to the backing device, so use an unused block device or a device whose data source has already been chosen and backed up. After drbdadm up, a new two-node resource normally appears as Secondary on both nodes and Inconsistent until a separate initial synchronization source is selected.

Steps to create a DRBD resource:

  1. Check the local node name on the first DRBD host.
    $ hostname
    alpha

    The on “alpha” block in the resource file must match this hostname. Repeat the check on the peer node and use its exact hostname in the second on block.

  2. Confirm the backing block device exists on the first node.
    $ lsblk /dev/vg_drbd/webdata
    NAME             MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
    vg_drbd-webdata 253:2    0  100G  0 lvm

    Do not run create-md against a mounted filesystem or the wrong disk. Internal metadata writes to the backing device and can overwrite data if the DRBD source node was not planned first.

  3. Open the resource file on the first node.
    $ sudoedit /etc/drbd.d/webdata.res
  4. Define the resource, local disk, node IDs, and replication path.
    resource "webdata" {
      net {
        protocol C;
      }
      device minor 1;
      disk "/dev/vg_drbd/webdata";
      meta-disk internal;
      on "alpha" {
        node-id 0;
      }
      on "beta" {
        node-id 1;
      }
      connection {
        host "alpha" address 192.0.2.10:7789;
        host "beta" address 192.0.2.11:7789;
      }
    }

    Use persistent block-device names such as LVM paths or /dev/disk/by-id entries instead of bus-based names such as /dev/sdb. The same lower-level device path must exist on both nodes unless a host-specific override is intentionally configured.

  5. Copy the same resource file to the peer node.
    $ scp /etc/drbd.d/webdata.res admin@beta:/tmp/webdata.res
  6. Install the resource file on the peer node.
    $ ssh admin@beta 'sudo install --mode=0644 /tmp/webdata.res /etc/drbd.d/webdata.res'

    Configuration management can replace the copy and install commands when it produces byte-identical resource files on both nodes.

  7. Validate that drbdadm can parse the resource on each node.
    $ sudo drbdadm dump webdata
    resource webdata {
        device               minor 1;
        disk                 /dev/vg_drbd/webdata;
        meta-disk            internal;
        on alpha {
            node-id 0;
        }
    ##### snipped #####
        net {
            protocol           C;
        }
    }
  8. Create DRBD metadata for the resource on each node.
    $ sudo drbdadm create-md webdata
    initializing activity log
    initializing bitmap (32 KB) to all zero
    New drbd meta data block successfully created.

    Run create-md only after confirming which node contains data that must be preserved. Choosing the wrong initial synchronization source later can overwrite the good copy.

  9. Bring the resource up on each node.
    $ sudo drbdadm up webdata

    drbdadm up attaches the backing device, creates the DRBD minor, applies the activity log, and connects to the configured peer.

  10. Check the resource state from the first node.
    $ sudo drbdadm status webdata
    webdata role:Secondary
      disk:Inconsistent
      beta role:Secondary
        peer-disk:Inconsistent

    Inconsistent on both disks is expected before the first synchronization source is selected. Promote only the node that should seed the initial copy.