> > 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
