#504 PR merged: skip the procedure of "drbdadm attach" when restore

Labels: enhancement

tbsky opened issue at 2014-11-05 06:38:

hi:
this patch is related to the issue https://github.com/rear/rear/issues/483
when restoring drbd, we can set drbd to situation below:

  1. make local drbd primary and connect to peers, which is very dangerous, since it may overwrite good data of remote peer. rear ask for user's confirm (user need to type "yes" to enter the state). in this state drbd device can be written by rear, so further mount/restoring data of drbd device is possible.
  2. make local drbd secondary. rear didn't have this option for user. but it is no big deal. you can do that after restore/reboot and sync data from master.
  3. other state. currently rear use "drbdadm attach" to let drbd go into standalone state. in this state rear can not write to drbd device, so there is nothing need to do about it anymore. unfortunately "drbdadm attach" behavior is different between drbd version 8.3 and 8.4. and upstream already confirm this is a feature, not bug. so "drbdadm attach" will fail under drbdadm 8.4 and restore will be interrupted.

in my opinion, rear seems simply use "drbdadm attach" to let drbd go to a "nothing need to do" state. (maybe there are other use case when drbd go into the state, but I can not think about it myslef).
if we just want drbd go to "nothing need to do" state, we don't need to do anything about drbd. so we may skip the "drbdadm attach" command and let drbd at quiet state. this is what the patch do.

in theory if we let drbd go to standalone and primary state, we can write to drbd device and prevent overwrite peer data, but the command to do this is different between 8.3,8.4 and maybe 9.0.

and consider the real case when doing drbd node disaster recovery:

  1. there is still drbd node alive. so you just need to restore the drbd node and choose "nothing to do" state (press enter when rear recover). after reboot you sync data from remote peer.
  2. there are no other drbd node alive. so when restore you let drbd to to "primary" state and restore data to drbd device. since there are no other drbd node alive, you won't have risk to overwrite peer data.

so rear is enough now for each case. there maybe one thing happen: you still have other drbd node alive, but when you restore you accidentally type "yes" when rear ask for confirm. then you will overwrite good data of peer. it is something like "rm -rf /*". I hope I won't be that unlucky administrator...

[Export of Github issue for rear/rear.]