我最近在一台装有 Centos 7 操作系统的 Google Compute Engine VM 上进行了恢复测试。该 VM 有五个分区磁盘，由 LVM 管理。该服务器已经运行了一段时间，因此磁盘上分布着大约十个文件系统。所有快照都是在凌晨一两秒内创建的。
看起来恢复进展顺利，df产出看起来符合我的预期。
我只是运气好吗？
我通常预计从表面上不同步的快照恢复时会遇到麻烦。
我在想：我是否需要使用“适当的”逻辑卷感知备份系统来确保恢复的文件系统的一致性？或者如果做不到这一点，我是否应该确保每个文件系统都在自己的单个磁盘上？或者我是不是在不必要地担心？
答案1
GCP 建议将每个文件系统放在它自己的单个磁盘上。
如果使用单一文件系统且无分区表来格式化持久磁盘，则可以节省时间并获得最佳性能。
从标准系统管理员的角度来看，这可以看作是一种资源浪费，因为可以连接到实例的磁盘数量是有限的，但是管理备份更容易。
- 具有共享核心机器类型的实例最多限制为 16 个持久磁盘。
- 对于自定义机器类型或具有至少 1 个 vCPU 的预定义机器类型，您最多可以连接 128 个持久磁盘。
- 每个永久性磁盘的最大容量可达 64 TB，因此无需管理磁盘阵列来创建大型逻辑卷。每个实例只能附加有限数量的总永久性磁盘空间和有限数量的单个永久性磁盘。预定义机器类型和自定义机器类型具有相同的永久性磁盘限制。
- 大多数实例最多可连接 128 个永久性磁盘，总永久性磁盘空间最多可达 257 TB。实例的总永久性磁盘空间包括启动磁盘的大小。
- 共享核心机器类型限制为 16 个持久磁盘和 3 TB 总持久磁盘空间。
如果我理解正确的话，您将 5 个单独的磁盘连接到您的实例，然后继续创建 PV、VG、LV 和 FS。最后，您为每个磁盘拍摄了快照几乎同时
看来您在快照之间没有对磁盘进行任何更改，但我不建议将此架构用于敏感应用程序（例如数据库），因为我会担心数据一致性。如果您在磁盘快照之间以更长的时间重复实验并遇到数据一致性问题，我不会感到惊讶。