Mysql 选择 逻辑备份 or 物理备份？

为什么要备份？

这里有大概以下几个原因

• 灾难恢复
• 人们改变了想法或误操作
• 审计，法律规定
• 测试

备份方案得建议：

• 再生成实践中，对于大数据库来说，物理备份是必须得（注：但是像使用 RDS等云数据库，无法访问底层文件得话，就只有逻辑备份 ）逻辑备份太慢并收到资源限制，从逻辑备份中恢复需要很长时间，这也是最大得缺点。基于快照得备份。对于较小得数据库，逻辑备份可以很好地胜任。
• 保留多个备份集。
• 定期从逻辑备份（或者物理备份）中抽取数据进行恢复测试。
• 保存二进制日志以用于基于故障时间点得恢复。二进制日志文件需要保存足够长时间，一遍能从最近得逻辑备份进行恢复。
• 完全不借助备份工具来监控备份和备份过程。需要另外验证备份是否正常。
• 通过演练整个恢复过程来测试备份和恢复。测算恢复所需要得资源（CPU,磁盘空间，实际时间，以及网络带宽等）。
• 对安全性要仔细考虑。如果有人能接触生成服务器，他是否也能访问备份服务器？反过来呢？

逻辑备份还是物理备份?

逻辑备份：也叫“导出”，将数据包含再一种Mysql能够解析的格式中，要么是SQL，要么是以某个符号分隔的文本。

物理备份：直接copy存在于硬盘上的文件。

逻辑备份

优点：

• 逻辑备份是可以用编辑器或像grep何sed之类的命令查看何操作的普通文件。当需要回复数据或只想查看数据但不恢复时，这都非常有帮助。
• 恢复很简单。可以通过管道把它们输入到mysql,或者使用mysqlimport.
• 可以通过网络来备份何恢复——就是说，可以在与Mysql主机不同的另外一台机器上操作。
• 可以在类似 RDS 这样不能访问底层文件系统的系统中使用。
• 非常灵活，因为mysqldump——大部分人喜欢的工具——可以接受许多选项，例如可以用where子句来限制需要备份哪些行。
• 与存储引擎无关。因为是从Mysql服务器中提取数据而生成。所有消除了底层数据存储和不同。因此，可以从InnoDB表中备份，然后只需要极小的工作量就可以还原到MyISAM表中。而对于原始数据却不能这么做。
• 有助于避免数据损坏。如果磁盘驱动器有故障而需要复制原始数据文件时，你将会得到一份错误并且/或生成一个部分或损坏的备份。如果Mysql在内存中的数据还没哟损坏，当不能得到一个正常的原始文件复制时，有时可以得到一个可以信赖的逻辑备份。

缺点：

• 必须由数据库服务器完成生成逻辑备份工作，因此要使用更多的CPU周期。
• 逻辑备份在某些场景下比数据库文件本身更大。ASCII形式的数据不总是和存储引擎存储数据一样高效。例如，一个整形需要4个字节来存储，但是用ASCII写入时，可能需要12个字符。当然也可以压缩文件以得到一个更小的备份文件，但这样会使用更多的CPU资源。（如果索引比较多，逻辑备份一般比物理备份小）
• 无法保证导出后再还原出来的一定是同样的数据。浮点表示的问题，软件BUG等都会导致问题，尽管很少见。（因此需要定时检查备份数据的完整性）
• 从逻辑备份中还原需要Mysql加载和解释语句，转化为存储格式，并重建索引，所以这一切会很慢

其实生产环境中，上诉最大的缺点还是关注再 Mysql 导出数据 和 通过SQL语句将其加载回去的开销。如果使用逻辑备份，测试恢复需要的时间将非常重要

物理备份

优点：

• 基于文件的物理备份，只需要将需要的文件复制到其他地方即可完成备份。不需要其他额外的工作来生成原始文件。
• 物理备份的恢复可能就更简单了，这取决于存储引擎。对于MyISAM，只需要简单地复制文件到目的地即可。对于InnoDB则需要停止数据库服务，可能还要采取其他一些步骤。
• InnoDB和MyISAM的物理备份非常容易跨平台，操作系统和MySQL版本。（逻辑导出也如此）
• 从物理备份中恢复会更快，因为Mysql服务器不需要执行任何SQL 或构建索引。如果由很大的InnoDB表，无法完全缓存到内存中，则物理备份的恢复要快非常多——至少要快一个数量级。事实上，逻辑备份最可怕的地方就是不确定的还原时间。

缺点：

• InnoDB的原始文件通常比相应的逻辑备份要大得多。InnoDB得表空间往往包含很多未使用得空间。还有很多空间被用来做存储数据以外得用途（插入缓冲，回滚段等）。
• 物理备份不总是可以跨平台，操作系统及Mysql版本。文件名大小写敏感和浮点格式时可能会遇到麻烦。很可能因为浮点格式不同而不能移动文件到另一个系统
• 物理备份通常更加简单有效。尽管如此，对于需要长期保留备份，或者是满足法律合规要求得备份，尽量不要完全依赖物理备份。至少每隔一段时间还是需要做一次逻辑备份。
•