数据灾备中心:创新性企业灾备管理服务

本文涉及的产品
对象存储 OSS,20GB 3个月
阿里云盘企业版 CDE,企业版用户数5人 500GB空间
对象存储 OSS,内容安全 1000次 1年
简介: 阿里云数据灾备中心旨在提供创新的灾备解决方案,确保企业业务连续性和数据安全。面对数据风险,如误删、勒索软件等,即使在公共云上,企业仍需灾备措施。数据灾备中心提供统一管理,通过3-2-1法则实现全面保护,特色包括统一覆盖多种资源、直观的星级评分和3D展示、简化运维流程。未来将推出更多功能,如资源分组评分、一体化策略中心、定制报表和消息中心,以支持不同行业的高要求,如金融、医疗等。

分享人李媛(圆儿)阿里云高级产品专家

本文旨在分享阿里云数据灾备中心,这是一个创新性企业灾备管理服务,助力企业业务连续性,轻松实现安全合规。

曾有一句老话“数据不备份,运维两行泪”,公共云具有高可靠、高可用的能力,意味着数据上传后不丢失、不错误,能够保证客户随时随地使用这些数据。但其实数据仍然无时无刻不暴露在风险之中,如数据的误删、勒索病毒、自然灾害和系统故障,都可能会对关键业务的连续性造成影响。数据丢失,无法恢复,对于一些特殊行业影响更大,如金融、医疗、政企、国家,需要满足特定行业的安全与合规,对企业提出更多的要求。企业也需要保证客户的数据安全,如网络安全等级护、个人信息的保护法、基础设施安全保护条例,

以及针对银行和医院的具体的监管和指引等等。由此可见,即使企业上了公共云,仍然需要数据灾备。

数据灾备中心应运而生

阿里云已经提供了多种存储数据的灾备方案,包括IAAS原子能力、SaaS备份服务等,可以满足客户多种多样的需求。

3.png

随着企业的数字化转型节奏的加快,企业上云的规模逐渐增大,以前可能只是部分数据上云,如今上云的数据逐渐增多。以前的一些传统企业可能有十几个部门,最初只有1-2个部门在云上,甚至很多在IDC。但是,当大家发现好像公有云更适合自身的企业形态时,可能就会在云上账号分布非常多的用户账号,以供不同的部门使用。在账号较多、资源较多的情况下,灾备运维部门的管理会遇到很多挑战:

  • 漏配,原本关键的业务数据需要保护,但由于账号过多,资源不断变化(新增、删除),尤其在新增时灾备的运维人员没有注意到关键的数据,导致未受到保护,则会对业务产生较大的风险。
  • 错配,假设某个业务原本需要本地加异地备份,但漏配了异地备份的部分灾备方案,不满足合规或业务需求,则会在审计过程中产生问题。
  • 资源多的情况下,会存在不同的存储资源及不同的这种方式。灾备的运维人员对不同的资源,需要登录不同的控制台或使用不同的API配置相应的灾备方案,这对灾备运维人员的灾备方案掌握有较高的要求,也需要通过很多的路径来进行管理。
  • 灾备的运维人员向上汇报时,统一反应过程非常繁琐,生成报表时需要到不同的控制台拉取数据,运维汇报艰难。

综上所述,在客户规模越来越大时,在灾备的运维、合规以及全面保护数据安全性方面,产生了很多挑战。因此,数据灾备中心应运而生。

数据灾备中心-创新性企业灾备管理服务

阿里云数据灾备中心是使用灾备领域专业的3-2-1法则,打造的专业企业灾备管理服务。该产品名称是Backup and Disaster Recovery Cente(BDRC),在经过授权后可以通过智能巡检保护客户的云上数据资源,实行数据保护状态,并建议修复方案,使用一体化的策略中心,对数据资源进行集中化的管理,并且也提供定制化的报表和消息中心等功能帮助客户简单高效的实现数据灾备及合规管理。

数据灾备中心具有以下三个特点:

  • 统一:存储的数据灾备全数覆盖,满足客户多种多样的需求
  • 直观:通过分数星级和全地域3D图多方位展示数据的保护情况
  • 省运维:配置全套的引导式流程,详细解释了每个方案,能够快速上手实操,减少灾备方案的学习成本

另外,数据灾备中心具备可视化的区域大图,可以全面掌握数据的保护情况。客户登录控制台就可以直接使用,客户登录控制台通过授权后,数据灾备中心就会发现登录的UID下的公共云资源情况,包括有多少台ECS,有多少OSS的bucket,有多少NAS文件系统等。然后,告知客户所有数据保护的情况,如哪些做了备份、哪些是本地备份、哪些是异地备份、哪些还未做任何备份,其次就是具体的解决方案,比如客户发现自己的十台ECS本来需要备份,但未做备份,应如何操作?因此,该阶段也会提供修复引导及路径,客户就可以根据引导按照具体的需求来进行修复并进行持续护航。

客户的灾备方案会不断更新,资源可能也不断更新,因此数据灾备中心是天级刷新的频率,不断刷新资源的拥有情况和数据灾备方案的配置情况,如果存在问题则会主动预警。运维人员每天都可以得到最新的状态。下图中左侧是概览图,上面展示了具体的分数,它们是对客户所有UID下所有类型资源的保护情况加权的打分,用户可以登录到控制台查看详情。右侧图中的小点表示资源,用不同的颜色也表示其保护的情况,如绿色表示保护程度很好,黄色表示可能需要采取行动。这样就改变了从前资源region化的限制(要看不同的region,不断切换region)。

6.png

其中,关于发现UID下公共云资源情况,当前支持ECS/OSS/NAS/Tablestore,更多云上数据源(如RDS)仍在支持开发中。另外,关于展示数据保护情况,即赋分的部分,在邀测过程中,有客户希望实现资源分组,核心资源达到的效果尽量高,要求分数较高,但如果对所有的ECS计算加权分,则范围太广,无法对负载核心资源的ECS单独打分,现在阿里云正在做基于标签分组评分能力的开发,预计2024年9月前上线。

前面提到,客户拥有多种资源,对不同资源做数据灾备方案时需要在不同的控制台或API操作,如ECS/OSS/NAS/Tablestore,包括rds等。一体化的备份策略中心,可以帮助客户进行多种配置时不再难,客户只需要登录BDRC控制台的备份策略中心,配置一体化的配置方案。BDRC策略中心在接收到客户的配置之后,通过内部机制调用相应产品的API接口,实现客户各类灾备方案的配置,这样就可以帮助客户化繁为简,登录一个控制台解决多个问题,通过预设策略、批量资源的关联,减少运维的投入,该功能预计在2024年的12月份之前上线。

数据灾备中心里还具备定制化的报表和消息中心,能够让审计和汇报都变得更加简单,该功能预计在20253月份之前上线,主要包括三个方面:

  • 支持充分定制报表,可以从资源维度、时间维度、时间保护维度等生成相应的报表以供使用,满足运维人员汇报需求或审计需求。
  • 支持多种报表格式的下载,如表格、文本、图片等。
  • 保障告警及时有效,不仅可以在告警中配置相应联系人,还可以根据不同类型的报警消息,确认是否要设定相应的条件,以确保运维人员接收到“非常重要”的消息。

邀测过程中,有一家著名的零售企业使用了BDRC协助完善云上的数据灾备体系。该客户属于传统零售行业,无论是从业务要求角度,还是合规要求角度,对数据保护的要求都较高。但在传统行业领域,IT的运维投入相对较少,运维人员涉及事务很广,部门很多,对业务连续性的要求也多种多样。该企业有专门做备份运维的部分,运维人员希望能够简单快速掌握集团云资源数据灾备情况。

该客户在上海、北京、深圳都有云上资源,有采购、销售、财务、市场营销、开发等部门,都有各自的账号,资源类型非常多,跨越了多个地域,管理查看非常复杂。且数据灾备方案也很多,备份的运维人员无法确定当前的保护方案能够满足业务方的需求,在汇报时一体化报告生成非常复杂,且不具备可视化效果,只能在各处拉取数据,再利用表格汇总,直观性很低。

在利用数据灾备中心测试后,其备份运维负责人表示“数据灾备中心BDRC 是我们想要的,其他公共云厂商还未看到类似的产品。在产品使用过程中及时发现了应配置保护方案但未配置的云上资源,帮助我们完善了云上数据灾备体系。非常期待策略中心和报表功能的上线,来进一步减轻运维部门的工作量和压力。

阿里云数据灾备中心希望通过产品让客户的业务更连续,企业更合规,运维更轻松,期待更多用户使用。

相关实践学习
2分钟自动化部署人生模拟器
本场景将带你借助云效流水线Flow实现人生模拟器小游戏的自动化部署
7天玩转云服务器
云服务器ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,可降低 IT 成本,提升运维效率。本课程手把手带你了解ECS、掌握基本操作、动手实操快照管理、镜像管理等。了解产品详情: https://www.aliyun.com/product/ecs
相关文章
|
17天前
|
存储 容灾 关系型数据库
云环境中的灾备规划与分析
【10月更文挑战第24天】企业在数据备份和灾备中,依据数据用途和管理方式,将数据分为系统、基础、应用和临时数据,以及数据库和非数据库数据。关键业务系统对业务连续性要求最高,其次是重要业务系统,然后是一般业务系统。
|
4月前
|
存储 人工智能 监控
云端护航:企业灾备策略与实践
云灾备已经成为现代企业不可或缺的一部分,它不仅能够帮助企业快速从灾难中恢复,还能提升整体的业务连续性和数据安全性。随着云计算技术的发展,未来的云灾备将会更加智能化、自动化,更好地满足企业在数字化转型过程中的需求。
|
6月前
|
存储 容灾 关系型数据库
企业上云的灾备规划与分析
【4月更文挑战第21天】在数据分析方面,数据被分为系统、基础、应用和临时数据四类,以及数据库和非数据库、孤立和遗失数据四种存储管理方式。业务分析中,业务系统被划分为关键、重要和一般三类,强调了不同类型业务中断的影响程度。在灾备技术分析中,介绍了离线式(冷容灾)和在线式(热容灾)容灾技术,包括备份软件和数据复制的三种层次:基于存储、主机和数据库。
|
监控 容灾 安全
《云上容灾交付服务白皮书》——2.容灾技术架构——1.3 行业容灾现状分析(上)
《云上容灾交付服务白皮书》——2.容灾技术架构——1.3 行业容灾现状分析(上)
520 0
|
监控 容灾 安全
《云上容灾交付服务白皮书》——2.容灾技术架构——1.3 行业容灾现状分析(下)
《云上容灾交付服务白皮书》——2.容灾技术架构——1.3 行业容灾现状分析(下)
321 0
|
域名解析 容灾 安全
《医保行业容灾演练云上技术白皮书》——第三章 医保云容灾建设方案——3.3 应用容灾解决方案框架
《医保行业容灾演练云上技术白皮书》——第三章 医保云容灾建设方案——3.3 应用容灾解决方案框架
207 0
|
负载均衡 容灾 应用服务中间件
《医保行业容灾演练云上技术白皮书》——第四章 医保云容灾演练方案——4.2 容灾演练改造——4.2.2 平台侧网络改造(下)
《医保行业容灾演练云上技术白皮书》——第四章 医保云容灾演练方案——4.2 容灾演练改造——4.2.2 平台侧网络改造(下)
238 0
|
弹性计算 容灾 安全
《医保行业容灾演练云上技术白皮书》——第四章 医保云容灾演练方案——4.2 容灾演练改造——4.2.2 平台侧网络改造(上)
《医保行业容灾演练云上技术白皮书》——第四章 医保云容灾演练方案——4.2 容灾演练改造——4.2.2 平台侧网络改造(上)
291 0
|
弹性计算 负载均衡 容灾
《医保行业容灾演练云上技术白皮书》——第四章 医保云容灾演练方案——4.2 容灾演练改造——4.2.3 应用侧网络改造
《医保行业容灾演练云上技术白皮书》——第四章 医保云容灾演练方案——4.2 容灾演练改造——4.2.3 应用侧网络改造
135 0
|
容灾
《医保行业容灾演练云上技术白皮书》——第四章 医保云容灾演练方案——4.1 容灾演练调研——4.1.3 应用侧调研及改造要求
《医保行业容灾演练云上技术白皮书》——第四章 医保云容灾演练方案——4.1 容灾演练调研——4.1.3 应用侧调研及改造要求