就我的经验而言，为了创建有用且一致的备份，必须让应用程序处理要备份的数据。我想与其他系统管理员一起验证我的发现。
考虑这样一种情况：应用程序打开了一个文件进行读写，在保持打开状态时，一个单独的备份进程读取该文件。（如果我们使用 flocks，则可以这样做，并且强制的而不是咨询我们必须让应用程序参与进来）。大家应该普遍认为，这个打开的文件创建的备份可能是不一致的。
在文件系统级别使用快照无法完全缓解这种情况；因为我们无法保证在快照时间点吨所有应用程序都已将一致的文件写入磁盘（假设吨我们能够刷新所有缓冲区）。
因此，在创建适当的备份计划时，必须始终牢记哪些应用程序写入数据以及它们如何写入数据 - 并确保它们在拍摄快照/备份之前将一致的文件写入磁盘。
您是否同意我的观点，或者我在思考这个问题时是否犯了根本性的错误？
（请不要用任何具体的 HOWTO 来回答这个问题，因为这是关于一般的“高级”原则。另外，为了确保万无一失，这是不是关于 DB，因为那里的问题已经解决了)。
答案1
您似乎对这些问题有很好的理解。
我见过的标准快照方法是关闭将写入文件系统的服务，中断快照并重新启动服务。备份未写入的那一侧。
另一种方法是能够从应用程序中导出某个时间点的数据集。然后备份导出的数据。这是数据库可能使用的一种方法。数据可能会在导出过程中进行转换，因此导入数据可能需要额外的步骤。
我使用过另一种数据库处理方法，即在复制文件时将其标记为已备份。这可能会在备份运行时推迟更新，或者允许稍后重播更改。这需要更改日志，也需要备份。
我通常从标准备份中排除数据库文件，并使用其中一种替代方法从数据库中获取时间点数据。
恢复数据库前请仔细规划。我很少需要将整个数据库恢复到某个时间点。冷备份（数据库关闭）可能适合用于培训的数据库。我很后悔为测试数据库提供类似的回滚功能。
答案2
您是否同意我的观点，或者我在思考这个问题时是否犯了根本性的错误？
从根本上讲，我想指出一个重要的考虑因素：停电仍然会发生，这对备份有很大帮助。任何处理停电（即 CPU 和 RAM 包括磁盘缓存的硬性损失）的应用程序也可以处理从快照恢复。任何不这样做的应用程序 - 是的，在这种情况下你是对的 - 都需要特别小心。
对于许多类别的数据存储来说，这是一个已解决的问题 - 特别是对于被描述为“日志式”的数据存储或任何非易失性非玩具数据库引擎。
当一个应用程序使用多个文件系统时，事情会变得复杂，但一些快照方法可以使它们保持一致。
答案3
我也在想同样的事情。也许使用 CQRS 和事件源或任何其他仅附加策略是一个很好的解决方案。如果您将附件保存在文件系统而不是事件存储中，那么您应该将文件标记为删除并仅在备份后删除它们。因此，如果在备份期间发生删除，它不会对备份一致性产生任何影响。至于查询数据库，我认为最好使用事件存储的备份在单独的服务器上重建它们，这样它就不会影响正在运行的应用程序的读取性能，并且您可以确保它也是时间点一致的。我仍然不确定是否有可能在不停止正常应用程序的情况下对其进行一致备份。