[DRBD-user] Regarding Best way for snapshotting with ZFS/LVM as backing disk for drbd

[GM]

>
> But Why do we need to preserve the metadata via snapshot at the first
> place as it is believed that once you rollback the using the snapshot drbd
> would get confused and would attempt resynchronisation of the entire device
> again any way
>

Consider the following scenario, Two nodes A and B. A is the Primary and B
is the Secondary. You create a zfs snapshot (both data and drbd metadata)
at 08:00 am on both nodes. At 08:30 am you realise that a serious
corruption has taken place and you urgently need to rollback *both* nodes
from the snapshot created at 08:00 am. You execute a zfs rollback on both
nodes while the drbd resource is down of course. Before bringing the drbd
resource up on both nodes, you must decide which way the replication must
take place (e.g A -> B or B -> A). Once you decide, bring the resource up.
If all goes well, drbd should bring up the resource on both nodes *without*
needing to do a full sync but rather just a small increment instead, as the
metadata is consistent on both nodes (as it was at the time the snapshot
was taken). So it's important to snapshot the drbd metadata on both nodes,
if you want to prevent a full sync.


> 3) Do i need to suspend-io first before taking the snapshot and then check
> up to date Status mandatorily ?
>

Ideally yes but that depends if the layers above drbd supports that
functionality. For example, I'm using qemu VMs on top of drbd/zvol. QEMU
can suspend i/o before issuing a qemu based snapshot (via guest tools)
which then it will propagate at the layers below (e.g drbd -> zfs). If the
layers above drbd cannot handle this, and you could simply take a snapshot
at the layer below drbd (zfs in this case), then that would have the same
effect as when removing the power from the physical machine (e.g the data
would still be consistent due to zfs transaction based nature, but you may
or may have have not lost the last few writes issued by the layers above).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20220801/b91142dc/attachment.htm>