为了预防上述故障的发生，同时提升数据的高可用性，KingbaseES 提供了sys_rman物理备份恢复工具，该工具集成了WAL文件归档、PITR恢复等功能，实现了自动化定时备份以及灵活多样化的恢复，为用户提供了安全便捷的数据备份恢复解决方案。
sys_rman工具的介绍与部署请参考《KingbaseES物理备份恢复工具手册》，这里不再赘述。
目录
3.1. sys_rman备份方式
¶
下表对sys_rman支持的备份类型做了一个简要说明。
|
备份类型 |
优点 |
缺点 |
适应场景 |
|---|---|---|---|
|
全量备份 |
针对所有需要的文件进行的一次备份。当还原时，不需要额外的协助，通过此全量备份即可恢复数据库到备份时的状态。 |
占用的存储空间大 |
1. 首次备份 2. 长周期的定时备份 3. 执行恢复操作后，恢复后的数据符合预期时，建议做一次全量备份 |
|
差异备份 |
选择性备份，仅选择上一次全量备份后，发生了变化的文件，相比于全量备份节省了一定的存储空间。 |
还原时，需要本次差异备份及其依赖的全量备份 |
短周期的定时备份 |
|
增量备份 |
选择性备份，仅选择上一次全量或差异或增量备份后，发生了变化的文件，更加地节省存储空间。 |
还原时，需要本次增量备份以及前次备份、再前次备份、直到串行依赖到一次全量备份 |
短周期的定时备份 |
|
块增量备份 |
选择性备份，在上一次全量或差异或增量备份后时间线未发生改变的情况下，仅选择上一次全量或差异或增量备份后，发生了变化的表文件的数据块和其他发生了变化的非表文件，比其他备份类型更加地节省存储空间。 |
还原时，需要本次块增量备份以及前次备份、再前次备份、直到串行依赖到一次全量备份；并且需要依赖ktrack插件。 |
适用于一些大表文件仅更新了几条记录的情况 |
3.2. 数据丢失恢复策略
¶
数据库恢复的原理简单来说，是首先通过拷贝物理备份集建立起一个基础的数据库data目录全貌，然后将要恢复到的目标点写入配置文件，这两步使用 sys_rman restore 命令即可完成，最后启动数据库进入恢复模式，借助归档的WAL文件恢复至目标点并暂停，需要人工确认恢复是否符合预期再执行后续操作。
若恢复符合预期，则执行
sys_wal_replay_resume()
将数据库由恢复模式转到正常运行模式，此时数据库运行在新的时间线上；若不符合预期，则需要停止数据库删掉data目录，重新确定恢复目标点再次恢复。
3.2.1. 恢复目标点的确定
¶
sys_rman恢复的第一个原则就是通过离目标点最近的备份集和WAL日志做恢复，这样可以减少WAL重做的数量，在一定程度上避免因WAL文件缺失导致的恢复后数据库无法正常启动的问题。离目标点最近的备份集既可以指定该备份集加时间做恢复，也可以只指定时间做恢复，需要注意的是该时间必须大于备份集的结束时刻，否则会使用上一个备份集做恢复。
在下图中，由于缺少一个基础的备份集支撑，因而无法恢复到 位置1 ；而 位置2 、 位置3 、 位置4 都是可用的恢复目的点。
以下图所示的情况，介绍指定时间点恢复与指定备份集恢复时， sys_rman restore 恢复命令的差异与注意事项：
|
恢复目标 |
指定时间点恢复使用的备份集 |
指定备份集恢复 |
特殊说明 |
|---|---|---|---|
|
位置1 |
全量备份1 |
全量备份1 + 位置1的时刻 |
若只指定备份集恢复，未提供恢复的结束点，sys_rman会自动添加该备份集结束时刻作为恢复的结束点 |
|
位置2 |
增量备份1 |
全量备份1 + 位置2的时刻 或者 增量备份1 + 位置2的时刻 |
虽然两种方式都可以完成恢复任务，但利用最新的备份集做恢复是最优选择，这样可以减少WAL重做的数量，在一定程度上避免因WAL文件缺失导致的恢复后数据库无法正常启动的问题。 |
|
位置3 |
增量备份1 |
全量备份1 + 位置3的时刻 或者 增量备份1 + 位置3的时刻 或者 全量备份2 + 位置3的时刻 |
指定时间点恢复需要注意的是该时间必须大于备份集的结束时刻，否则会使用上一个备份集做恢复。 |
|
位置4 |
差异备份1 |
全量备份1 + 位置4的时刻 或者 增量备份1 + 位置4的时刻 或者 全量备份2 + 位置4的时刻 或者 差异备份1 + 位置4的时刻 |
优先使用最近的差异备份1做恢复，若恢复失败，可以尝试使用次最近的备份集（全量备份2）做恢复。 指定时间点恢复只会选择差异备份1做恢复，若因差异备份1文件损坏导致的恢复失败，可以尝试指定备份集恢复。 |
3.2.2. 恢复后是否提升节点
¶
恢复结束后，如果只是用来测试是否恢复到当前数据，则无须执行
sys_wal_replay_resume()
，因为执行后时间线会切换，多条时间线的出现会对后续的还原造成干扰；或者恢复后的数据不符合预期，也无须执行
sys_wal_replay_resume()
提升节点。
比如下图所示场景，第一次在 位置1 处执行了恢复操作，启动数据库后发现数据不符合预期，因而未执行
sys_wal_replay_resume()
, 时间线未切换，将该库关闭后删除data目录；重新到 位置2 处执行恢复，恢复后发现数据符合预期，执行
sys_wal_replay_resume()
，该库正式作为生产库启用，时间线切换到2.
下面所示的场景，第一次在 位置1 执行恢复，在拉起数据库后执行了
sys_wal_replay_resume()
操作，时间线切换到了 2；之后若想恢复到时间线1上的增量备份2之后的 位置2 ，需添加时间线参数
--target-timeline=1
，否则默认会恢复到最新的时间线2上的 位置3 。
3.2.3. 多时间线恢复点的确定
¶
时间线发生过切换后，执行恢复时需要确定恢复目标点在哪条时间线上，默认是使用最新的时间线做恢复的，若想恢复到旧时间线上的某个位置，需要添加时间线参数避免PITR恢复时发生歧义导致数据错乱。
3.2.4. 目标明确的恢复
¶
目标明确的恢复只需要考虑时间线因素即可，默认使用最新的时间线做恢复，若想恢复到旧时间线上的某个位置请添加时间线参数限制。
下图所示情况，当需要恢复到 位置1 时，可直接使用时间点恢复或指定备份集恢复：
/opt/Kingbase/ES/V8/Server/bin/sys_rman --config /home/kingbase/kbbr_repo/sys_rman.conf --stanza=kingbase restore --type=time --target='位置1的时刻' /opt/Kingbase/ES/V8/Server/bin/sys_rman --config /home/kingbase/kbbr_repo/sys_rman.conf --stanza=kingbase restore -set='增量备份1' --type=time --target='位置1的时刻'
下图所示情况，数据库在 位置1 时发生过恢复，当前数据库运行在时间线2上，此时需要恢复到时间线1上的 位置2 ，需要在恢复时指定时间线：
/opt/Kingbase/ES/V8/Server/bin/sys_rman --config /home/kingbase/kbbr_repo/sys_rman.conf --stanza=kingbase restore --type=time --target='位置2的时刻' --target-timeline=1 /opt/Kingbase/ES/V8/Server/bin/sys_rman --config /home/kingbase/kbbr_repo/sys_rman.conf --stanza=kingbase restore --type=time --target='位置2的时刻' --target-timeline=1 –set=’增量备份2’
3.2.5. 目标不明确的恢复
¶
目标不明确的恢复比较常见，适用于多次尝试寻找最终恢复点，需要操作的步骤较多，比如下面这个示例：
第一次在 位置1 处执行了恢复操作，启动数据库后发现数据不符合预期，因而未执行
sys_wal_replay_resume()
时间线未切换，将该库关闭后删除data目录；重新到 位置2 处执行恢复，恢复后发现数据符合预期，执行
sys_wal_replay_resume()
，该库正式作为生产库启用，时间线切换到2.
/opt/Kingbase/ES/V8/Server/bin/sys_rman --config /home/kingbase/kbbr_repo/sys_rman.conf --stanza=kingbase restore --type=time --target='位置1的时刻' /opt/Kingbase/ES/V8/Server/bin/sys_rman --config /home/kingbase/kbbr_repo/sys_rman.conf --stanza=kingbase restore --type=time --target='位置2的时刻'