一、产品概述

数据库备份这款产品的英文名称为Database Backup，简称DBS，它是为数据库提供连续数据保护、低成本的备份服务。正如下图中右侧的DBS整体架构图所示，大家可以看到用户的数据库无论是在企业的数据中心、其他云厂商、还是公网上，都可以通过阿里云DBS备份到阿里云上的OSS对象存储中；如果用户的数据库已经上云了，比放在使用了阿里云RDS或者在ECS上自建了数据库，也可以借助阿里云的VPC或者经典网络，通过DBS也可以备份到用户的OSS上面。总而言之，阿里云DBS可以云上、云下或者其他云环境中提供强有力的保护。在功能上面，大家可以看到数据库备份提供了数据备份和操作恢复等整体的解决方案，实现了实时的增量备份，并且能够实现秒级数据恢复的能力。

大家可以体会到阿里云DBS的一些比较显著的特点，一个是秒级RPO，当进行恢复的时候可以选择任意的时间点进行，除此之外阿里云DBS对接对象存储的整体方案的成本也很低，并且阿里云DBS还能够支持多种环境。

二、产品优势

接下来为大家分享阿里云DBS数据库备份产品的优势。其实，阿里云DBS数据库备份产品的优势主要有以下五个：灵活易用，无学习门槛；高性能，适应不同规模要求；低成本，降低整体TCO；零风险，海量用户验证；多环境，覆盖阿里云场景。

优势1：灵活易用，无学习门槛

对于阿里云DBS这款产品而言，用户从购买到配置再到运行，基本上仅用5分钟的时间就可以完成。正如下图所示的就是DBS的整体使用过程。

首先，用户需要购买一个DBS的实例，之后需要配置一下自己的备份源，所谓备份源也就是用户想要通过DBS来备份哪个数据库，只要将数据库的连接串以及账号密码输入进去，也就完成了备份源的配置。

第二步，客户需要配置整个备份的目标，也就相当于要将数据库通过DBS备份到OSS上去。

第三步，用户需要配置数据库所需要备份的是整个实例还是单个数据库，备份的是单张表还是多张表。对于整个细粒度的备份，DBS都可以支持用户进行自由选择。

第四部分，用户可以设置备份的时间，因为DBS会提供全量备份和增量备份两种功能，只要用户开启了增量备份之后，系统就会实时地进行备份；而全量备份可以设置一周七天每天都备份或者每周只备份一次，备份的频率和时间都可以根据用户的需求灵活地进行设置。一般而言，数据备份往往会选择在业务的低峰期，比如凌晨两点钟至凌晨五点钟。

第五步就是在备份启动之后，将备份的数据存放到用户的OSS上，那么用户这些备份的数据需要存放多久，什么时候进行清理以及什么时候进行转存，阿里云DBS都提供了全局的规则设置。

当用户对于这些规则进行设置之后，后面的相关操作都会由DBS自动完成。在整个备份和恢复上面，阿里云DBS都提供了一个统一的Web界面，那么这样一来，用户无论是做数据备份还是数据恢复就不用来回切换工作界面了。这也就是DBS的第一个优势，它可以让用户更加灵活易用，用户只需要进行简单的配置就可以运行起来，因此学习成本比较低。

优势2：高性能，适应不同规模要求

当用户在第一步配置完备份计划之后，整个备份就开始处于运行状态中了。阿里云DBS提供了全量备份和增量备份两种备份计划如下图左侧所示，在全量备份中，DBS采用了无Agent的方式，也就是用户只需要提供IP、域名、账号和密码配置一下就可以了。在整个全量的备份过程中，DBS提供了无锁的备份，其含义相当于在备份的过程中不会影响到用户数据库上面线上的业务查询，因为大家都知道数据库除了备份之外还需要承载一些在线的业务的查询，而DBS在整个备份过程中不会影响到线上查询业务。此外，阿里云DBS还提供了并发的备份，因为当数据库的数据量比较大的时候，并发地进行备份可以大大地提升备份的速度。而在这个过程中包含了大量的创新点，比如阿里云DBS会探测数据库的繁忙程度，并且会调节全量备份在拉取数据的时候分片的大小、每次要拉取的数据量，以及并发的线程数等。

上面讲解了全量备份，接下来为大家分享增量备份。当DBS做增量备份的时候，它会从数据库内存中实时地捕获日志，每当产生一条日志就会去捕获这条日志并被分到用户的OSS上面，这样就可以实现数据的实时增量备份，也会让用户的RPO能够达到秒级甚至更低。

当有了备份之后，其实用户还需要做恢复操作。对于数据恢复而言，阿里云DBS提供了几个有价值的功能。首先，阿里云DBS能够支持单表的恢复，当进行备份的时候一般会选择整个实例或者单个数据库，但是当进行备份的时候，一般情况下其实并不需要将整个实例的数据全部恢复出来，很有可能对于500G的数据而言，想要恢复的只有里面的一张表几百M或者一个G的数据而已，而阿里云DBS恰恰就提供了表级别数据或者单表的数据恢复功能，用户需要哪张表的数据，DBS就帮助用户恢复哪一张，这个功能点在用户数据出现问题需要紧急恢复的时候，可以大大地降低用户恢复数据库故障的所需时间。而数据库恢复过程如果平时没有经过演练，通过脚本等方式临时抱佛脚会遇到各种各样的问题，DBS提供了这种Web界面，并且提供了引导式操作，这样一来从选择恢复的时间到选择恢复的对象在Web界面上都有明确的引导，可以帮助用户一步一步地进行恢复。DBS作为SaaS级别的云产品，它天生就支持弹性扩展。除此之外，阿里云DBS目前还提供了多种实例规格，可以支撑企业在不同阶段对于性能的要求。上图就主要介绍了DBS在高性能上面能够适应不同规模企业的要求。

优势3：低成本，降低整体TCO

在没有DBS之前，用户基本上会采用自建的数据库备份系统，一般情况下，用户可以采用脚本、数据库开源工具以及NAS和磁带等构成的自建备份系统。脚本以及开源工具等都是免费的，但是企业往往却需要投入一定的人力成本对数据库备份系统进行开发、维护以及后续升级，之后还需要采购NAS以及磁带、磁盘等存储设备。因此，企业不可避免地需要一次性地投入大量的资产，而相比而言，如果用户使用了阿里云DBS，就可以实现按量付费，用户可以先购买一个DBS实例，这样也是比较划算的，用户可以先做一些测试、试用和调研，然后根据所需要备份的数据规模不断地选择增加投入，因此使用阿里云DBS在成本上具有较大的优势。包括用户在实际进行数据备份存储的时候，阿里云对象存储OSS也为用户提供了非常好的不同性价比的备份类型，包括标准存储、低频访问以及归档存储等，而这些在DBS上面可以帮助用户进行自动的存储分级，用户可以通过设置相应的规则确定DBS在哪一天需要将标准存储转移到归档存储上面，因此阿里云DBS非常适合用户需要对于长期存储数据进行归档的场景。而且随着用户投入的使用量的不断增多，用户使用的单价也是越来越低的。

如上图所示，这里就是采用云数据库备份DBS的解决方案和传统自建数据库备份方案的对比情况。在正常情况下，用户自建的数据库备份系统需要脚本、开源工具以及NAS等，此外还需要磁带等存储设备，除了对于这些存储硬件的投入之外，还有一些隐藏的成本，而随着备份以及归档的时间增多，磁带库的硬件成本、管理成本以及多份数据的冗余成本等很多隐藏成本会逐渐加大备份系统的整体成本，因此推荐用户尝试使用云数据库备份解决方案。因此，阿里云数据库备份DBS的第三点优势就是可以帮助用户整体地降低在数据库备份的TCO。

优势4：零风险，海量用户验证

其实大家能够看到，在整个数据库备份以及恢复过程之中，无论是在阿里云上面还是用户自建的机房中，用户的数据库都会有VPC、安全组策略或者本地网络上面的隔离策略。在备份的过程中，数据一旦离开了数据库，DBS就会提供SSL这种传输的加密，将传输的数据拉取到DBS这边。在控制台上面大家就能看到，对于DBS本身而言，可以支持主子账号，并且对于任务状态以及性能等都有云监控，而DBS本身也有HA高可用这种保障。而DBS接下来会通过HTTPS将数据存到用户的OSS上面，这个步骤的数据安全性也是没有任何问题的。而存储到对象存储OSS上面的数据也是通过了AES256加密的，而且这些备份数据也做到了用户的隔离，不同的用户只能看到自己的数据。当整个数据备份过程结束之后，用户可以随时地验证备份的有效性以及备份的正确性，并且可以随时进行恢复验证。因此，阿里云数据库备份DBS的第四大优势就是零风险，而且已经经历了海量的用户充分的验证，借助于阿里云DBS，用户可以快速地发现问题并及时地进行修复，这样的迭代速度是传统自建数据库存储备份方式根本没有办法比拟的。

优势5：多环境，覆盖阿里云场景

阿里云数据库备份DBS的第五个优势就在于对多种环境的支持上面。在下图中大家可以看到，DBS除了能够支持整个阿里云上面的RDS、ECS自建库等，其实还支持在用户自己本地的IDC数据中心上面建立的数据库。这时候就会出现一种场景就是用户希望先将自己本地的数据库备份到云上面，此时用户可以通过DBS将数据库备份到自己在阿里云上的OSS上面，这时候就实现了整个上云的备份。对于上云备份而言，用户可以选择公网，通过阿里云上面的高速通道、专线以及VPN网关将本地的数据库备份到阿里云上面。第二类场景就是如果用户在其他的云上面也有数据库，用户可能并不想将全部的数据都放在一个“篮子”里面，因此在阿里云上面也提供了跨云的灾备方案，用户可以将其他云上的数据库通过阿里云的DBS备份到阿里云OSS上面。而在下图的上半部分，大家可以看到如果用户的数据库已经在阿里云的RDS或者ECS自建库上面了，也可以通过DBS备份到OSS上面，这样一来其实就实现了阿里云的云中数据备份。

而在企业中，往往会有一些行业合规以及数据安全性的要求，因此可能需要数据备份不仅仅只有一份，而会需要在不同的地方存在多份数据备份。针对这样的需求，阿里云DBS也提供了异地的灾备。举个例子，如果用户的数据库在杭州，那么就可以将用户的数据库备份到杭州的OSS，同时将这份备份数据放到用户位于深圳的以及北京的OSS上面，其实这样就帮助用户解决了异地灾备的诉求。阿里云OSS上面还提供了归档类型，这非常适合于用户将出于审计合规的因素需要将一些数据必须存放2到3年甚至是5年的要求，而通过DBS将数据存放到归档OSS上面则可以实现用户的数据归档需求。

三、产品架构

阿里云DBS产品架构

以上就为大家介绍了阿里云DBS的五个优势，接下来进入本文的第三部分，为大家介绍DBS整个产品的架构。如下图所示的阿里云DBS产品的架构图，DBS主要面向的客户包括数据库管理员也就是DBA、IT管理人员、架构师以及研发人员。DBS从功能上面提供了全量的备份，进一步细化则会包括备份预检查、结构备份、数据备份以及备份校验等子模块。此外，DBS还提供了增量备份，在备份结束之后还提供了数据的恢复功能。在下图的右侧展示了服务的场景，阿里云DBS能够支持ECS自建数据库、公网数据库、混合云专线部署、阿里云RDS、专有云以及内网数据库等。目前，DBS在数据源支持上面而言，可以支持四种数据源：MySQL、SQL Server、MongoDB以及Oracle，未来也会进一步扩展。

阿里云DBS的备份流程

接下来为大家介绍阿里云DBS的备份流程。首先，一定要有一个源数据库，其实也就是用户需要备份的数据库，当启动备份的时候，DBS会首先做一个预检查，在这里就需要检查用户的数据库是否符合备份的条件，比如数据库的类型是否合适、版本是否支持、binlog是否已经开启等，这些条件都需要提前进行检查，而不是在备份时出现问题后再报错。一旦预检查通过之后，阿里云DBS就会启动结构的备份，此时会将数据库上面的数据库对象，比如表结构、存储过程以及索引等都帮助用户备份下来放到OSS上面，之后DBS就会启动全量的备份，此时就会通过SQL查询并发地读取全量的数据，而也会在读取速度和数据库的影响上面找到一个平衡点，也就是在不影响到线上业务查询请求的前提之下，尽快地完成数据备份。在全量备份的过程中，也会同时启动增量的备份去实时地从数据内存中捕获日志并且放到用户的OSS上面。那么预检查、结构备份、全量备份以及增量备份就构成了整个DBS备份的流程。

阿里云DBS的恢复流程

当数据备份成功之后，如果用户想要做数据恢复的时候，阿里云DBS所提供的恢复流程是什么样的呢？因为数据是备份到OSS存储上面的，那么当进行恢复的时候，用户需要提供一个数据库来做恢复，那么这个时候阿里云DBS首先会检查用户选择时间的数据是否存在，还要检查所需要恢复数据库的版本等问题是否匹配。而在自建的系统上面经常会遇到所选择的备份数据不存在的问题，因为当数据备份上去之后，经过了半年或者一年的时间，很有可能在用户不知道的情况下数据就已经被删除掉了，而当真正进行数据恢复的时候才会发现这个问题，而这往往会造成很大的风险，阿里云DBS将会提前做好预检查。而当预检查恢复之后就需要启动结构恢复的第二部分，DBS会从OSS上面将之前备份好的表结构恢复过来，这样当第二步完成之后，在恢复的数据库上面就已经有了表结构。之后就会进行第三步，从OSS上面读取全量的数据并进行恢复。第四步还是进行结构的恢复，它会将相关的索引、外键这些数据库的对象恢复上来。紧接着的最后一步就是根据用户选择的时间点进行日志解析，当用户选择的恢复时间点是全量备份的时间点，就不需要增量恢复了。而大多数情况下，用户所选择的时间点都是在全量备份之间的某个时间点，因为DBS支持任意时间点的数据恢复。在全量恢复之后，DBS会启动增量日志的恢复，恢复到用户指定的时间点，将增量的日志应用到这些数据上面。当增量日志恢复完成之后，大家就可以看到恢复的数据库上面就已经有了用户想要的数据了。

阿里云DBS秒级RPO实现原理

所谓RPO的意思通俗理解来说其实就是当数据库发生了故障将会允许丢失多久的数据。这对于用户而言也是很好判断的，当然是希望尽量不丢失数据，或者让丢失的数据尽量少。举个例子而言，如果选择一周做一次全量备份，当数据库出现问题的时候丢失数据在极限情况下可能就是一周的业务数据；而如果选择一天做一次全量备份，那么RPO就是一天，也就是当数据库出现故障或者问题的时候，最多只能丢失一天的业务数据。如果用户选择了阿里云DBS并开启了增量备份，那么就能实现秒级RPO，也就是说当用户数据库出现故障的时候，可以帮助其将数据恢复到任意的时间点，可以精确到秒级别。

如上图所示，如果用户在1点钟做了操作，向数据库中插入了一条数据“a=1”，当在1点半的时候用户又做了update“a=2”，而在2点钟又update“a=3”，在2点半又update“a=4”，在用户操作过程中，如果开启了DBS，那么增量会持续地备份和保护数据库。当我们想要将数据恢复到2点15分的时候，因为全量备份能够恢复到1点15分，然后应用binlog一直到2点15分，那么此时a的数据就能够恢复到2点15分了，这样也就实现了秒级RPO和任意时间点的数据恢复。