一、灾备保护的什么？对于各行各业而言，用户数据、系统数据均是企业最核心、最重要的财富，但以下种种原因，都可能给数据带来不可逆转的损坏。只有完善的灾备方案，才能最终保障数据安全、业务连续性。随着互联网市场的蓬勃发展，及用户对数据重视程度的日益提高，据智研数据中心统计数据，灾备行业的市场规模已达百亿规模，且预计会逐年持续增长。二、什么是灾备？灾备是容灾和备份的简称。灾备方案=容灾方案+备份方案。容灾的定义：指在相隔较远的两地（同城或者异地）建立两套或多套功能相同的IT系统，互相之间可以进行健康状态监视和功能切换。当一处系统因意外（天灾、人祸）停止工作时，整个应用系统可以切换到另一处，使得该系统功能可以继续正常工作。侧重数据同步和系统持续可用。备份的定义：指用户为应用系统产生的重要数据（或者原有的重要数据信息）制作一份或者多份拷贝，以增强数据的安全。侧重数据的备份和保存。三、灾备的两个关键技术指标RTO：RecoveryTimeObject，恢复时间目标。指灾难发生后，从IT系统宕机导致业务停顿之刻开始，到IT系统恢复至可以支持各部门运作，业务恢复运营之时，此两点之间的时间段称为RTO。RTO是反映业务恢复及时性的指标，体现了企业能容忍的IT系统最长恢复时间。设目标RTO值设定的越小，代表对容灾系统的恢复能力要求越强，但企业投资也越高。RPO：RecoveryPointObject，恢复点目标。指灾难发生后，容灾系统进行数据恢复，恢复得来的数据所对应的时间点称为RPO。RPO是反映数据丢失量的指标，体现了企业能容忍的最大数据丢失量的指标。目标RPO值设定的越小，代表企业允许的数据丢失越少，企业损失越小。设计灾备方案的核心是：帮助客户平衡RTO/RPO的需求和客户经济能力，找到最佳的实现技术和手段，适合的才是最好的。四、备份的分类分类方式分类按照备份内容操作系统备份、数据备份按照备份数据量全量备份、增量备份、差异备份按照备份形式（主要针对数据库）物理备份、逻辑备份按照备份时数据库是否启动（主要针对数据库）冷备份、热备份按照备份介质磁带备份、磁盘备份为了大家更轻松的理解这些分类，下面我详细解释下冷备、热备，增量备份和差异备份的差异：分类优点缺点冷备将数据以隔离的方式来保存，备份数据不受原数据的影响；解决了硬件故障、人为误操作。数据恢复慢热备（又称冗余)搭建冗余的环境，数据完全一致;恢复速度快，瞬间恢复。只能解决硬件故障，不能解决人为误操作分类定义全量备份备份所有数据增量备份针对上一次备份所作的增量备份（上一次的备份可以是全备，可以是增备）差异备份针对上一次的全备份所做的增量备份五、云产品的灾备特性以下讲解以阿里云为例，其他云平台会有些许不同，大家可自行查阅官方文档。ECS备份备份类型灾备级别云磁盘三副本数据备份解决底层硬件级别的故障，防范单点故障快照/镜像解决误操作，网络攻击等人为故障引起的数据损坏SLB容灾（高可用）SLB负载均衡灾备分类灾备级别单可用区+单可用区SLB是集群级别的灾备，防范了单点故障；不具备机房级别的灾备能力和跨地域（城市）级别的容灾能力。多可用区ECS+主备可用区SLB（是单个实例）集群级别的灾备+机房级别的灾备,防范了单个机房断电等意外灾难；不具备跨地域（城市）级别的灾备能力多区域+跨地域多SLB实例+智能解析结合云解析（全球负载均衡版），实现多线路智能解析和跨地域容灾。RDS容灾（高可用）RDS数据库灾备分类灾备级别高可用版+单可用区集群级别的灾备，防范了单点故障高可用版+多可用区集群级别的灾备+机房级别的灾备，防范了单个机房断电、火灾等意外灾难高可用版+灾备实例集群级别的容灾+机房级别的容灾+跨地域（城市）级别的容灾数据库（含RDS)备份数据库备份分类备份方式优缺点传统冷备本地备份：将备份集拷贝到本机其他盘、其他机器；异地容灾：用户在其他地区自行搭建备份机房。本地备份：无法抵御地震、台风等自然灾害；异地备份：前期投入很大阿里云DBS冷备同城：DBS地域和备份源数据库相同；异地：DBS地域和备份源数据库不同可按量付费成本低；可将本地IDC数据库、其他云数据库、ECS自建数据库和RDS数据库备份到OSS；异地备份更简单六、几种常见的灾备架构1、用云搭建异地容灾中心本地物理机房为主数据中心，仅将数据备份到云端。2、基于公共云的同城灾备将全部系统迁移上云，并部署在同一个地域的两个不同可用区中，实现系统的同城灾备。3、基于公共云的异地灾备将全部系统迁移上云，并部署在两个不同的地域中，实现跨地域灾备。4、结合公共云同城灾备和异地灾备如：两地三中心，七、分析几起严重的数据丢失事故炉石传说故障年1月18日，由网易代理的暴雪旗下卡牌类游戏《炉石传说》遭遇了重大故障，从1月17日凌晨1点开始开始维护，直到1月18日下午18点才完成。而更为可怕的是，《炉石传说》的数据并没有恢复，备份数据库也出现了故障，因此这款游戏的玩家被迫回档到1月14日15点20分。案例分析：高可用没做好，导致实际RTO很长；数据备份方案设计不完善，应充分考虑同机房不同机器+异地备份等方式，避免备库一起损坏。Gitlab数据库被删除年2月1日，GitLab一位身处荷兰的疲惫系统管理员在进行数据库复制过程中不小心在一台错误的服务器上删除了一个目录，他删除了一个包含GB实时产品数据的文件夹，在取消rm-rf删除命令后该文件夹只剩下4.5GB数据。并且最近的数据还是在6小时前备份的。GitLab.

转载请注明:http://www.aideyishus.com/lkjg/6802.html