据我的经验， 为了创build一个有用的，一致的备份，必须包含处理要备份的数据的应用程序 。 我想与其他系统pipe理员validation我的发现。
考虑一下应用程序打开R / W文件的情况，并且保持打开状态时，单独的备份过程读取文件。 （并且允许这样做 – 如果我们使用鸡群，而且是强制性的而不是build议性的 ，那么我们就不得不涉及到应用程序）。 应该普遍同意，这个打开的文件创build的备份可能不一致。
在文件系统级使用快照不能完全缓解这一点; 因为我们无法保证在快照时间点t所有应用程序都已经向磁盘写入了一致的文件（假设我们能够刷新所有的缓冲区）。
因此，在创build适当的备份计划时，必须始终牢记应用程序在哪些数据上写入数据，以及如何进行数据备份，并确保在执行快照/备份之前将一致的文件写入磁盘。
你是否同意我的观点，或者在思考这个问题时是否犯了根本的错误？
（请不要用任何具体的HOWTO来回答这个问题，因为这是关于一般的“高层次”的原则。而且，只是为了确定，这不是 DB的问题，因为问题已经被解决了）。
你似乎对这个问题有很好的理解。
我所看到的标准快照方法是closures将写入文件系统的服务，中断快照并重新启动服务。 备份不被写入的一面。
另一种方法是能够从应用程序中导出时间点数据集。 然后备份导出的数据。 这是数据库可能使用的一种方法。 数据可能会在导出期间转换，因此可能需要额外的步骤来导入数据。
我使用数据库的另一种方法是将文件标记为在复制时备份。 这可能会在备份运行时推迟更新，或者可能允许稍后重播更改。 这需要更改日志，这也需要备份。
我通常从我的标准备份中排除数据库文件，并使用其中一种替代方法从数据库获取时间点数据。
在恢复数据库之前仔细计划。 我很less需要恢复一个完整的数据库到一个时间点。 冷备份（数据库closures）可能适用于培训中使用的数据库。 我后悔提供类似的回滚testing数据库。