我对 InnoDB 引擎的理解是，由于引擎本身的内部架构，数据库在崩溃后始终可以恢复。也就是说，InnoDB 可以从崩溃一致状态中正确恢复。即，如果断电。
另一方面，在 vSphere 中对虚拟机进行快照时，互联网上的普遍观点认为，备份将具有崩溃一致性，但可能会导致 InnoDB 数据库损坏，除非虚拟机处于静止状态。这似乎与上述情况不一致。
Tldr；InnoDB 是否真的能够从崩溃一致状态中恢复，如果可以，那么在不静止的情况下对 VM 进行快照难道不应该是一种安全的备份方法吗？
答案1
永远不要假设某些事物总是可恢复且一致的！
崩溃恢复文件系统并不一定意味着您的文件完好无损。可能会丢失（希望是少量）未提交的文件系统写入。最坏的情况是，元数据变得不一致，并且 fsck 恢复了文件系统，但可能会丢失文件。这也适用于您的数据库日志，根据您的恢复点目标，这可能会有问题。
文件一致性是一个更强的要求：文件处于稳定状态。fsck 应该已经干净了。有几种方法可以做到这一点，VMware 工具 vmsync、Linux LVM 快照或 fsfreeze、Windows VSS。
即使某个时间点的文件也并不意味着应用程序的一致性。数据库将具有未提交到磁盘的内存更新。并且正在运行的系统上始终在发生新的更新。理想情况下，将数据库写入刷新到磁盘并暂停进一步的写入，直到拍摄存储级别快照。
或者，当然可以进行不一致的备份，并更多地依赖日志进行恢复。这会使备份的恢复过程稍微复杂一些。
到目前为止，我根据您选择的存储快照假设了存储级别备份。对备份方法的更全面评估将同时考虑逻辑转储和物理原始文件。MariaDB 的备份技术快速入门指南比较了每种方法的多种实现。例如，看看 mylvmbackup 如何执行刷新和快照，以及 XtraBackup 如何执行重做日志恢复。
当然，没有恢复，备份就毫无意义。一定要进行恢复测试。在执行此操作时，验证恢复点：最后恢复的数据是什么？
答案2
使客户机静止是为了确保所有具有待处理 I/O 操作的进程在实际允许 ESXi 快照操作进行之前完成将数据写入磁盘。
这意味着 ESXi 快照系统（位于客户机外部）与客户机 FS 本身之间的协调。此协调由以下人员执行：VMWare 工具， 或者打开虚拟机工具（推荐）在 Linux 系统中。
当执行静默快照并且它没有返回任何错误时，您可以确保基本磁盘中的数据是一致的，并且在当前快照下方的磁盘中执行的任何备份也将是一致的。
值得一提的是，Linux 系统的静默除了 open-vm-tools 之外不需要任何其他工具，它通常开箱即用，而 Windows 客户机除了 VSS 和虚拟磁盘服务之外还需要许多特定于您正在使用的 DB 系统的附加服务。
备择方案：
某些 DB 系统可能没有与 VMWare Tools 配合使用的绑定，因此无法使数据库服务处于静止状态。您可以使用多种替代方法来解决该问题。
1 - 您可以执行冷备份，即：停止虚拟机，拍摄快照并打开它。基础数据将完全一致，因为快照是在关闭的虚拟机上拍摄的。
2 - 您可以停止数据库服务并执行来宾备份，然后重新打开它。数据也将保持一致，因为在进行备份时数据库实际上并未使用。
3 - 将数据库服务器设置为只读，然后备份，并将其设置回R&W模式。
4 - 在客户机文件系统中拍摄一张或一系列快照。如果您使用的是 Windows Server，请在备份之前拍摄一些 VSS 快照。如果由于某种原因备份数据最终不一致，您可以轻松地恢复到具有一致数据的 VSS 快照之前的点。