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
