MySQL企业备份4.0版本说明
当系统管理员试图在使用分布式文件系统(DFS)或存储访问网络(SAN)的环境中设置MySQL和MySQL Enterprise Backup时，MySQL服务器、服务器的数据目录、MySQL Enterprise Backup和备份目录可能最终存在于不同的物理服务器上。当这种情况发生时，运算mysqlbackup可能会受到影响。最可能受到负面影响的操作是热备，其成功与否取决于:
数据文件的每一页都是一致复制的，即该页中的所有字节都对应同一个LSN。
任何复制的页都不早于标记备份应该覆盖的临时持续时间的开始的时间。
重做日志是一致复制的，这意味着复制了一段连续的重做日志，它包含了从备份要覆盖的临时周期开始到备份操作结束的所有更改。复制的重做日志的每个块必须是一致的。
大多数性能合理的dfs或san很容易达到条件1。即使条件1得到了满足，条件2仍然可能不满足:例如，mysqlbackup是否可以正确复制表空间的所有页，除了其中一个页mysqlbackup在副本中包含了一个旧版本。如果旧版本页面的LSN小于第一次看到的LSNmysqlbackup在备份过程开始时，生成的备份将是有缺陷的。这个例子表明mysqlbackup除非它能看到对文件系统的写操作以正确的顺序(即服务器执行它们的顺序)执行，否则可能会在执行热备份时遇到问题。
关于条件3，与数据文件页不同，重做日志块是按顺序写入的，这意味着条件3比条件1和条件2更容易实现。然而,如果mysqlbackup在遇到重做日志结束前，已达到复制数据文件页中的最高LSN，则备份失败。也会发生故障mysqlbackup在复制重做日志期间，随时读取损坏的日志块。这两种失败都可能发生在mysqlbackup不会看到与MySQL服务器相同的文件系统状态历史记录。
因此,使用mysqlbackup对于DFS或SAN，重要的是要确保mysqlbackup查看所有写入文件系统的顺序与MySQL服务器相同。条件最可能被满足时mysqlbackup和MySQL服务器运行在同一个服务器节点上，如果不是这样，就不太可能总是实现。