Typical setups are using a cluster manager like pacemaker or the less feature rich but also less complex drbd-reactor to coordinate promotion attempts and service starts.
But in situation where you "know" that you always want this node to promote and use DRBD and the peer(s) are never going to take over, but only used for "DR" purposes, then this target unit may be useful.
It is intended to be used as dependency of any mount or other use of the specific DRBD resource. 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.
systemctl enable firstname.lastname@example.org systemctl enable email@example.com echo "/dev/drbdX /mnt/point xfs defaults,nofail,firstname.lastname@example.org 0 0" >> /etc/fstab