[DRBD-user] LVM backing snapshot + restore

Simon Ironside sironside at caffetine.org
Wed Jul 24 10:13:30 CEST 2013

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.

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.


More information about the drbd-user mailing list