读数据保护：工作负载的可恢复性14备份和恢复数据库

1. 给采用传统方式交付的数据库制作备份

1.1. 某个数据库是新还是旧，跟该数据库是不是传统数据库没有必然的联系，真正的决定因素在于，这个数据库是不是运行在你所管理的服务器或虚拟机里

• 1.1.1. 如果是，那就可以归入按照传统模型来交付的数据库

• 1.1.2. 如果不是，那么则有可能属于PaaS式数据库或serverless数据库

1.2. 冷备份

• 1.2.1. 要想确保数据文件的内容在制作备份的过程中不会发生变化，最简单的办法是先把数据库实例关掉，然后再去直接备份数据文件

• 1.2.2. cold backup

• 1.2.3. 一个极其安全的办法，只是操作起来通常不太方便

1.3. 在专门剥离出来的replica上做备份

• 1.3.1. split replica backup

• 1.3.2. 选定某个已经处在最新状态的replica，把它从数据库环境里剥离出来，然后针对该replica做备份

• 1.3.3. 方案并不要求数据库在备份过程中停运，它还是可以继续运行在其他的replica上

1.4. 热备份模式

• 1.4.1. hot backup

• 1.4.2. 让你可以对内容正在发生变化的数据文件制作备份

• 1.4.3. 数据库在该模式下会做出一些特殊的处理，让你在数据文件的内容持续发生变化的情况下，依然能够备份这种文件

• 1.4.4. 数据库会在重做日志(redo log)里多记录一些信息，以解决刚才说的那个文件内容在备份过程中一直变化的问题

• 1.4.5. 在数据库进入该模式之后对其做快照(snapshot)，一做完快照，就把它从该模式中切换出来

1.5. snap and sweep

• 1.5.1. 先做快照再清理

• 1.5.2. 快照命令，给数据库制作一份内容协调的快照

• 1.5.3. 首先通过一条命令把数据库切换到特殊模式，然后再做快照

• 1.5.4. 快照已经是一个application-consistent镜像了，我们无论花多久来备份这个镜像，都不会影响数据库本身

• 1.5.5. 以使用snap-and-sweep方案的场合，就是对Windows虚拟机里的数据库做备份

  • 1.5.5.1. 备份软件能够与VSS对接，让VSS进而与数据库产品对接，并令其进入备份模式

  • 1.5.5.2. 就可以制作VSS快照了，做完快照之后，备份软件可以把这个快照备份起来

  • 1.5.5.3. 不用编写任何脚本就能够制作出热备份

1.6. dump and sweep

• 1.6.1. 先转储再清理

• 1.6.2. 先将数据库里的数据转储（也就是dump）成某个东西，然后再在常规的文件系统里清理（也就是sweep）这个东西，把它备份下来

• 1.6.3. 不要求你购买商用的备份软件，也不要求你为了备份数据库而安装任何的agent程序

• 1.6.4. 并非所有的数据库都提供这种机制

• 1.6.5. 使用这个方案时必须注意一个重要的事情，就是要预留足够大的空间，以便同时容纳两个备份

  • 1.6.5.1. 在制作新备份时不应该先把最近制作的那个备份删掉，而是应该等这个新的备份完全制作好再去删除上一个备份，或用这个新备份把上一个替换掉

  • 1.6.5.2. 即便制作新备份的过程中发生了问题，我们也还是有上次制作的那个备份可供使用，而不至于连一个能用的备份都没有

• 1.6.6. 脚本虽然是一种执行备份的绝佳方式，但并非完全没有风险

• 1.6.7. dump and sweep方案对某个数据库很棒，并不意味着它在另一个数据库上的效果同样好

1.7. 让数据流入备份软件

• 1.7.1. 标准的备份方式就是让数据直接流入备份软件，那么这自然是最应该考虑的备份方案了

• 1.7.2. 不要求你自己去定制脚本

  • 1.7.2.1. 你所使用的备份软件应该会有良好的错误汇报机制，让你无须担心刚才说的那几个脚本问题

1.8. 事务日志的备份方式

• 1.8.1. 数据库可能是每天晚上备份一次，然而事务日志则有可能需要每天备份好多次

• 1.8.2. 判断其中有哪些方式适用于自己所使用的这款数据库产品，并确保你最终选择的那种备份方式确实能够把事务日志备份下来

• 1.8.3. 在备份某些事务日志的时候，有的数据库会对你刚备份过的日志做truncate（截断）​，这相当于删除其中的某些内容

  • 1.8.3.1. 如果你的数据库支持这个机制，而且你也启用了该机制，那么必须注意，每次只能让一个进程去备份事务日志，否则在恢复数据时就会变得相当困难

1.9. 主文件的备份方式

• 1.9.1. 文件可能会以JSON文件、控制文件或主数据库等形式出现

2. 备份PaaS与serverless数据库

2.1. 每个平台通常都只有一种真正可行的备份方案

2.2. dump and sweep

• 2.2.1. 在备份PaaS数据库的时候，很少出现只能采用这种方式来备份的情况

• 2.2.2. 某些PaaS平台允许你采用数据库自己的dump工具去备份某些数据库，但却不支持通过同样的工具做恢复

  • 2.2.2.1. AWS RDS的Oracle就是如此，它支持通过RMAN工具做备份，但却不支持通过RMAN恢复

2.3. 通过数据库所集成的备份即服务机制来备份

• 2.3.1. 让数据库服务能够通过该流程频繁地创建镜像副本(image copy)，这样的镜像副本在这种场合通常也称为快照(snapshot)

• 2.3.2. 快照实际上就是对数据库所做的镜像副本，它们通常保存在另一个存储系统里，以求更好地遵循3-2-1原则

• 2.3.3. 会把快照自动复制到另一个存储系统，而不像传统方式那样要求你必须自己去复

• 2.3.4. 一定要对备份做测试

  • 2.3.4.1. 必须彻底地测试你想要选用的备份方案

• 2.3.5. 3-2-1原则

  • 2.3.5.1. 能不能保证至少有一个备份会保存在别处

  • 2.3.5.2. 把所有的备份都存放在同一个账号的同一个存储空间里是不够安全的

  • 2.3.5.3. 至少将其中一个备份保存到别处

3. 数据库产品的备份方式

3.1. Oracle

• 3.1.1. 通过Recovery Manager（恢复管理器）​，也就是RMAN工具来做

• 3.1.2. RMAN还支持一种镜像操作，让你把旧的增量备份合并到完全备份里

3.2. SQL Server

• 3.2.1. 通过backup database命令，让数据库自动为其内容（或其事务日志）制作完全备份或增量备份，你可以把数据备份到磁盘上，以便稍后执行dump and sweep，也可以备份到Azure平台，以便稍后做云端备份

3.3. DB2

• 3.3.1. backup database命令可以对DB2数据库的全部内容或其中一部分内容，以及该数据库的事务日志，制作完全备份或增量备份

3.4. MySQL

• 3.4.1. MySQL的数据表有好几种类型（有些数据表可能是MyISAM表，还有一些可能是InnoDB表）​，不同类型的数据表所支持的备份方案不同

• 3.4.2. Enterprise Backup功能做备份

  • 3.4.2.1. 效率比通过mysqldump命令做备份要高，然而只有InnoDB表能够完全支持此方案

  • 3.4.2.2. 如果你用的是InnoDB表，而且你是企业版用户，那么Enterprise Backup就是最好的方案

• 3.4.3. mysqldump命令的适用面比Enterprise Backup广，无论是不是企业版，都可以用它做备份，但对于大型数据库来说，这样备份的速度特别慢

• 3.4.4. 其他几种备份方式，例如复制表文件、通过二进制日志做增量备份、制作文件系统快照，以及在剥离出来的replica上做备份等

3.5. PostgreSQL

• 3.5.1. 用dump-and-sweep式的备份方案给PostgreSQL数据库做备份时，最常见的一种做法是通过pg dump命令做完整的SQL dump，并将其保存到磁盘

3.6. MongoDB

• 3.6.1. MongoDB Atlas（这是一种PaaS式的MongoDB）​，那么最好的备份方案就是持续制作云备份，以便将来能够执行时间点恢复

3.7. Cassandra

• 3.7.1. 备份方式取决于你使用的是开源版、企业版，还是Astra版（这是一种PaaS式数据库）​

• 3.7.2. 不同版本的Cassandra，其备份方案有很大区别

• 3.7.3. Cassandra是一种弹性（或者说，弹力）较大的数据库，但不要把它的高弹性理解成无须备份

  • 3.7.3.1. 如果有人不小心删掉或截断某张数据表，那么丢失的数据依然无法找回

• 3.7.4. 常见的Cassandra备份工具是nodetool snapshot，这是一种类似于快照的系统，它能够以硬链接的方式，对每一个keyspace或其中某些keyspace中的所有数据制作完全独立的副本

• 3.7.5. Datastax还给企业版用户提供DES备份与恢复服务(DSE Backup and Restore Service)，用来备份并恢复整个集群

• 3.7.6. 如果你用的是Datastax Astra形式的Cassandra，那么数据库每4个小时就会自动备份一次

3.8. DynamoDB

• 3.8.1. DynamoDB只以服务的形式提供，因此可供选择的备份方案都比较直观

• 3.8.2. AWS提供自动备份机制，能够把DynamoDB中的所有数据表或其中一部分数据表备份下来，你可以启用该机制

• 3.8.3. AWS也提供可以由用户控制的按需备份机制，但它并不提供相应的时间点恢复功能

3.9. Neo4j

• 3.9.1. neo4j-admin backup命令来做，该命令能够对一个或多个在线数据库执行完全备份或增量备份

• 3.9.2. 安排好备份流程，让它从那种只负责读取（而不负责写入）数据的replica上执行，以便降低备份流程对性能造成的影响

4. 恢复传统数据库

4.1. 确定问题出在哪里

• 4.1.1. 试着分步骤启动数据库，看它是在哪一步才发生故障的，并检查该步骤所涉及的那些部件是不是有问题

• 4.1.2. 查明出错原因，可以让你在恢复时节省大量时间

  • 4.1.2.1. Oracle数据库仅是因为控制文件出错而无法运作，那么只需要从备份里找到这个控制文件并将其恢复出来，然后重新启动数据库即可

  • 4.1.2.2. 有时问题可能仅出在控制文件上

4.2. 恢复数据文件

• 4.2.1. 如果你是用冷备份、热备份、snap and sweep或直接把数据流发送给备份软件等方式来制作备份的，那么只需要在备份软件里直接操作

• 4.2.2. 如果你是用dump-and-sweep方式备份的，那么你应该首先判断，你所要找的那个备份是不是放在平常执行备份的那个地方

  • 4.2.2.1. 如果是，那么直接执行恢复命令

  • 4.2.2.2. 如果不是，那么必须先从备份系统里把你当初dump（收集）到的文件提取出来，然后才能执行数据库恢复命令

  • 4.2.2.3. 要分两个阶段才能把数据恢复出来

4.3. 做介质恢复

• 4.3.1. 如果你的数据库能够重放事务日志，而且你手里也有这样的日志，那就可以在恢复数据库之后重放，从而把数据库的状态由制作备份时的那一点向目前推进

• 4.3.2. 由于你所备份的数据文件是在不同的时间点上备份的，因此你必须通过该步骤让这些数据文件全都对齐到同一个时间点

4.4. 启动数据库

5. 恢复新型数据库

5.1. 其恢复流程取决于你是如何备份这种数据库的，以及你备份的是哪些内容

• 5.1.1. 还要考虑到数据库采用的是立即一致性模型，还是最终一致性模型

5.2. 不要一直拖到真正需要恢复数据库时再去观察方案的恢复效果

• 5.2.1. 演练你的数据恢复方案

• 5.2.2. 如果演练得不到位，那么万一出现状况，有人（尤其是你自己）可能就会因此而丢掉工作

5.3. 在云平台上，即便数据库很大，测试起来也相当容易，所以别把不方便测试当成借口

5.4. 有些数据库无须做介质恢复即可实现时间点恢复

• 5.4.1. 有些新式数据库会相当频繁地制作基于快照的备份，并以此来实现时间点恢复

• 5.4.2. 只需要选择适当的快照并执行恢复命令，然后重新启动数据库，就可以完成时间点恢复

5.5. 基于数据表的恢复

• 5.5.1. 新式数据库的某些备份方案只能在数据表层面备份数据，因此，恢复时也只能在数据表层面恢复

5.6. 节点层面的恢复

• 5.6.1. 数据库基本上都不要求你像恢复传统数据库时那样做恢复，你只需要执行一些简单的命令，根据数据库里某个已有的replica创建一个新的replica即可

5.7. 云端快照

• 5.7.1. 如果数据库运行于云平台中，那你可以给数据库所在的任何一个盘（也就是“卷”​）​，频繁地制作快照

5.8. 可能要在执行完恢复之后确保此部分数据与其他数据一致

• 5.8.1. 具体的时长取决于此部分数据跟最新版的数据之间有多大差距，还取决于集群的规模及运作效率

5.9. 数据库的恢复工作可能会受具体故障原因的影响而变得相当复杂

• 5.9.1. 平时应该在云平台上反复演练与各种故障相对应的恢复计划，这样才能熟悉这些步骤

  • 5.9.1.1. 云不是万能的，发生在传统平台里的故障，同样有可能发生在云平台

• 5.9.2. 不要等到数据库真正出现问题时，才开始考虑如何全面恢复数据