Well (ironically?) you have me wondering if my approach may have issues
I simply have not encountered, possibly due to good luck, so I am
interested in hearing from others whether I should reconsider my approach...
I received a lot of invaluable help from the list, and in particualr one
very helpful gentleman named Simon Ironside back in 2013 when I
initially set this up. Thanks again Simon if you are still on this list.:
On 23/07/2013 18:11, Charles Lyons - ConnetU wrote:
If we snapshot the LV itself, presumably we'll get a copy not only of
the VM's volume block data but also of DRBD metadata on the LV (which I
understand is stored in the end/final segment(s) of the LV).
Yes, assuming you are using internal metadata. I'm doing exactly this
too.
(1) Is there any danger of this process not giving a DRBD-consistent
snapshot? Is there anything within DRBD which needs to be flushed/synced
prior to starting the snapshot (as is the practice with SQL)?
I've found it to be 100% reliable, it worked absolutely fine when I
really needed it.
(2) How is best to restore an image file of the LV, assuming the VM is
offline and, if necessary, the DRBD resource can be
detached/disconnected on each/both side(s)?
I treat it more or less like a new resource. I do the below, this
works but is perhaps OTT:
# Shutdown the VM
drbdadm secondary <resource> # on the primary node
drbdadm down <resource> # on both nodes
# Restore the LV image to the LV on one node
drbdadm create-md <resource> # on both nodes
drbdadm up <resource> # on both nodes
drbdadm -- -o primary <resource> # on the node I restored
# Start the VM
Because you have new metadata on both nodes, there will be a full
resync doing the above.
I suppose, but have not tried and proven, that this could be
simplified by just doing:
# Shutdown the VM
# Restore the LV image to the DRBD resource in primary role.
# Start the VM
The LV image will of course be longer than the DRBD resource but the
extra is the metadata at the end of the volume which we're not
interested in anyway. Because you write to the DRBD resource rather
than the underlying LV, the sync to the secondary is already happening
during your restore.
(3) Presumably it doesn't matter if the snapshot is taken on the primary
or secondary?
With protocol C, it doesn't matter.
Second related topic: if we've got an existing snapshot, can we use this
as the basis for creating a totally new DRBD resource... i.e. creating a
new LV of identical size, dd the image to the LV and then create a new
DRBD resource on top. Is there anything in the metadata (like global
UUIDs) which could be duplicated and confuse DRBD? If so, is there a
recommended way to "reset" the metadata prior to attaching so it will
appear as a totally new pre-seeded volume?
Yes, using the method I described above (drbdadm create-md <resource>)
you'll have fresh metadata on both sides. You'll be prompted before it
overwrites the existing metadata.
HTH,
Simon
I have not had to do more than 3 or 4 restores of production servers
since then and in each case took the simple road:
# Shutdown the VM
# Restore the LV image to the DRBD resource in primary role. [I use DD
for this]
# Start the VM
I have even had success restoring directly to the primary, snapshots of
running machines. Perhaps I have just been lucky. The restore includes
the internal metadata as it was when the snapshot was taken and I am
writing to the upper DRBD device and it gets replicated as I write it.
Now I realize I don't really appreciate the potential risks in that.
Can anyone with a more in depth knowledge comment on this?
*Paul O'Rorke*
*Tracker Software Products (Canada) Limited *
www.tracker-software.com <http://www.tracker-software.com/>
Tel: +1 (250) 324 1621
Fax: +1 (250) 324 1623
<http://www.tracker-software.com/>
Support:
http://www.tracker-software.com/support
Download latest Releases
http://www.tracker-software.com/downloads/
On 2020-01-29 12:14 a.m., d tbsky wrote:
Paul O'Rorke <p...@tracker-software.com
<mailto:p...@tracker-software.com>>
I don't know what others do, I just do essentially what you said,
but without stopping the DRBD service. I simply restore the
snapshot to the primary DRBD block device, not the backing device
and let DRBD do it's magic in the background.
thanks a lot for your hint. with lvm under drbd, I think it's not
easy to restore the snapshot directly to drbd. unless I dd the
snapshot to drbd? but it's not efficient. what's you method to
restore snapshot to drbd?
_______________________________________________
Star us on GITHUB: https://github.com/LINBIT
drbd-user mailing list
drbd-user@lists.linbit.com
https://lists.linbit.com/mailman/listinfo/drbd-user
