Re: Regarding Best way for snapshotting with ZFS/LVM as backing disk for drbd

Many Thanks for valuable suggestions and sharing your experiences.

On Mon, 1 Aug 2022 at 22:26, GM <[email protected]> wrote:

> 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).
>
> _______________________________________________
> Star us on GITHUB: https://github.com/LINBIT
> drbd-user mailing list
> [email protected]
> https://lists.linbit.com/mailman/listinfo/drbd-user
>

_______________________________________________
Star us on GITHUB: https://github.com/LINBIT
drbd-user mailing list
[email protected]
https://lists.linbit.com/mailman/listinfo/drbd-user