首页
学习
活动
专区
工具
TVP
发布

系列(八)——同城数据冷备建设

为了让企业能更好用好云平台的数据安全能力,本文重点云平台数据备份冷备能力,以腾讯云为例,主要从以下两个维度介绍:同城数据冷备能解决企业什么问题,达到怎么样业务效果?...,云平台控制台均提供便捷页面,通过鼠标点击快捷完成数据备份和回档设置,如下图所示:图片数据备份覆盖度,目前数据产品均有数据备份能力,常见例如mysql,redis,ckafka,es,pg等等2.2 同城冷备份方案同城数据冷备方案主要依赖于云平台能力备份能力...,对现有业务架构没有任何改造,方案架构如下:图片该方案核心要点说明:数据备份:云侧数据库mysql和redis在控制台设置数据备份参数,数据备份存储在COS,具备地域级别,RPO依赖于数据库备份周期以及时间...本文小结同城冷备方案,在云平台的协助下,企业几乎0成本并拥有同城数据冷备能力来保障业务生命线。指标详细说明能力具备同地域(不同可用区)数据备份能力,不具备不同地域的能力。...3.演练能力建设,增加平时运维成本以及自动化工具开发功能。

6.2K113
您找到你想要的搜索结果了吗?
是的
没有找到

备知识总结:与备份区别、备技术、体系规划

系统在企业中给与数据安全系数相当高的保障,但是系统倒是是什么,他们是什么意思?恐怕连正在使用备份的网络管理人员都不能解释。本文用最浅显的语言给大家解释备份到底是什么。...如果是同步,那端同时就删除了;如果是异步,那端在数据异步复制的间隔内就会被删除。这时就需要从备份系统 中取出最新备份,来恢复被错误删除的信息。...规划企业安全保障体系考虑的因素 对于企业而言到底应该如何建设自己的备系统,是只建设备份系统、还是只建设系统、还是需要二者同时建设、或者是分步骤的建设,谁先谁后等问题,主要根据业务的需求而定: (1...备份系统+异地系统 这是一个较为理想化的系统一体化解决方案,能够在很大程度上避免各种可能的错误。 恢复等级 ? 灾难恢复层次 ? 备技术层次 ? 1.1 磁盘阵列备技术 ?...2.1 卷管理软件备技术 ? 2.2 数据库日志复制技术 ? 2.3 数据库备技术 ? 3.1 应用备技术 ? 11.体系结构规划 ? 系统正常运行 ? 生产中心单台主机宕机 ?

8K21

异地方案解析

一、异地主要备份三种数据: 1、DB数据 2、操作系统 3、日志信息 二、恢复时间不能超过30分钟 三、图中为DB的备份方式,DB总的有四份备份:生产存储一份、移动硬盘一份、备份存储一份、备存储一份...备份方式为,平时通过生产系统的介质服务器传输到移动硬盘,通过CS传输数据到备中心的介质服务器,在通过介质服务器传输到备份存储、备存储。...生产中心发生异常时的DB切换方式为,将移动硬盘迅速转移挂载到备中心的介质服务器,然后再发起恢复 四、日常对OS进行每日备份,通过CS传输到备中心的介质服务器,再发送给备份存储和备存储,即OS的备份有三份...:生产存储、备份存储、备存储 五、日志的备份和OS一样 六、恢复切换步骤:日志恢复、OS恢复、修改IP和主机名、移动硬盘转移挂载 七、本地恢复 image.png 八、两地传输带宽的计算要考虑每日数据增量

2.5K10

高校备份方案 2.0

,当风险发生时,数据丢失不可避免; 既有的备份系统不完备,多采用定时备份、本地备份的模式,备份时间窗口大、周期长,数据存在无法恢复或丢失的风险较高; 相当多的信息系统未考虑应用和业务连续性的需求,异地没有规划建设...2.建设目标 充分考虑当前信息系统的现状,并借鉴目前网络安全法、等保 2.0 等政策法规对高校信息系统安全的要求,建设业务系统备份保护需要达到以下目标: 规划好系统的等级保护和分级保护; 数据损坏、...△级别与能力 三、备份方案 2.0 的创新应用 备份方案 1.0,有基于硬件存储层架构,也有基于应用层架构。基于硬件存储层方案,建设和运维成本比较高。...英方软件基于超低时延的数据复制技术,针对云和大数据环境下行业对备份的新要求,提出了备份方案 2.0。...△备份方案 2.0 2.0 方案覆盖数据库系统故障、应用系统故障、单机单点故障、逻辑错误&病毒攻击、自然灾害等场景,满足高校在数据库双活、云备、秒级接管、数据持续保护等备份需求,具备了多层次

1.5K30

系列(一)—— 云上业务方案要如何选?

本文从容概念,决策因素,典型案例和方案对比进行说明,希望方案的选择有所帮助。 1.概念 将这个词,分开来看“”和“”。...其次考虑当前方案能否满足切换和恢复目标。 3)扩展性,主要为后续业务平滑演进。...典型案例 虽然这里对“”概念进行扩展,一般指同地域以及跨地域粒度的;以云上客户案例同时结合腾讯云产品能力,分别对同城,异地备以及异地多活进行说明。...image.png 3.2 同城 同城根据数据写入方式分为单写或者双写;单写称为半双活,双写称为双活。 3.2.1 同城半双活(单写) 同城半双活核心特征: 1)范围:可用区粒度。...image.png 3.2.2 同城双活(双写) 同城双活核心特征: 1)范围:可用区粒度 2)流量分布:每个可用区均承载流量业务;数据库采用分区模式,将数据分为两个可用区,az间的网络延时对业务影响较小

7.6K115

同城异地

序言 同城异地备,主要是用来进行备份的,从而当一个数据中心挂了,另外一个数据中心经过切换之后,能让服务迅速的恢复。...同城双活,则是基于多机房的情况下,流量经过双机房,一个机房挂掉,完全不影响业务。...随着业务的进一步发展,需要提供高可用水平,从而需要从单机房扩展为多机房,从而也就有了同城。。。 对于运维来说,多一次升级,多一次变更,就会多一个故障,多一个锅。。。...热升级了解一下,不可预知的中断了解一下 同城异地最关键的点在于存储,存储如何跨机房使用,从而分为几个方面进行探讨: 1、 DNS解析 在业务大量使用DNS解耦的时候,而且使用双机房的时候

3.9K31

技术方案|某工业集团PaaS方案

因此,制定一套科学、高效的方案至关重要。本文将围绕某全球领先的工业集团如何通过灵雀云企业级云原生平台ACP(以下简称ACP)实现高效的方案展开深入探讨,旨在为您提供可借鉴的经验和启示。...整体方案介绍 图表 1 方案总体架构 在制定企业整体方案时,应考虑技术中台、应用数据、应用以及接入层的需求。...灵雀云提供ACP原生能力,如数据同步、接入层切换等方案,能够满足各种需求。 数据层 业务运行过程中,数据的持久化至关重要。...考虑到项目中包含管理平台,对于不同产品的备份和恢复方案的问题,可以将各种备份和恢复方案管理平台中脚本化。...方案点评 该方案在数据、应用和接入层方面已经具备了一定的基础和框架,但仍然有待优化点: 1.

7610

的架构分析和选择策略

1.传统中心的架构 半径是衡量方案所能承受的灾难影响范围的指标。不同灾难的影响范围是不同的,而距离也会影响到技术的选择。...中心的架构按照源备端之间的距离,可分为本地同城双活、两地三中心。 1.1本地 本地一般指主机集群,当某台主机出现故障,不能正常工作时,其他的主机可以替代该主机,继续正常对外提供服务。...1.2同城双活 同城双活属于本地,但根据运营模式可以分为主备和双活两种形式: 主备模式即生产中心正常对外提供服务时,同步将数据单项复制到备端数据中心,且备端不对外提供服务。...随着IT基础架构逐渐云化,也面临着云化转型,不断涌现出更多的云产品和方案。...实现支持高度自动化的异构平台方案,可以自由选择目标云平台进行备份,方案灵活性更高,安全性更强。

2.1K30

系列(三)——云网络建设

以腾讯云为例,在同地域选择机房地址的时候,距离大于60公里,要求不同可用区延时小于3ms,来满足云上客户同城建设基本需求。...1.2 云网络产品 对于云上网络产品,从业务流量维度主要分为: 流量走向 对应产品 建设 南北向流量 负载均衡(CLB)、NAT网关、弹性公网IP(EIP)、anycast IP 1.同城多活,避免跨可用区的流量...2.负载均衡公网CLB具备已跨AZ能力 3.NAT网关绑定多个EIP,提升连接数 东西向流量 专线接入、对等链接、云联网、VPN、private link 1.敏感业务建议不要使vpn打通 2.混合云专线接入方案...2.网络复杂度 同城或者异地建设,网络层面因素主要有三个: 1)跨区或者跨地域网络延时,对上层业务影响。 网络延时,通过优化基础设施手段是非常有限的,毕竟受限于实际物理距离和光速。...专线为主,不同POP点接入;VPN为辅,最为紧急逃生通道,同时这里注意云上vpn网关最大带宽承载为1G,如果不满足业务要求,建议使用GRE方案作为应急通道。

4.3K93

系列(九)——异地数据冷备建设

异地数据备份挑战相对同城数据备份,异地数据冷备主要挑战是成本,主要是跨地域之数据传输带宽成本。...对于同城数据备份,对企业来说“零”成本,企业可以把所有数据都进行备份;而跨地域数据备份,需要对业务进行梳理,尤其数据量比较大的业务,来决策哪些业务需要异地数据备份。...如果涉及到一个库只需要同步其中几张表,可能还会涉及到业务改造;由此可见相当于“零”成本,“零”投入同城数据备份而言,异地数据备份会带来一些复杂度。2....异地数据冷备方案2.1 API实现方案数据备份:云平台的数据库数据备份均为同地域,因此需要将该备份数据上传到异地COS存储桶。...2.3 数据库备份服务数据库备份服务拥有一套完整的数据备份和数据恢复解决方案,具备实时增量备份以及快速的数据恢复能力,同时具备异地能力。

8.4K164

,双活、多活、同城、异地、多云,到底应该怎么选?

去年写过一篇《做,冷备是不是个好方案?》,当时提出来,冷备或者主备,其实并不是一个理想的方案,而且绝大多数情况下,只能是一个心理安慰,真正发生故障的情况下,这样的模式根本起不到作用。...最近,公有云又出了些大故障,各大群和朋友圈又开始沸沸扬扬,但是整体看下来,声音无非两种: 单站点不靠谱,要有,出现这种情况就得马上切,所以回去赶紧建设站点; 鸡蛋不能放在一个篮子里,单云不靠谱,...既然要双活,必然会选择另一个跟当前机房有一定距离的机房(同城或异地),而且距离必须得拉开才有意义,如果都在一个园区里面,就没有任何意义了。...我们可以得出的几个结论: 不管怎么选择方案,我们自己的业务系统,从自身架构上,一定要支持单元化,一定要支持数据同步才行,如果这都不支持,讲双活和多活,就是特么的扯淡。...一个合理的建设节奏应该是,同城双活—异地双活—两地三中心(同城双活+异地多活),因为你要解决的问题的复杂度和难度也是在逐步上升的,不可能一蹴而就。

2.8K40

云上架构设计与方案

五、数据备级的方案 对于以上的方案,投入的代价较大,例如需要支付双活数据中心的高速通道费用、相同配置的云主机费用。...该方案实际是企业用得较多的形式,就算业务没有恢复,但数据还在我自己的机房中有备份。 业内的实际方案较多,有基于硬件的备一体机,也有纯软件实现的方案。...1、例如下图,本地通过备一体机进行数据的压缩、加密、存储,同时在云端也进行一份备存储。这样当业务系统中断时,可以选择在云端恢复、或线下私有云恢复。 ?...2、例如下图,也可以通过纯软件的方式进行备,直接将备份的文件放下云端、或线下私有云。 ? 这两种方式本质上都是文件级的方案,因此对于数据库等高可靠性的业务支撑不如日志级的数据同步方案。...六、小结 1、如果中型企业、资金预算较充足,可以选择双AZ方案、或线上+线下的双活高可用方案。 2、对于金融级客户,可以选择两地三中心的方案。 3、对于普通企业客户,可以选择数据级的方案

4.9K10

前端网站-CDN主域重试方案

方案 一个网站的前端资源最主要的是 : HTML JS CSS IMG ......保证网站的整体访问, 可从这几种资源进行,HTML 通常都是放在主域上, 做服务端渲染或者异步渲染,通过主域名访问获得 HTML 内容,所以不对 HTML 进行考虑。...至于 IMG, 由于现在用模板、jsx 形式,如 react 通过 img 组件的形式,对 img 的考虑通过用组件的维度来进行,而将 CDN 域请求失败的资源重新向主域请求,想到的就是利用资源标签...JS 的执行顺序,需要做两件事: 判断资源是否加载失败,通过代码执行顺序来定 当代码执行判定资源请求失败,就在资源标签的位置后方插入对应的主域请求,达到保证代码按顺序执行 以上,形成了对 JS 主域重试方案如下...前端网站为了考虑性能等,会对 JS 进行一个拆包,对部分 JS 逻辑做一个动态的懒加载,这部分动态的 JS 依赖于 JS 执行过程中动态插入,而不是直接在静态 HTML 中,如何对其进行 业务中会有对部分

1.4K10

Kubernetes 解决方案的关键能力

Kubernetes 解决方案关键能力 title.png 我们面临着不断地需要实施和部署新的软件应用、发展新的商业模式、以及吸引新的客户。...对于Kubernetes上的应用,我们需要一个可靠的恢复方案。 根据451 Research的报告,对于关键性应用来说,57%的应用要求RPO<1小时,48%要求RTO<1小时。...即使是非关键应用,也有恢复的需求。这对已经满负荷工作的IT团队来说都是较大的压力。 在这样的情况下,企业的IT团队,需要为诸多企业级应用交付强健的恢复方案。...Kubernetes解决方案,不仅需要操作简单方便,而且需要对容器化应用的技术细节进行有效感知。因此,一个为Kubernetes原生构建的、简单、易用、方便的恢复方案变得更加重要。...通过保护应用、应用的配置、以及应用的数据,Portworx提供了真正的Kubernetes原生恢复解决方案

2.1K00

,双活、多活、同城、异地、多云,到底应该怎么选?

冷备或者主备并不是一个理想的方案,而且绝大多数情况下,只能是一个心理安慰,真正发生故障的情况下,这样的模式根本起不到作用。 原因我就不重复了,大家如果有兴趣可以直接看那篇文章。...最近,公有云又出了些大故障,各大群和朋友圈又开始沸沸扬扬,但是整体看下来,声音无非两种: 单站点不靠谱,要有,出现这种情况就得马上切,所以回去赶紧建设站点; 鸡蛋不能放在一个篮子里,单云不靠谱,...既然要双活,必然会选择另一个跟当前机房有一定距离的机房(同城或异地),而且距离必须得拉开才有意义,如果都在一个园区里面,就没有任何意义了。...我们可以得出的几个结论: 不管怎么选择方案,我们自己的业务系统,从自身架构上,一定要支持单元化,一定要支持数据同步才行,如果这都不支持,讲双活和多活,就是特么的扯淡。...一个合理的建设节奏应该是,同城双活—异地双活—两地三中心(同城双活+异地多活),因为你要解决的问题的复杂度和难度也是在逐步上升的,不可能一蹴而就。

2.7K30

系列(四)——业务应用层建设

综上所述,本文从云平台视角出发阐述应用层业务建设,主要分为方案设计考虑纬度、复杂度以及云上客户案例三个方面。 1.应用概述 1.1 应用部署 应用是否满足跨地域/可用区部署?...应用层调用链是否能接受跨区延时,如果业务无法接受跨区,该业务做只能set化部署,这里需要强大中间件团队开发数据同步系统。...应用层调用链能接受跨区延时,一般以试点业务先观察,小步迭代方式逐步构建能力。...切换强依赖于调度系统以及配置系统稳定性。这里稳定性主要包括系统能力和性能;遇到大规模故障,大量信息配置变更请求调度系统和配置系统要能扛住洪峰,是保障这个方案的根基。...2.应用复杂度 计算应用层,主要考虑以下两个方面: 哪些节点执行任务。 这里要区分清楚哪些节点执行核心业务,这里会引入不同的复杂度。

3.1K72
领券