数据备份POC-(测试报告)

软件安全漏洞的检测和防范技术方法

第1章 漏洞概述与分类 ................................................................................................................. 4

1.1 漏洞的定义与危害 ........................................................................................................... 4

1.1.1 漏洞的定义 ................................................................................................................... 4

1.1.2 漏洞的危害 ................................................................................................................... 4

1.2 漏洞的分类与分级 ........................................................................................................... 5

1.2.1 漏洞的分类 ................................................................................................................... 5

1.2.2 漏洞的分级 ................................................................................................................... 5

交通银行同城双活

交通银行2006年完成数据大集中，在上海浦东张江建立数据中心，2007年将海外分行系统从香港迁移到张江数据中心，实现境内外一体化数据中心运行。为保障业务连续性，2007年在上海浦西漕河泾建立同城备份中心，2008年在武汉建立异地灾备中心，形成“两地三中心”的灾难备份体系。在灾备建设过程中，交行充分借鉴国内外先进技术和经验，开发了若干具有自主知识产权的关键技术，突破了IBM技术的限制，实现了大机和开放系统在光纤距离70公里的张江和漕河泾中心的同步运行。关键业务系统的联机交易可以在同城两个中心之间进行平滑的路由切换，使备份中心用于灾备的闲置资源得到充分利用，降低了IT投资成本，提高了生产系统的可用性和同城备份系统的灾难恢复等级。

一、技术背景

在大型机同城灾难备份的各种解决方案中，IBM的GDPS（跨地域的并行耦合体）是目前大型商业银行用得最多、也是灾备恢复级别最高的方案。GDPS支持单站点运行（SingleSite）和多站点运行（Multi-site）两种模式。

在GDPS Multi-site架构下，由于光纤的传输延迟，大型机系统联机交易的性能会随着物理距离的延长而急剧下降。IBM法国实验室的Benchmark测试表明，OLTP交易性能在两中心距离超过20公里后将急剧增长，当两中心的光纤距离达到80公里时，交易的平均响应时间将增长近20倍。因此，GDPS多站点模式要求两中心（光纤）距离不超过20公里。考虑到防范灾难的要求，金融机构同城双中心之间的距离大都在20公里以上，物理距离的限制大大制约了GDPS Multi-Site的应用范围。

商业银行的外围业务往往采用J2EE三层架构，即Web、APP和DB服务器架构。Web和APP服务器一般都支持分布式处理，容易实现服务器的多路部署和负载均衡。在DB服务器层，Oracle从9i开始就推出了RAC技术，支持ORACLE数据库服务器的集群，但是Oracle

浙江电信云平台

IBM Power 服务器和存储 PoC 场景与好处小结

目 录

1 POC01（分区创建及分区资源隔离测试） .............................................................................................. 2

2 POC02（分区操作的独立性及手动调整分区 CPU 资源测试） .......................................................... 2

3 POC03（分区对操作系统多个版本的兼容性测试） .............................................................................. 3

4 POC04（手动调整分区 I/O 资源测试） ................................................................................................. 3

5 POC05（分区资源扩展测试） .................................................................................................................. 3

6 POC06（分区最小颗粒度测试） .............................................................................................................. 4

7 POC07（多个微分区基于负载和权重自动调整 CPU 资源测试） ...................................................... 4

2018/5/15 WoquTech 产品-PRODUCT QBackup：一款面向业务的数据库CDP备份产品 作者｜孙朝阳·产品专家 QBackup数据库备份容灾云平台，是一款集合了CDP备份，历史数据秒极恢复，灾备保护等功能的一体化云平台。支持主流的Oracle、MySQL数据库，可同时对大量数据库做集中式备份和管理，并对备份进行持续校验以确保数据的可恢复性。此外，QBackup还可用于应用测试、预发布、性能优化、POC等诸多应用场景。 当前数据库备份的困境 DBA的日常备份工作可以简化为以下工作流： ⚫ 使用Rman，Mysqldump等工具将数据库定时备份成文件 ⚫ 待需要恢复时再把备份文件导入成数据库 ⚫ 最后提取所需要的数据 在这个过程中正常的数据文件会被转换为其他格式，因此这些备份文件不能立刻被使用，而需要再进行一次转换才可使用。 假设，刚刚发生了一起故障，某张表的数据被错误的覆盖掉了。 那么恢复的过程一般是这样的： 首先，DBA需要找到最近一次备份点。比如说，最近一次备份点是今天凌晨两点，那么，从今天凌晨两点到故障点这个时间段可能会存在部分数据丢失的风险。 接着，DBA需要准备相应的环境以供数据恢复。比如硬件设备，操作系统，数据库软件等等。由于这一阶段操作较为繁琐，所以需要花费一定的时间。 WOQUTECH 然后，DBA导入完整的备份数据。导入时间视数据量而定，一两百GB的数据库可能需要若干小时，如果是几十TB的数据库，则有可能需要好几天。 最后，将所需要的表导回到生产库。如果在恢复过程中出现备份损坏，坏块等情况，则需要寻找其他备份，按上述步骤重新恢复。 不难看出，该恢复方式存在以下几个问题： ⚫ 存在数据丢失的风险 ⚫ 恢复时间太长 ⚫ 操作复杂 因此，该恢复方式并不适合做为常规的数据恢复手段。 “通用”备份产品 由于现有备份手段并不适合常规操作，所以市面上也逐渐开始推出了面向操作系统、文件、邮件服务器、数据库等“通用”的数据备份产品。 注意，这里的“通用”是带引号的。大多数情况下“通用”是一个偏褒义的词汇，表明产品兼容性很好，适用范围很广。但在备份领域，“通用”一词应该更多的偏向贬义，原因是它不去理解业务，试图使用单一的备份技术适应所有的上层业务场景，并统一为“文件备份”。 它考虑的是如何把文件拷贝的更快，备份窗口缩小的更短，而不是考虑数据的可恢复性。 对于业务而言，拷贝速度等指标都不是重点，重点在于业务的受保护程度，具体到数据库，就是指一次事务提交后，多久才能被备份起来。假设每天执行一次备份任务，使用面向文件的备份产品就意味着备份要延迟高达二十几个小时。 面向业务的CDP备份 那么，面向业务的备份，会有什么不同呢？ 首先，在设计阶段，我们会考虑业务上对恢复数据的紧迫性，并以此为出发点进行备份产品的设计。 众所周知，在户外救援中有个说法叫“黄金72小时”，意思是在这个时间段内救援成功的可能性最高。对于业务来说，也是如此，距离故障时间越短，数据恢复率越高，对业务的影响和损失就越小。 QBackup是一款面向业务的数据库CDP备份产品，这款产品从设计初始就是基于业务中遇到的问题，来寻求最佳的解决方案。 如果遇到上文的故障场景，使用QBackup又能达到什么样的效果呢？ WOQUTECH 当故障发生后，假设上午10点05分，迅速打开页面，输入需要恢复的时间点10点04分59秒，点击确定就可以自动化创建出历史数据库。之后就可以将需要的数据导回到生产库，整个恢复过程仅仅需要几分钟就可成功完成。 这就是“专用”备份产品所能实现的效果，它从初始设计开始就是为了解决数据库备份场景的问题，因此它所具备的特性非常适合如下几个场景： 近线快速恢复 像类似Rman这样的备份手段，其本质上属于“冷备份”，应该用于长期存档之类的用途；日常工作中，我们经常遇到的情况，是在键盘敲下之后很快就意识到可能出现了误操作，因此我们更需要的是用于近线快速恢复的产品。 这样的产品应该具备两个特征：保留数据原格式，精度至少为分钟级。 因此Rman（备份为文件）以及Flashback（基于Flashback日志）都不满足要求，而QBackup不仅能够保留数据原格式，随时可用，精度也达到了秒级。 大库备份场景 以国泰君安证券为例，其需要备份几十TB的数据库，每次备份时间都需要很久，千兆网络下跑三四十个小时也是常有的事，空间消耗也很高。 QBackup初始备份后只需要传输增量数据，对主库的性能几乎没有影响，因此非常适合大库备份。 降低TCO成本 这是我们某个客户的原有环境，算是比较常见的，主库需要定时备份到文件服务器，同时每个主库还要有对应的DG数据库，以及导出备份文件到测试服务器。 可以看到，在原有环境中，同一份数据同时是存在于文件服务器、DG服务器、测试服务器，数据重复性很高，硬件、存储空间占用较多，数据的读写效率非常低。 那么换成QBackup之后会是什么样的效果呢？ WOQUTECH 首先，这些DG服务器都不再需要了，并且，因为测试数据库是基于虚拟化技术的，所以测试服务器也不再需要。 应用预发布 QBackup也非常适合于开发测试、应用预发布、数据库升级测试等等。得益于CDM技术，使用QBackup建立测试数据库的过程中，不存在数据拷贝，因此，无论多大体量的数据库，建立测试环境都只需3分钟即可。 基于沙箱创建的测试数据库，其新增、修改、删除的数据均保存在沙箱环境中，对原始数据没有任何影响。当测试数据库使用结束后一键删除，其改动的数据亦随之丢弃。 QBackup | 来自客户的认可最重要 ⚫ 浙江省某医院 该医院当时遇到的问题是：操作人员制作报表时错误的覆盖了生产环境数据，情况十分紧急。 当时客户刚刚购买QBackup 1个月左右，于是马上使用QBackup创建出历史数据库，并导回完整的数据至生产库，整个操作过程仅不到5分钟。 ⚫ 国泰君安 客户当时数据库体量大约30TB，日归档量约3TB，而客户之前一直使用的都是Rman备份方式，每次完整备份约需五十多个小时。使用QBackup备份之后，可以做到实时同步，对主库以及网络几乎无性能影响，并且可以快速恢复历史数据。 ⚫ 中邮人寿 保险行业升级测试较多，尤其是涉及调整系统时间等操作，导致不同的开发小组无法共用测试环境，DBA搭建测试数据库的工作变得更加繁重。 QBackup快速创建测试数据库的特性大大降低了DBA工作的枯燥性和重复性，由2人/天降低至3分 钟。 ⚫ 中原证券 对接客户现有的Oracle一体机，承担容灾的角色，全自动化操作有效降低了容灾演练、紧急切换过程中出现的手忙脚乱的问题。