IE阶段内容：BCManager eBackup 备份、Rainbow 迁移、BCManager eReplication 容灾、FusionStorage 分布式存储、HCS 私有云。

1. 备份eBackup

1.1. 备份容灾概述

1.1.1. 理解快照备份和容灾

对于比如银行、证券、电信、移动、直播、游戏、电商等这些行业。365*24小时不间断运行。必须保证业务连续性

灾备包含两个概念

备份：数据被删除、物理介质损坏。人为删除数据，磁盘损坏，都会导致数据丢失。

备份又是容灾的第一个等级。所以有必要好好了解下备份。

容灾：比如有两个数据中心，一旦一个出了问题，另一个可以继续对外提供服务。

备份：解决的是数据完整性问题；删了123，有备份，就可以还原恢复出来123。数据完整性。

容灾：解决的是业务连续性问题。一个数据中心出问题了，另一个可以顶上去对外继续提供服务，业务连续性。

不管你是备份还是容灾，只要你删除了业务数据，都会对业务造成影响。

假如删数据，通过备份来还原。

假如数据中心出问题，通过容灾来对外提供业务。

快照：snapshot

逻辑错误：人为/故意/非故意的/主动的/被动的删除了某些数据，人为了不小心把数据更新错误了等。

物理错误：磁盘损坏/主板损坏等等

快照：它保存的是逻辑数据（元数据/索引数据），指向底层的数据块。因此它解决的是逻辑错误。比如不小心删除了某个文件，可以直接还原快照来还原这个文件。但快照无法解决物理错误。

备份：分为逻辑备份和物理备份。逻辑备份保存的逻辑数据，物理备份保存的是块数据。既可以解决逻辑错误，又可以解决物理错误。比如Oracle exp/imp expdp/impdp数据泵导入导出，都属于逻辑备份；RMAN属于物理备份。

容灾：容灾是一种架构，不是技术的实现。不解决逻辑错误，解决的是物理错误。

1.1.2. 为什么备份

FC虚拟化：虚拟机

虚拟机快照。假如整个数据存储挂掉了，快照是无法解决的。只能使用备份。

RAID、快照、备份、容灾架构

为了保证数据的安全。无论如何，备份必须要有。

需要定期备份（物理备份）

备份数据库 oracle .dbf 数据文件 .ctl 控制文件 .log 日志文件等，还可以备份行数据，表结构 业务数据

备份数据 .doc .pdf .xsl

备份虚拟机 整机 虚拟机某个磁盘，无法实现针对磁盘里面的某个文件，或者某个文件里面的内容进行备份

1.1.3. 主流备份软件

赛门铁克

BE backup exec 用于windows备份

NBU 用户linux/Unix备份

华为为了出国门，就和赛门铁克成立了“华赛”，在成都（成都研究所）。现在被华为收购。

和3com 合作叫“华三”

和commvault公司合作产品simpana

这些产品可以备份所有的东西，备份文件、业务数据等都可以。

华为ebackup，全称 BCManager eBackup（只能备份虚拟机或虚拟机磁盘）

比较尴尬的是，华为超融合（一体机）里面使用的备份软件，使用爱数备份。

爱数 备份虚拟机

VMware veeam 专门备份虚拟机

还有一个容灾软件 eReplication，全称 BCManager eReplication（针对虚拟化/云场景做容灾的）。

UltraVR 仅仅针对虚拟化做容灾。

1.1.4. 备份策略

备份也有自己解决不了的问题：比如凌晨2点到上午10：46分的这个数据，没有备份，就会丢失。

6.6日备份的240G数据包含了之前所有的数据，但是从6.3-6.5所作的备份占用了很大的空间（对于6.6来说没有意义）。

如果每天采用全备（全量备份/完全备份），那么空间占用 870G。但真正实际有意义的只有240G，浪费了630G空间。

全备 月份/周/天 周期性的做备份

上图中的三种备份模式，第一次sunday周日备份，全部都是完全备份。

备份：全备/增备

全备：完全备份/全量备份

增备：1.累积增量备份 2.差异增量备份

1.1.5. 备份窗口

在用户正常使用业务系统不受影响的情况下，能够对业务系统中的业务数据进行备份的时间间隔，或者说用于备份的时间段。

备份窗口期=可以备份的时间长度。

例如：业务运行时间早7点到晚10点。那么可以用于备份的时间窗口为 晚10：00-早7点 9个小时。

备份窗口决定如何选择组网方案和备份策略。

1.1.6. 备份介质

光盘、磁带库、磁盘

D2T disk to tape

D2D disk to disk

D2V disk to virtual 磁盘到虚拟带库

D2V2T disk to virtual to tape

磁带库性能不是很好，拿磁盘的存储性能 + 虚拟引擎 = 虚拟带库

1.1.7. 容灾指标

RTO：recovery time objective 恢复时间目标

RPO：recovery point objective 恢复点目标

RTO：从业务宕机开始算，到业务可以正常访问为止，中间所经历的时间长度为RTO。

RTO值越小，意味着业务宕机时间越短。

表示能够容忍业务停机的最长时长。

RPO：业务宕机了，开始业务数据恢复，但最终没能把所有的数据恢复出来，丢数据。那丢了多少呢？把10丢了，这个10是从12点开始到1点内写入的。那么就意味着丢失了1个小时的数据。所以RPO=60分钟。

RPO值越小，意味着丢失的数据越少。

表示能够容忍的最大数据丢失量。

1.1.8. 灾备系统标准

灾备系统级别越高，对应的成本也就越高，数据的安装和业务的连续性也就越有保证。