DRBD@.TARGET(7)

💖 drbd@.target — the DRBD Manual, section 7 💖

okay bestie, gather round, because this one is a systemd target unit and it is genuinely iconic. it's called drbd@.target, it lives in the DRBD Manual (that's section 7 of the manual, for the record), and it means "this node is a configured DRBD resource, and maybe — maybe — it wants to be promotable." ✨

---

🌸 NAME 🌸

drbd@.target — the system target unit that says a DRBD resource is configured, and optionally that it's promotable. like, it's giving "i am set up and i am ready" energy. 💅

---

🦋 SYNOPSIS 🦋

drbd@.target

that's it. that's the whole synopsis. no flags, no arguments, no drama. just vibes. 🎀

---

👑 DESCRIPTION 👑

so here's the thing, and i need you to hear me on this one: you usually do not want to hardcode an unconditional promotion attempt of DRBD resources. why? because you usually can't know a-priori whether this instance of DRBD will actually have access to good data yet. 😭 it's literally a mystery until it isn't.

typical setups let a cluster manager do the thinking — like pacemaker, or the less feature rich but also less complex drbd-reactor — and those coordinate promotion attempts and service starts for you. that's the grown-up way. 🫶

but (and this is the plot twist) in situations where you know that you always want this node to promote and use DRBD, and the peer(s) are never going to take over and are only used for "DR" purposes — then this target unit may be useful. key word: may. 🔥

it's intended to be used as a dependency of any mount or other use of that specific DRBD resource. here's the dependency chain, and it slays:

• the implicit dependency on drbd@RESNAME.service will configure DRBD.
• an optional drbd-lvchange@RESNAME.service can be used to attempt to activate the backend logical volumes first.
• the optional (but in this scenario necessary) drbd-wait-promotable@RESNAME.service is then used to wait for DRBD to connect to its peers and establish access to good data. ⭐

bestie, notice the "optional but necessary" thing. it's optional in general, and mandatory if you're doing the thing this whole page is about. do not skip it, i'm begging. 🙈

---

🌈 EXAMPLE 🌈

let's make it real. say you have a DRBD resource named webdata, its backing devices are LVM logical volumes, and there's an xfs on one volume showing up as /dev/drbd0. this should make your boot sequence successfully mount that drbd to /mnt/point — unless DRBD really finds no access to good data in time, or some peer is already primary. 😬

systemctl enable drbd-lvchange@webdata.service
systemctl enable drbd-wait-promotable@webdata.service
echo "/dev/drbdX /mnt/point xfs defaults,nofail,x-systemd.requires=drbd@webdata.target 0 0" >> /etc/fstab

look at that fstab line. defaults,nofail,x-systemd.requires=drbd@webdata.target. chef's kiss. 👑

but — and i cannot stress this enough — you really should let drbd-reactor handle the mount (and the services using it) instead. like, seriously. that's the move. 💜

---

💀 SEE ALSO 💀

• drbd-reactor(1)
• drbd-reactor.promoter(5)

go read those too, iykyk. ✨

---

🎀 AUTHORS 🎀

LINBIT HA Solutions GmbH — https://linbit.com 🫶

---

and that's the whole page, bestie!! this was drbd-utils, dated 2026-08-15, and it's the DRBD@.TARGET(7) man page, periodt. 💅✨