如何保证LVM2 LV在原始块级别的临时不变性？

Question

我继承了一个 Azure VM (Ubuntu 20.04)，它有一个 7 磁盘 VG，完全被格式化为 ext4 的 RAID5 LV 占用。

我需要进行备份，并希望使用 Azure 备份来为包含 VG 的 Azure 磁盘创建快照。

Azure 磁盘快照在时间点上不一致，因此出于文件系统完整性和 LVM 元数据的原因，我需要在备份运行时冻结存储。我的工作量可以忍受；我正在尝试找出使原始磁盘块暂时不可变的最佳方法。

fsfreeze- 我测试了冻结文件系统、拍摄快照、解冻，然后切换到快照。

在我有限的测试中，这工作正常，当“恢复”的磁盘换回时，我没有看到 LVM 带来任何可怕的情况，但我只能执行这么多测试，并且如果存在 1% 的边缘情况，我的磁盘元数据会丢失会不一致我可能找不到它。

我担心我将活动锁定在如此高的层：在活动时不会发生任何文件系统操作FIFREEZE ioctl，但这是否会阻止 LVM 执行任何类型的较低级别操作，例如元数据更新、RAID 相关活动？

然后我尝试了一下，感觉dmsetup suspend /dev/mapper/my-lvol这是一个更好的解决方案。

测试设置：

fsfreeze

1. echo 3 > /proc/sys/vm/drop_caches
2. sync ; sync（旧习难改 ：）
3. fsfreeze -f /export
4. dd if=/dev/mapper/my-lvol of=/dev/null status=progress

运行dd直至完成。我承认这是有效的，因为我没有通过冻结的文件系统进行访问，但这让我想知道当我假设我的 Azure 磁盘不变时，LVM 是否仍然可以在低级别上执行操作。

dmsetup suspend

1. echo 3 > /proc/sys/vm/drop_caches
2. sync ; sync
3. dmsetup suspend /dev/mapper/my-lvol
4. dd if=/dev/mapper/my-lvol of=/dev/null status=progress

dd只要暂停到位，就会阻塞。我仍然可以使用dd和rmeta设备rimage，但我有点预料到了。

使用该dmsetup选项，我收到挂起任务系统日志警告jbd2。堆栈跟踪显示它正在尝试提交日志事务 ( jbd2_journal_commit_transaction())，这既让我放心，LV确实已锁定，但也让我担心，我正在以不一致的状态对文件系统进行快照，并且如果我们回滚，它可能需要重播日志到快照。我们的 RPO 将允许一些回滚，但理想情况下我想设计一个解决方案来消除这种风险。

我放弃的选项

1. 基于文件的备份：可能，但设置和管理似乎比冻结快照更复杂 - 首先！
2. 临时对 LV 进行快照并从中进行备份。VG 已满，我真的不想添加更多磁盘/调整 VG 大小等。

问题

我非常感谢这里的任何意见。正如你所见，我对 Linux 文件系统/块 IO 的理解处于边缘（甚至可能超出）。

1. 总体而言，冻结/暂停似乎是获得时间点一致快照的可行解决方案吗？
2. 我是否仍然不够深入 - 只是因为jdb2无法编写事务可以lvm或dm仍然在较低级别进行元数据更新？

谢谢，蒂姆