This assumes that you've at least created the correct partition for your DRBD already.
Notice that I am "diskless", that's because either your DRBD partition doesn't exist/has been renamed (eg. sdb becomes sda when sdb dies and you reboot) or because that drive is really actually dead/gone.

*If you need to permanently change the partition/device for your resource be sure to edit /etc/drbd.conf on both hosts and reload the config.

(replace r0 with the name of the resource you're recovering from):
drbdadm create-md r0

DRBD module version: 8.3.4
   userland version: 8.3.8
preferably kernel and userland versions should match.
Writing meta data...
initializing activity log
NOT initialized bitmap
New drbd meta data block successfully created.

drbdadm attach r0

That's all there is to it, you're recovered and just need to wait for the sync to complete.

Check /proc/drbd and you'll see it is rsyncing to your newly added disk.

cat /proc/drbd
version: 8.3.4 (api:88/proto:86-91)
GIT-hash: 70a645ae080411c87b4482a135847d69dc90a6a2 build by xemul@ovzcore.sw.ru, 2009-10-12 19:29:01
 0: cs:SyncTarget ro:Secondary/Primary ds:Inconsistent/UpToDate A r----
    ns:0 nr:378692 dw:378340 dr:0 al:0 bm:22 lo:13 pe:1478 ua:11 ap:0 ep:1 wo:b oos:487894364
    [>....................] sync'ed:  0.1% (476456/476828)M
    finish: 2:08:56 speed: 63,056 (63,056) K/sec
 

drbd, partition, commandsthis, assumes, ve, quot, diskless, doesn, renamed, eg, sdb, sda, reboot, permanently, resource, edit, etc, conf, hosts, reload, config, recovering, drbdadm, md, module, userland, preferably, kernel, versions, meta, initializing, initialized, bitmap, successfully, attach, recovered, sync, proc, ll, rsyncing, newly, disk, api, proto, git, hash, ae, dc, xemul, ovzcore, sw, ru, cs, synctarget, ro, secondary, primary, ds, inconsistent, uptodate, ns, nr, dw, bm, pe, ua, ap, ep, wo, oos,

Latest Articles