银行重要交易系统信创分布式数据库备份系统实施策略如何设计？

【摘要】随着应用系统信创改造升级，信创分布式数据库在银行重要业务系统中逐渐得到推广，其备份系统建设也成为重要议题。本文结合分布式数据库备份的实际应用实践，首先分析了数据库备份恢复的要素，包括数据库备份内容和恢复场景，以及备份恢复策略。接着探讨了信创分布式数据库备份系统建设的难点，如生态不成熟、备份/恢复能力不足、备份运维不灵活等。针对这些难点，本文提出了信创分布式数据库备份系统的实施策略，包括二段式备份方式先行、备份存储信创先行等，并对比了不同备份存储介质技术路线的优缺点。此外，文中还提出了多中心数据备份架构的设想，以满足跨站点的备份恢复需求。最后，总结了信创备份的实施步骤，包括备份环境准备和系统对接、备份功能验证与优化、应用试点和推广等。分布式数据库的信创备份将是一个持续优化改进的过程，需要兼具数据库自身备份恢复的能力和信创备份管理平台的功能，为应用系统的可靠性和数据的完整性提供有力的支撑。

【作者】大唐小少，某股份制商业银行数据中心DBA，十多年核心业务系统数据库运维经验，参与完成分布式银行核心和信用卡核心系统项目投产上线，目前主要负责核心系统分布式数据库运维体系建设。对国产数据库、分布式和容器化相关技术领域感兴趣。

随着应用系统信创改造升级的深入，信创分布式数据库在银行重要业务系统也逐步推广使用，信创分布式数据库备份系统的建设也提上日程。这其中，如何满足信创数据库的备份恢复的功能需求和兼容性适配，在金融行业面临着新的挑战。本文简要阐述数据库备份恢复的要素、信创分布式数据库备份建设面临的难点，以及信创分布式数据库备份的选型及实施策略思考。

1、银行重要系统数据库备份要素分析

1.1 数据库备份恢复内容

1）数据库备份内容

数据库备份包括数据文件、数据库日志、元数据、全局的事务列表和Sequence数据、数据库组件运行日志和审计日志及性能日志等。

• 数据库文件：数据库表文件通过数据库的备份工具统一生成备份文件或者按照库及表生成单独的文件；

• 数据库日志：数据库事务日志、归档日志或者binlog日志；

• 数据库元数据：数据库集群的元数据信息，包括表结构定义、视图和存储过程定义、用户密码等信息；

• 全局事务列表：分布式架构下全局的事务列表信息

• 全局Sequence数据：分布式架构下全局的Sequence数据

• 数据库运行日志：数据库组件的运行日志，用于问题的排查和分析；

• 数据库审计日志：数据库DDL和DCL相关的审计日志，用于事后审计；

• 数据库性能日志：数据库运行慢日志、锁冲突日志等性能数据，用于性能分析和排查。

其它数据如配置文件、服务器参数文件等按需进行备份。

2）数据库恢复场景

• PITR数据恢复：利用全量的数据库备份文件和数据库日志，恢复数据到指定时间点；

• 异机数据恢复：将生产集群的数据库备份数据恢复到其它环境用于性能测试、应用版本验证等场景；

• 问题分析排查：通常恢复数据库日志用于事务具体执行操作或者审计操作日志分析应用的DDL操作行为。

1.2 数据库备份恢复策略

数据库备份的目的有几种：首先是保证对于一些没有容灾高可用的系统，通过备份数据达到系统恢复的目的；另外是满足监管对信息系统的安全策略、金融监管架构的审查需求还有业务取数需求。基于以上背景制定数据库备份恢复策略，包括备份的类型、备份的周期、备份介质和保留周期以及恢复频率和恢复场景。

• 备份的类型：分为全量备份和增量备份，全量备份是对整个数据库进行备份、增量备份是仅备份上一次备份以来发生变化的数据；

• 备份方式：分为定时备份和实时备份，定时备份是定义好备份策略后由备份软件自动发起备份任务、实时备份是手动发起的实时备份任务；

• 备份周期：分为日备份和月备份，日备份每天定时备份1次或多次、月备份则是每月备份1次。不同的备份周期对应的保留周期也不同，比如日备份保留30天，月备份长期保留，根据恢复场景需求制定不同的保留周期；

• 数据恢复的频率和恢复场景：根据不同的恢复场景制定恢复频率，比如生产故障恢复数据、月度版本验证的数据恢复请求、监管机构的数据审查等。

以上备份数据的保留周期根据金融监管的相关规定设定，比如核心业务系统的数据保存时间不少于3年、涉及到金融机构客户资料的保存期限不少于5年，尤其是涉及到一些监管审计核查、反洗钱等排查数据时，需要保证数据可恢复。

2、信创分布式数据库备份系统建设难点

2.1 生态不成熟

一方面信创数据库可能无物理备份接口，需要数据库厂商完善功能，和备份软件厂商做对接和适配开发；另一方面国产备份软件自身的备份功能可能不完善，如运维功能点不完善、备份和恢复的自动化方面还存在不足等。

2.2 备份/恢复能力不足

国产备份软件在数据的重删、压缩等方面相较国外软件还存在一定的差距，备份/恢复性能有所下降，对备份网络的带宽要求更高，且需增加备份存储的容量。

2.3 备份运维不灵活、人工依赖程度高

3、信创分布式数据库备份系统实施策略

针对以上难点，我们将如何应对呢？核心宗旨是以数据安全为中心，首先要保证数据能用、降低可用性风险，在系统出现故障时能够通过备份数据及时的恢复系统和业务。

3.1 数据库备份技术方案

数据库备份在实现上分为物理备份和逻辑备份：物理备份指的是直接备份数据库的物理文件如数据文件、日志文件等；逻辑备份是指备份数据库的逻辑对象，比如通过数据库命令或工具导出表数据或表结构信息等。在考虑备份软件时候主要是物理备份实现，当前在数据库备份技术方案的选择上，主要有以下几种：

1）数据库工具完成备份到本地或NAS文件，再由集中备份设备进行统一备份管理；

2）数据库备份工具备份数据到远端或云端的存储设备，如COS或OBS，再由集中备份设备进行统一备份管理；

3）第三方备份软件直接调用数据库备份接口备份数据库到专业备份存储进行管理。

上述备份方案中，首先需要满足备份恢复的时效性要求，网络复制带宽资源能否保证；其次是备份过程中的影响，是否支持备库备份、备份过程中对于备机回放和DDL的影响；最后是恢复的一致性要求，满足PITR的一致点恢复。

基于实际需求和客观生态环境分析，针对信创分布式数据库备份系统建设有以下两点实施策略：

3.1.1 二段式备份方式先行

由于现阶段部分信创数据库没有备份的物理接口，优先通过数据库自身备份命令将数据备份成文件，再利用备份软件将文件备份到集中备份设备，暂时降低对备份软件成熟度的依赖，等未来生态成熟起来了再进行直接备份。对于一部分信创数据库有备份接口的场景，则通过信创备份软件进行试点使用。

3.1.2 备份存储信创先行

将备份系统的软件和硬件解耦。信创备份软件层的生态成熟还需要时间、无法完全独立承载生产中心的备份任务，因此传统备份软件在一段时间内保持使用会是客观事实。信创备份存储相对成熟性和稳定性较高，先在备份存储介质层使用信创产品比如华为OceanProtect专业备份存储，把备份数据统一起来。同时，用好硬件层的压缩和消重能力，一方面可以减少网络带宽占用、另一方面可以缩短备份时间和降低备份空间。

3.1.3 两种方案对比

如下是两类备份存储介质技术路线的对比：

3.2 多中心数据备份架构

在未来，通过备份存储能力进一步实现多中心备份，满足跨站点的备份恢复需求：比如同城站点备机故障需要恢复，直接从本地机房的备份数据中恢复数据，减少了备机修复的时间；又比如灾备站点孤岛演练后的数据初始化恢复等。因此，结合重要系统数据库的高可用部署架构制定数据库多中心备份的架构，并且支持站点级别的备份恢复，同城或灾备站点的数据库节点故障时，通过本地站点的备份数据进行实例恢复。

4.小结

基于信创数据库备份选型标准和测试验证后，选择满足备份恢复场景和需求的产品，然后进行信创备份的实施。

1）备份环境准备和系统对接

信创备份软件和备份存储选型确定后，首先在测试环境准备备份软件和存储设备，并且选择部分数据库进行备份功能的对接验证。

• 硬件资源准备：准备备份测试需要的备份服务器、备份存储设备，以满足测试所需要的软硬件资源。

• 部署备份环境：在信创环境部署备份软件并进行配置和优化，准备功能性测试和性能测试验证。

2）备份功能验证与优化

根据备份恢复的功能需求拟定验证案例，结合实际测试验证的情况进行优化。

• 选定信创操作系统和信创数据库进行兼容性适配验证，验证不同的数据库备份和恢复场景下的功能和效率情况、备份数据压缩比，并进行针对性的配置及接口调优；

• 备份管理平台的功能验证，包括备份恢复任务的管理、监控、任务报表功能、审计等；

• 备份数据有效性验证，包括自动化的异机恢复验证，以验证检查备份数据的有效性。

3）应用试点和推广

测试验证充分后将选择部分应用和数据库进行试点推广，结合试点的效果进行全面的推广使用，逐步替换现有的备份软件。

欢迎点击文末阅读原文到社区阅读和讨论交流

觉得本文有用，请转发或点击在看，让更多同行看到