'\" t
.\"     Title: drbd@.target
.\"    Author: LINBIT HA Solutions GmbH https://linbit.com
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
.\"      Date: 2023-01-09
.\"    Manual: DRBD Manual
.\"    Source: drbd-utils
.\"  Language: English
.\"
.TH "DRBD@\&.TARGET" "7" "2023\-01\-09" "drbd\-utils" "DRBD Manual"
.\" -----------------------------------------------------------------
.\" * Define some portability stuff
.\" -----------------------------------------------------------------
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.\" http://bugs.debian.org/507673
.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.ie \n(.g .ds Aq \(aq
.el       .ds Aq '
.\" -----------------------------------------------------------------
.\" * set default formatting
.\" -----------------------------------------------------------------
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.\" -----------------------------------------------------------------
.\" * MAIN CONTENT STARTS HERE *
.\" -----------------------------------------------------------------


.SH "NAME"
drbd@.target \- System target unit indicating a configured (optionally: promotable) DRBD resource
.SH "SYNOPSIS"

.sp
drbd@\&.target

.SH "DESCRIPTION"

.sp
Usually you do not want to "hardcode" an unconditional promotion attempt of DRBD resources, because you usually cannot know a\-priory whether this instance of DRBD will have access to good data (yet)\&.
.sp
Typical setups are using a cluster manager like \fBpacemaker\fR or the less feature rich but also less complex \fBdrbd\-reactor\fR to coordinate promotion attempts and service starts\&.
.sp
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\&.
.sp
It is intended to be used as dependency of any mount or other use of the specific DRBD resource\&. The implicit dependency on \fBdrbd@\fR\fIRESNAME\fR\fB\&.service\fR will configure DRBD, an optional \fBdrbd\-lvchange@\fR\fIRESNAME\fR\fB\&.service\fR can be used to attempt to activate the backend logical volumes first\&. The optional (but in this scenario necessary) \fBdrbd\-wait\-promotable@\fR\fIRESNAME\fR\fB\&.service\fR is then used to wait for DRBD to connect to its peers and establish access to good data\&.

.SH "EXAMPLE"

.sp
Assuming you have a DRBD resource named \fIwebdata\fR, its backing devices being LVM logical volumes, with an xfs on one volume showing up as \fI/dev/drbd0\fR, this should make your boot sequence successfully mount that drbd to \fI/mnt/point\fR (unless DRBD really finds no access to good data in time, or some peer is already primary):

.sp
.if n \{\
.RS 4
.\}
.nf
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
.fi
.if n \{\
.RE
.\}
.sp

.SH "SEE ALSO"

.sp
\fBdrbd-reactor\fR(1), \fBdrbd-reactor.promoter\fR(5)

.SH "AUTHORS"
.PP
\fBLINBIT HA Solutions GmbH https://linbit\&.com\fR