[DRBD-user] how to restore lvm snapshot?

[Paul O'Rorke]

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 <paul at tracker-software.com 
> <mailto:paul at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20200129/133e111e/attachment.htm>