保障业务连续性,企业灾备建设新思路

本文涉及的产品
对象存储 OSS,20GB 3个月
对象存储 OSS,内容安全 1000次 1年
数据安全中心,免费版
简介: 本次分享主题为“保障业务连续性,企业灾备建设新思路”,由阿里云专家李媛和胡航丽主讲。内容涵盖企业业务连续性与灾备建设的重要性、新产品及其界面特点、Regional ESID、云备份Call back up、跨账号备份等。重点介绍了数据灾备中心BDRC,其具备全面覆盖阿里云资源、可视化设计、简化运维等特点,帮助企业高效实现数据灾备及合规管理。同时,针对企业面临的灾备挑战,如勒索病毒攻击、数据误删等,提供了不可变备份、自动病毒检测等功能,确保数据安全性和业务连续性。最后,通过案例展示了如何通过云备份服务满足企业的高阶需求,降低运维成本并提高效率。

保障业务连续性,企业灾备建设新思路

 

内容介绍

一、企业业务连续性离不开灾备建设

二、新的产品以及每一个界面的特点和带来的价值

三、企业灾备和数据的业务连续性

四、Regional ESID

五、企业灾备建设面临的新挑战

六、云备份Call back up

七、跨账号备份

八、回顾

 

本次分享的主题是保障业务连续性,企业灾备建设新思路,由阿里云云存储高级产品专家李媛和阿里云智能集团高级产品专家胡航丽分享。

今天将带来保障业务连续性企业灾备建设新思路,以及阿里云存储的数据保护方案。通过多年来的实践观察,发现企业对灾备的需求始终在不断地变化与演进。为应对这些需求,我们也必须不断创新。因此,本次分享将主要围绕这些新需求所带来的新产品发布以及新增功能展开。

 

一、企业业务连续性离不开灾备建设

企业的业务连续性让我联想到了一座城市的日常运作,它之所以能够日日夜夜正常运转,离不开各种基础设施的保障,比如水电气等资源,以及防灾措施。就像今年频繁发生的台风,我们需要采取措施来抵御这些自然灾害。同样,企业的业务也需要一个完备的灾备系统来确保其连续性,除了建设基础的IT设施之外,这一点至关重要。

企业的业务可能面临多种威胁。首先是自然灾害,如地震、洪水、火灾、台风,以及近年来愈发猖獗的勒索病毒等。一旦感染勒索病毒,数据会被加密,黑客还会索要高额赎金。此外,数据误删也是一个问题,这既可能是运维的失误,也可能是恶意行为,历史上不乏此类事件。其次是合法合规问题,国家对数据安全极为重视,出台了许多通用或针对特殊行业(如金融、医院)的法规,明确要求企业必须确保数据的安全和可恢复性。

针对这些威胁,我将分享一些具体的数据。首先是灾害形势严峻,比如今年台风频发,摩羯之后紧接着是普拉桑等,给各地带来了房屋倒塌、机房进水等种种问题。自然资源部也提到,今年的洪涝灾害和风暴潮等海洋灾害频发。同时,我国地震局的专家预测,2024年的地震也可能更加频繁。

关于勒索病毒。全球知名的安全厂商NTT和Surface在报告中均指出,2023年勒索事件激增,增长了67%,赎金翻了五倍,平均达到200万美元。更重要的是,两者都指出,中小型企业也开始面临这一挑战。以前黑客可能更倾向于攻击大企业以获取更多赎金,但随着防范意识的增强,他们现在开始将目标转向中小型企业,即员工人数不到200人的企业。这说明勒索病毒和黑客的攻击范围正在不断扩大。

关于数据运维失误,近年来也屡有发生。例如,2017年河南某云主机商的数据被恶意删除;2018年思科的数据也遭遇了恶意删除;2020年某公司一天之内市值蒸发了超10亿元。在公共云厂商中,也发生过类似事件。2023年和2024年,全球多家公共云厂商因工程师运维失误导致客户数据丢失,进而影响了客户的业务和数据安全。

最后,国家确实出台了许多政策和规范,要求企业进行灾备建设。这包括通用的网络安全等级保护2.0(即等保2.0)、关键信息基础设施的安全保护条例以及个人信息保护法。此外,在2023年年底还发布了《数据中心业务连续性评价白皮书》。

接下来,通过两个金融行业的案例来进行讲解,一个是银行业,一个是证券业。在这些行业中,都有明确的规定要求企业对客户数据进行备份。有些规定甚至非常细致,比如要求兆天级备份,并规定除了本地备份外,还需要进行异地备份。

在云栖大会的主题中,可以感受到AI的浪潮汹涌澎湃。而在AI的发展中,数据扮演着至关重要的角色。比如,AI公司需要收集海量的数据集、编写核心的训练脚本以及生成关键的核心和模型文件。这些数据对于AI公司的运行至关重要,因此需要对它们进行保护。企业需要全面了解在云上存储的资源的保护情况。今天,我为大家带来了一个全新发布的企业灾备管理服务——数据灾备中心BDRC。BDRC已经正式上线了阿里云的官网和控制台。

关于数据灾备中心BDRC,它是公共云首发的企业灾备管理服务。它主要具备以下几方面的功能:一是保护客户数据;二是提供统一的策略中心进行集中化的保护管理;三是帮助客户生成定制化的报表,以支持客户的汇报等会议需求。该产品的愿景是帮助客户简单高效地实现数据灾备及合规管理。它有三个显著特点:第一个是全面性,它覆盖了存储在阿里云上的所有资源,包括SAS化的备份方案和NAS化的备份方案;第二个是直观性,我们主打可视化设计,通过分数星级和3D视图展示客户在阿里云全域资源的保护情况;第三个是省运维特性,策略中心采用了引导式的流程设计,降低了客户在配置灾备方案时的学习成本。

为了更好地理解数据灾备中心是什么样的产品,讲解一下产品架构图。针对ECS、NAS、OSS、Tablestore等阿里云云存储常用的资源,有一系列的云资源保护方式可供选择,包括云备份、云盘快照、OSS跨区域复制、NAS回收站和OSS版本控制等。如果是阿里云存储的老用户,对这些保护手段应该已经非常熟悉了。然而,大家可能会遇到一些困惑:我的资源是否已经采取了保护措施?这些资源到底采用了哪一种保护方式?尤其是当客户的账号下有多个部门共同使用时,这种困惑更为常见。在数据灾备中心中,有一个引擎层会整体编排云资源和云资源的保护方式,并最终以可视化的方式呈现给大家。这包括资源的视图、状态的视图、风险的评分、资策略的配置以及报表视图等。

数据灾备的运维人员也可以通过BDRC的开放API和控制台来下发保护策略,调用所有的云资源保护方式来保护相应的云资源。因此,这个产品主要面向三个场景:一是云上资源的灾备;二是业务分层保护;三是灾备的合法合规。

 

二、新的产品以及每一个界面的特点和带来的价值

根据控制台提供的橄榄叶资源保护概览,它通过评分星级和颜色进行了全方位展示,涵盖了100分、95分、80分等多个等级。这些评分实际上是对账号下全域资源的加权评估,具体考量了你是否拥有保护伞措施,这些保护措施是仅局限于本地还是也包括异地。

那么,这些评分规则是如何制定的呢?对于熟悉或关注数据保护的同仁来说,可能都知道一个著名的321备份黄金法则。这一法则意味着,你需要有三份数据副本,包括一个原件和两个备份;同时,这两份备份应存储在两种不同的介质上,或使用两种不同的数据保护手段;此外,还需要有一份异地备份。基于321备份黄金法则,我们针对客户的多样化数据,采用不同的数据保护手段来进行评分。在概览视图上,不同颜色的条形图还能帮助客户清晰地了解资源的分布情况。

例如,你可以直观地看到10台ECS中有多少处于红色区域,即急需提高分数,同时也有哪些资源是安全的。这样,你就能一目了然地掌握全域资源的安全状况。此外,也欢迎大家前往控制台查看更多细节。控制台会展示风险最高的前十个资源,帮助你快速定位需要提升数据保护的资源。

此外,还提供了全域3D视图。阿里云资源是按地域分布的。在以往,查看不同地域的资源需要不断切换。但在BDRC数据灾备中心,我们打破了地域壁垒,让你能够直观、全面地查看所有地域的资源情况。其中,绿色表示安全,红色、橙色、黄色则分别代表不同程度的风险。这有助于运维人员迅速了解数据保护的整体状况。同时,每个点都是可点击的,点击后会跳转到资源列表,方便进行下一步操作。

针对单个资源,我们也提供了相应的资源风险列表。针对ECS、OSS、Table Store等资源,我们都有分类展示。以OSS为例,我们会展示单个资源的评分以及风险情况,并引导你进行修复。你可以看到每一行都是一个OSS条目,在右侧的操作栏中,你可以选择修复等下一步操作。资源情况会自动刷新,当然,你也可以根据需要点击右上角的刷新按钮进行手动刷新。上述提到的三个功能已经在线上可以使用。

接下来,要与大家分享的即将上线的三个新功能。这个产品从与大家见面至今已经历时一年。在这一年里,我们邀请了众多国内外传统行业的大客户进行试用,并收集到了许多宝贵的建议。这些建议对我们的产品优化起到了非常重要的作用。

比如资源分组管理,它具体能做什么呢?假设客户拥有100台ECS,如果对这100台ECS进行整体打分,可能得到的分数是70分。但实际上,在这100台ECS中,只有30台是极为关键的,承担着生产业务的重任。而其余的70台可能主要用于测试或开发,存储的只是一些临时数据。那么,如何能够单独查看这30台ECS的保护情况呢?客户可能并不太关心那70台当前的状况,因为每天的数据都会不断更新。因此,客户提出了这样一个需求:是否可以对资源进行分组管理?这是一个非常出色的想法,我们已经将其转化为产品的实际功能。

未来,我们还将提供业务分层管理的能力,并基于阿里云的资源标签对资源进行分组,以便对不同程度的业务进行分组管理。客户可以根据自己的需求,创建不同的组别,并只关注特定组别的资源打分情况。例如,客户可以创建一个名为“核心”的组,只关注该组中核心资源的保护情况。此外,客户还可以对这30台核心ECS进行批量修复操作,这也是完全可行的。在保护策略中心,策略将可以直接关联资源的分组,从而实现批量资源保护情况的修复。

保护策略中心这一功能,在产品立项之初就已经被确定为需要实现的能力。然而,由于它涉及的产品功能众多,我们在前面已经分享了五个相关的功能,并花费了一些时间来详细解释。保护策略中心预计将在今年12月底左右与大家见面。它的主要作用是实现一体化策略集中配置。使用过阿里云存储保护功能的客户应该深有体会,要配置不同类型的数据保护策略,往往需要登录不同的控制台,并了解每个功能的具体作用和使用方法。例如,要配置ECS的保护和快照功能,需要登录到ECS控制台;要配置OSS的版本控制功能,则需要登录到OSS控制台;而开启某个NAS文件系统的回收站功能,则需要登录到NAS控制台。一般来说,构建一个业务可能需要同时使用ECS、云盘、OSS和NAS等资源,这就意味着需要登录多个控制台来配置不同的数据保护策略。然而,在BDRC的保护策略中心,这些问题都将得到解决。我们将把所有的保护功能都集成到保护策略中心中,客户只需登录一个控制台就可以配置所有类型的保护策略。未来,保护策略中心还将支持批量关联多个资源进行保护策略的配置,如批量开启NAS回收站功能和OSS版本控制功能等。

未来,我们还将针对灾难防范场景,如防地域性灾害等,提供预设性的策略。这些预设策略旨在简化使用流程,让客户无需深入了解每个功能的具体效果。通过选择预设策略,客户即可轻松实现防自然灾害和地域性灾害的目标。

此外,我们还将推出消息中心功能,以解决许多客户面临的运维难题。例如,有客户反馈,他们设置了天级快照策略,但后来被其他同事更改为周级快照,这不符合业务要求。然而,如果不登录控制台或使用Open API查询,他们无法及时发现这种情况。因此,消息中心将为大家提供这样的通知服务,并支持告警功能。它会通过站内信、邮件、短信等多种告警方式,实时监控所有保护策略的状态变化,并及时通知大家,从而更好地守护企业的数据安全。

在压测过程中,我们遇到了一位数据保护类产品的老客户(GC6客户),他们主要从事招投标、咨询策划等业务。由于这些业务涉及大量敏感数据,如招投标文件和策划文案等,他们对数据保护有着极高的要求。然而,作为传统行业的客户,他们的IT运维人员相对较少。尽管公司整体规模庞大,但在中国公司内,负责备份运维的人员却寥寥无几。

同时,他们的业务部门众多,分布在上海、北京和深圳等地,拥有不同的生产中心。这些资源被不同部门使用,如采购、销售、财务和开发等,导致资源管理变得异常复杂。他们难以确定资源是否得到保护,以及是否采用了恰当的保护手段。此外,他们还需要每两周向上级汇报资源保护情况,这要求他们登录各个控制台,手动生成报告,这无疑增加了工作难度。

因此,他们非常期待我们能够提供一份全面的报表。而这也是我们未来计划实现的功能之一。

以下是客户的真实感触和邀测感言:“数据灾备中心BDRC正是我们想要的。在其他公共云厂商中,我们并未看到类似的产品。在使用BDRC的过程中,它很好地完善了我们云上的灾备方案。我们非常期待新功能的发布,相信这将进一步减轻运维部门的工作量和压力。”

 

三、企业灾备和数据的业务连续性

要实现数据保护与业务连续性,存储作为核心要素,扮演着至关重要的角色。如果存储基础不牢固,许多功能都将无法实现。在这个过程中,数据的冗余,即数据能够在多个数据中心和多个可用区之间分布,是确保数据安全与业务连续性的基石。它能有效避免单点故障,在各种风险和故障情况下,确保数据不丢失且业务能够持续运行。

今天,我们将围绕数据同城冗余和跨区域冗余,来介绍阿里云存储在这方面的能力和最新进展。

在同城冗余的能力建设上,我们秉承“普惠”理念。这意味着我们希望所有使用阿里云存储产品的客户,都能以低成本获得同城冗余的能力,从而提升数据在多个可用区的保护能力,并增强服务的可用性。在对象存储服务上,客户可以一键升级,从本地冗余升级为多AZ冗余。同时,云盘的快照和备份功能,其底层的存储默认就是多AZ冗余的。也就是说,一旦创建了快照,客户就无需支付额外成本,就能享受到多AZ的容灾能力。

在过去12个月里,表格存储已经支持并上线了同城冗余功能。而绝大多数企业都在使用的快存储,也已经在今年发布了同城冗余的云盘。据我们观察,阿里云是国内唯一一家提供该能力的云厂商,而在国际云厂商中,也仅有少数几家提供了类似能力。

Tablestore的同城冗余能力自去年10月发布以来,已经实现了大规模的商业化,并覆盖了八个国内和国际的地域,实现了3AZ的全面覆盖。

关于普惠能力,我们实现了从本地冗余到3AZ冗余的升级,且同城冗余功能默认提供,无需支付额外费用。这意味着客户无需新增成本就能获得这一能力。因此,我们也获得了普惠的能力,并赢得了众多客户的认可。

以某客户为例,其业务需求增长迅速。在业务增长的同时,对于核心业务如订单系统,需要更高的稳定性。然而,降低成本的压力又非常大。在这三个矛盾之间,如果没有Tablestore的同城冗余能力,该客户可能需要投入更多的资源、更高的成本或更多的人力来实现核心系统的同城容灾。而Tablestore则能够很好地满足该客户的需求,并获得了客户的认可。

此外,Tablestore的同城冗余能力相比传统的高可用方案,在灾难应对和可用性方面有着巨大的提升。在灾难发生的瞬间,其血流量只会下降1/3,且用户无需进行任何操作。等Tablestore的服务恢复后,其读写能力也会自动恢复。因此,相比传统的高可用方案,Tablestore有着显著的优势。

传统的高可用方案可能会完全失效,或者需要用户自行决策和判定。在网络条件不佳等情况下,整个恢复时间目标可能会很长。因此,对于有相关需求的业务场景,可以考虑使用Tablestore。而我们会从底层存储默认提供同城冗余的能力,且无需支付额外成本。

 

四、Regional ESID

接下来,我们介绍今年新发布的Regional ESID,这是绝大多数企业都会使用的快存储产品。在今年的产品发布之前,快存储都是单AZ的,存在单个AZ故障导致数据丢失的风险,或者需要企业自行投入大量人力、物力和资源来建设相应的容灾能力。今年,我们深刻洞察到了用户的需求,并研发了Regional ESID。

Regional ESID将所有的数据分布在三个不同的AZ,并且这些数据分布在不同的物理资源上,包括IDC机柜、网络、电力等,都是相互隔离的。因此,即使一个AZ出现故障,数据仍然保持一致,业务也能保持连续。它从数据存储层就确保了RPO等于0,无需额外的数据复制技术来保障。

Regional ESID在典型的业务场景中发挥着至关重要的作用,并且提供了一些新的能力,如数据库的高可用、容器的跨AZ容灾和中间件的跨AZ容灾等。从数据库到容灾、灾备,再到业务连续性,都离不开企业最核心的数据库应用。

以MySQL数据库为例,在传统的高可用方案中,通常需要搭建一个主备节点,并通过MySQL的组复制方式进行数据同步。然而,这种方式在数据同步时可能会遇到延迟,特别是在大数据量或大变更的情况下。如果主节点出现故障,需要进行切换,可能会面临切换的RTO很长或数据丢失的问题。

另外,主备之间的延迟判定也是一个挑战,需要通过心跳表或监控方式进行判定,但在很多场景下可能不准确或难以实施,导致决策时间和切换时间变长。

而基于Regional ESID,我们可以发现,在standby机房中,无需提前准备计算节点,只需按需拉起即可。更重要的是,不需要进行底层复制。只要将数据写到云盘上,它就会自动在多个AZ之间进行容灾。因此,直接在物理层面就解决了复制的问题。

在真正出现故障时,比如A可用区不可用,我们可以直接在B可用区拉起计算节点,服务就能恢复。这样,我们完全消除了传统方案中复制延迟引发的数据不一致等问题,也无需再耗费精力和资源建设数据监控和复制状态。

此外,Regional ESID还能降低25%的存储成本。如果备节点采用按需拉起的架构,计算成本至少可以降低50%。同时,RPO也得到了提升,并且在数据层就能保证RPO等于0。

最后,Regional ESID与其他云盘(如语音盘)具有相同的企业特性,如快照多重挂载等能力。它们的使用方式也相同,并且不会增加企业额外的运维成本。

在典型容器场景中,容器作为一种新兴的应用形式,凭借其出色的灵活性和可移植性,得到了广泛的普及和推广。然而,对于状态化应用(即stateful应用)来说,在扩容和弹性方面面临着巨大的挑战和限制。在没有采用特定技术之前,云盘和容器必须在同一个可用区内,无法实现跨AZ部署。如果需要在另一个AZ中部署资源,就必须先将数据同步或拷贝到该AZ,然后在那里启动Pod,并挂载新的云盘。这个过程不仅数据同步和数据校验的工作量巨大,而且风险也很高。

而我们的Regional ESID产品则解决了这个问题。当A可用区的资源不足时,可以直接在B可用区启动Pod,并挂载Regional ESID云盘,无需受到Pod和云盘必须在同一个AZ的限制。这提供了更高的灵活性,并打破了原有的AZ限制。

此外,Regional ESID在容器环境中的表现也非常出色。当某个AZ出现故障时,可以在另一个AZ中秒级启动Pod并进行切换,从而确保业务的连续性和可用性。这也是我们的客户在使用Regional ESID产品后所发现的巨大优势。他们发现,将容器与Regional ESID产品结合使用,可以显著提升系统的可用性和容灾能力,并降低成本。他们无需再准备大量的standby计算资源,只需按需使用即可,这真正回归到了容器的优势所在。

通过介绍同城冗余的能力,我们了解到同城冗余只能保护机房级的故障,确保在机房出现故障时数据不丢失。然而,当遇到城市级的故障时,我们需要跨可用区的冗余能力来进行数据保护和保障业务连续性。早在2017年,我们的对象存储服务就已经支持了跨区域复制功能。而在2021年,我们又分别支持了快照和云盘的异步复制功能,从而实现了跨可用区的数据冗余。

一个好的跨可用区复制产品必须具备三个要求:首先,它要有出色的RPO  SLA保障;其次,它要具备低成本优势;最后,当灾备中心具备读写能力时,不同中心之间的服务能力应该保持一致,无需对业务进行额外的改造或约束。而我们的OSS就具备这三个能力。

首先,OSS提供了RTC保障,可以确保RPO小于十分钟。其次,我们希望业务灾备中心在日常就可以提供服务,以降低成本。为此,我们提供了灵活的双向同步和一到多边复制能力,以满足用户就近访问的需求。最后,我们的OSS还具备镜像回源能力,这意味着当一个数据写入到一个区域后,其他区域也可以快速读取到该数据,而无需对业务进行改造。

如果他身处杭州,而一旦我们配置了跨区域复制的能力,杭州的用户在想要观看新发布在北京某个存储桶上的视频时,可以直接通过镜像回源的功能获取。如果杭州本地没有缓存该视频,系统会自动从北京的原存储桶中获取并返回给用户。因此,OSS的跨区域复制功能确实具备这样的能力。客户可以基于OSS构建一个多地域多活、高可用性的架构。

以亲宝宝为例,它保存了大量家庭珍贵的视频、照片等数据。通过跨地域的容灾策略,这些数据可以得到非常好的保护,并且在多个地域都能获得访问能力。比如,在杭州、上海等各个中心,都可以提供读写和就近访问的服务。这样,业务可以在非常低的成本下扩展其读写能力,同时用户也能享受到就近访问的最佳体验。这是一个生动的案例。

此外,云盘也是绝大多数企业都会使用的存储产品。我们的云盘在跨区域复制方面,早在2021年就已经提供了异步复制的能力。在杭州的主卷上,每个复制周期都会捕获并同步中间的差异化数据到另一个可用区的副卷上并应用。这种方式对杭州区域的主卷性能没有任何影响,并且每次同步都是细粒度的,只有变化的数据才会被同步,因此同步的数据量是最小的。同时,我们还提供了出色的可观测性能力。在不久的将来,我们还将上线RTC保障,与OSS一样,提供RPO小于10分钟的SLA保障。

除了这些S层(存储层)的能力外,我们还提供了多层次的同城冗余能力和跨区域的复制能力。在整个阿里云存储基础设施中,我们为用户提供了坚实的数据保护和业务连续性保障。然而,要保障业务的更高稳定性和韧性,仅仅依靠S层的能力是不够的,还需要企业配合更上层的灾备能力。

多年来,我们观察到企业对灾备建设的需求也在不断演进。从十年前的从无到有,逐渐转变为从有到全、从有到精。接下来,我将与大家分享阿里云的SaaS化备份产品以及云备份服务,这些产品旨在洞察企业的高阶需求,解决新的挑战,并帮助客户创建更加智能、合规且能够降本增效的灾备方案。

 

五、企业灾备建设面临的新挑战

第一,我们需要确保核心数据能够应备尽备,即确保所有数据都被完整且准确地备份,无遗漏、无错误。这是一个至关重要的前提,因为任何数据的遗漏或错误都可能导致在恢复时出现问题。

第二,如果生产环境不幸遭遇勒索病毒等恶意软件的攻击,我们需要能够以最快的速度获取到正确的备份数据来进行恢复。这意味着备份数据必须是可靠且易于访问的,以便在紧急情况下能够迅速恢复业务运行。

第三,备份数据的强可用性和不可变性也是我们需要关注的问题。备份数据一旦完成并存储在存储系统中,就必须确保其不会被勒索病毒等恶意软件攻击,也不会被误删除。这需要采取一系列的安全措施来保护备份数据的完整性和可用性。

最后,备份方案的降本与简化运维也是企业非常关心的问题。随着企业对成本控制的日益严格,备份方案的成本成为了一个重要的考虑因素。因此,我们推出了许多功能来帮助客户构建一个既符合灾备要求又成本较低的备份方案。同时,对于许多客户,尤其是传统企业客户来说,他们通常拥有众多的账号和复杂的系统架构,如何简化运维也成为了一个新的挑战。我们需要提供易于管理和维护的备份方案,以降低客户的运维成本和提高效率。

 

六、云备份Call back up

云备份Call back up是阿里云的统一灾备平台。它能够帮助客户统一备份和管理本地及云上的多样化数据资源,具备备份上云、迁移上云、归档上云,以及云上备份和云上容灾的一体化能力。

云备份具备以下三个显著优势:

首先,数据源覆盖极为全面。针对本地的文件数据库、NAS虚拟机等,我们都提供了备份上云的能力。同时,对于本地的NAS、HDFS以及S3对象存储,我们也提供了策略化归档上云的功能。对于阿里云上的各类数据,包括ECS整机、文件数据库、OSS、NAS、Tablestore等,我们也提供了统一的备份能力。此外,针对ECS实例,我们还提供了跨可用区、跨地域的容灾能力,以满足不同RPO需求,并提供多实例容灾编排能力。同时,我们还配备了丰富的企业级功能,以帮助客户解决面临的挑战。其中,策略中心新增了标签关联功能,以及降本增效的特殊保留和自动归档选项。值得一提的是,我们在公共云上首发了备份点的病毒检测功能,帮助客户在遭遇勒索病毒等恶意软件攻击后,能够迅速恢复生产。

其次,云备份提供不可变的备份服务,包括跨账号备份和跨地域备份,确保数据的安全性和可靠性。

最后,产品的特色在于安全、经济和高效利用。在数据上云的过程中,我们采用端到端加密技术,包括默认的AES256加密以及客户可选的阿里云KMS自带密钥加密。同时,我们使用同城冗余的备份库来抵御机房级灾害。我们的服务具备三个9的SLA保障,并配备了专业的灾备产品重复数据删除功能。对于灾备软件来说,降本的关键在于重复数据删除,以避免数据冗余导致的存储容量浪费。此外,作为SaaS化产品,我们无需客户部署任何额外软件,只需通过简便的图形化界面即可实现免运维操作。

具体的挑战及应对策略。随着数字化转型的加速,特别是AI技术的兴起,企业数据量急剧增长,业务和资源每天都在不断变化。如何确保核心数据的备份成为了一个新的难题。例如,当企业创建新的ECS实例或OSS Basket时,如何确保这些核心资源能够及时得到本地或异地备份?为此,我们推出了基于标签的资源自动关联备份功能。只需在备份策略中配置并开启标签关联资源做备份的能力,创建后的资源就会自动被纳入备份范围,无需额外操作。

接下来,我们的行动方案如下:在每个备份周期,系统会自动巡检那些带有特定标签的资源,并将它们自动纳入备份任务中。这一功能支持多种云上数据类型,包括ECS整机文件、OSS、NAS、Tablestore等。通过这一能力,我们能够有效地解决第一个挑战——确保核心数据的全面备份。

关于第二个备份点的病毒检测,我们是全球公共云备份类产品中首个具备备份点病毒检测能力的服务商。具体来说,当客户将数据备份到我们的备份库后,我们会对这些数据进行全面检测,判断其是否干净或存在风险,并对备份点和备份文件进行相应标记。我们支持检测23种恶意文件类型,并允许客户在备份策略中轻松开启此功能。随着每次备份任务的执行,系统都会自动进行检测,同时,客户也可以根据需要,对单个备份点进行手动检测。在标记完成后,客户在恢复数据时,可以迅速识别出哪些备份点和文件是安全的,从而确保恢复过程的顺利进行。这就解决了第二个问题——在勒索病毒攻击后实现快速恢复。

第三个挑战是备份数据的不可变性。尽管已经备份,但数据仍面临被误删或恶意删除的风险。根据VIM的调研报告,超过90%的企业在遭受勒索病毒攻击时,其备份数据也未能幸免。因此,即使进行了备份,仍存在安全隐患。

而不可变能力正是为了解决这一问题而设计的。它基于备份库开启,一旦设置便不可撤销。在数据保留期限内,无论采用何种手段,都无法删除或修改这些数据。例如,如果设置保留期为一年,那么在接下来的365天内,无论使用哪个账号、采用何种方式,甚至是黑客攻击,都无法删除或更改这些数据。通过这种方式,我们确保了备份数据的强可用性和不可变性,为合规性要求再添一道坚实的保障。

 

七、跨账号备份

传统企业对跨账号备份的需求日益增强,不仅限于云备份,还包括数据灾备中心。例如,客户可能拥有十个账号,并希望有一个统一的视角来监控每个账号的资源保护状况。跨账号能力已成为数据服务类产品不可或缺的功能,因此云备份也具备了跨账号备份的能力。客户可以利用一个备份运维账号,来集中管理其多个生产账号的数据备份。备份完成后,数据会统一存放在备份运维的备份库中,实现统一出账和统一管理。

对于使用这些账号的部门,如采购部,他们可能并不精通IT技术,只知道在需要恢复数据或数据出错时,向备份运维团队提出恢复请求。例如,他们可能会说:“我这个文件夹需要恢复。”备份运维人员则可以轻松地从备份库中找到并恢复所需数据,从而大大降低了各部门的学习成本。

在成本方面,推出了TCO优化策略,包括特殊保留策略和自动归档功能。随着企业对数据保护的重视和数据量的快速增长,成本压力日益显著。特别是在银行、医院等行业,由于合规要求,数据需要保留三年、五年甚至十年以上,但这些数据的使用频率可能非常低。

为了降低备份数据的存储成本,我们推出了以下两项功能:

一是静谧远书的特殊保留策略,客户在使用天级备份后,可以为每周、每年的首个备份设置特别的保留时间。例如,每天备份一次并保留七天,而每周的第一个备份则可以延长保留时间至一个月。以此类推,确保更近的数据用于恢复,更远的数据则满足合规要求。

二是自动归档功能。对于超过30天的备份数据,可以自动归档至备份库的归档层。无需手动操作,只需在备份策略中配置好归档时间,系统即可自动执行归档操作,并在需要时按需取回数据。

这两个功能都可以有效降低成本,而且它们是可以结合使用的。您可以根据业务需求,灵活搭配这两个功能,以实现成本节约的最大化。

最后,我分享一个案例:一家国际连锁酒店使用了云备份服务。这家酒店规模庞大,广为人知。在2024年,他们决定将部分业务从其他海外云厂商迁移到阿里云的上海和深圳地域。对于像这样的MAC客户来说,数据保护至关重要。因此,在迁移到阿里云时,他们非常关注备份方案是否符合其要求。

他们的需求包括:整机ECS文件的备份、备份数据的强可用性(确保客人资料等不被误删、侵害或篡改)以及备份数据的检测(他们在之前的云厂商上使用了第三方安全公司的服务进行备份数据检测)。

由于海外的云服务商提供的备份软件并不自带备份点病毒检测功能,因此客户采取了一种替代方案。他们首先生成备份,如快照,然后通过共享功能将其发送到第三方安全公司的账户中。接着,这些备份会被挂载到第三方安全公司的检测引擎上进行病毒检测。

然而,这种方案存在两个问题。一是安全性问题,因为客户的数据需要被分享给另一个安全公司。二是成本问题,因为第三方安全公司需要部署一个检测引擎,这个引擎通常运行在阿里云的ECS实例或其他云服务商的计算资源上,这些都会产生额外的成本。

针对这些问题,我们提出了以下解决方案:

首先,推荐使用云备份服务,对ECS整机和文件同时进行本地和异地的备份。特别是在上海和深圳的客户,我们不仅进行了本地备份,还实现了这两个地域之间的互备,以最大程度地抵御地域级的灾害。此外,我们还为这两个备份库都开启了不可变备份功能,以确保备份数据的安全性和合规性。

最后,对客户特别重要的功能是备份点的病毒检测。与第三方方案相比,我们的方案具有以下优势:首先,客户的数据仍然保留在他们的账户中,他们可以直接使用备份点的病毒检测功能,而无需分享任何数据,从而保证了绝对的安全性。其次,从成本角度来看,由于我们的服务是基于Serverless架构的,客户无需构建或维护任何检测引擎,只需即开即用。此外,我们的自动病毒检测功能也满足了客户对备份数据进行检测的要求。

 

八、回顾

我们发布了最新的企业灾备管理服务数据灾备中心BDRC,并分享了存储的高可用能力和云备份的新功能。而阿里云不断的进行创新,是为了客户企业数据更安全,业务更连续。

 

相关实践学习
2分钟自动化部署人生模拟器
本场景将带你借助云效流水线Flow实现人生模拟器小游戏的自动化部署
7天玩转云服务器
云服务器ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,可降低 IT 成本,提升运维效率。本课程手把手带你了解ECS、掌握基本操作、动手实操快照管理、镜像管理等。了解产品详情: https://www.aliyun.com/product/ecs
相关文章
|
6月前
|
运维 Cloud Native 领域建模
核心系统转型问题之实现风险可控如何解决
核心系统转型问题之实现风险可控如何解决
|
8月前
|
存储 安全 数据安全/隐私保护
使用云存储进行灾难恢复与业务连续性规划
【6月更文挑战第1天】云存储成为数据安全的超级英雄,提供灾备和业务连续性。通过选择可信的云服务商,定期备份数据,即使本地故障也能迅速恢复。简单示例展示了Python上传数据至S3,但实际需考虑安全性、速度和备份策略。定期检查云存储状态并制定详细恢复计划,确保灾难应对有序。为保护数字资产,投入云存储是值得的挑战。
81 1
|
9月前
|
存储 容灾 关系型数据库
企业上云的灾备规划与分析
【4月更文挑战第21天】在数据分析方面,数据被分为系统、基础、应用和临时数据四类,以及数据库和非数据库、孤立和遗失数据四种存储管理方式。业务分析中,业务系统被划分为关键、重要和一般三类,强调了不同类型业务中断的影响程度。在灾备技术分析中,介绍了离线式(冷容灾)和在线式(热容灾)容灾技术,包括备份软件和数据复制的三种层次:基于存储、主机和数据库。
|
存储 运维 Prometheus
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.1监控预警体系建设
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.1监控预警体系建设
320 0
|
存储 NoSQL 算法
互联网三高如何保障业务连续性
互联网三高(高并发、高性能、高可用)中的高可用,看完本文相信能解开你关于高可用设计的大部分困惑
83798 37
互联网三高如何保障业务连续性
|
运维 监控 测试技术
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.1 游戏业务稳定性保障——5.1.1新游上线稳定性保障实践(4)
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.1 游戏业务稳定性保障——5.1.1新游上线稳定性保障实践(4)
178 0
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.1 游戏业务稳定性保障——5.1.1新游上线稳定性保障实践(4)
|
缓存 监控 网络协议
云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.3高可用架构建设(上)
云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.3高可用架构建设(上)
270 0
|
缓存 监控 容灾
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.3高可用架构建设(下)
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.3高可用架构建设(下)
210 0
|
弹性计算 数据安全/隐私保护
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.1游戏业务稳定性保障
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.1游戏业务稳定性保障
156 0
|
运维
《云上业务稳定性保障实践白皮书》——二. 理论概念——2.2 故障
《云上业务稳定性保障实践白皮书》——二. 理论概念——2.2 故障
202 0