问它是否足以备份整个服务器--包括MySQL？

EN

我不同意尼尔斯的看法。我承认我不能和MySQL说话，但我可以说，从经验来看，甲骨文是不正确的。

对磁盘上的数据库文件进行快照是非常没有意义的，即使它是即时的。DB包含许多事务，其中一些事务几乎完全刷新到磁盘，一些事务被部分刷新，有些事务几乎完全保留在RAM中。磁盘上的内容可以用DB工具恢复，但不太可能是一个可行的数据库。

更糟糕的是:对于任何大型数据库，备份都需要一些时间，这意味着只有磁盘的备份是完全无用的。把它想象成一个非常模糊的快照；你拍摄的东西移动得相当快(你的数据库)，你把快门打开，等待备份所需的时间(20分钟?2小时? 28小时？)(用于我的一些产品DBs)。照片将非常模糊；您会提前捕捉到一些表，很少有事务提交到磁盘上；另一些事务可能会在数小时后捕获，届时磁盘上可能会有几十万个事务。我不能说你的光盘备份不能直接工作；我甚至不能说你无法用DB法医工具从它中恢复过来；但是我不相信我的工作。

如果您的FS支持快照，而您的DB支持热备份(或等效的)，那么这些都可以工作。热备份是对数据库的一项指令，用于使表空间安静下来；它在某种日志文件上缓冲所有挂起的事务，并在表空间脱离热备份状态时作为整体应用它们。这可以在您停止表空间并将它们备份到磁带时工作，但是如果您能够使表空间安静下来，对底层文件系统进行快照，然后从热备份中释放表空间并将快照滚到磁带中，则这是绝对有效的。

如果你不能做到这一点--而且我经常做不到--那么我所做的就是告诉备份软件完全忽略数据文件，让MySQL先运行mysqldumps到在线存储，然后把它转到磁带上。我从没有遇到过从这些中恢复过来的问题。

但是，正如我在这些情况下经常添加的那样，无论您做什么，您都应该很好地记录它，并经常进行测试。最后一点比任何其他建议都重要。如果你知道它有用，谁会在乎你在做什么？你可以备份使用压缩蠕虫档案写在翅膀案例的蝉，如果它是已知的可靠工作。但是如果你不是在测试它，谁会在乎会说话的服务器负责人说些什么呢？不适合有目的的。

基本上是的-一切都是文件。但是:磁盘上保存数据的文件是不一致的，因为有些数据还在RAM缓存中，而且还没有写入磁盘。

所以，我在很重的负载下备份一个DB，仅仅使用文件备份，您可能会丢失一些事务。按文件进行完整备份的最安全方法是关闭DB，同步磁盘，然后启动备份。或者使用DB--意思是将数据库内容备份到磁盘--这些备份或多或少是一致的。在mySQL中，您可以选择不同的备份模式。

编辑:试试(如果你有可用的话)。在那里，您可以通过GUI指定备份作业。结果将是使用备份规范作为cron作业的相应备份命令。