处在IT互联网行业，我对腾讯云盘故障事件的关注度很高，已经连续在公众号推送两篇文章解析磁盘静默错误，云盘备份机制、安全备份方法等，但是依然有朋友在问
“我们公司的系统在腾讯云上，会不会有事啊？”
“我的备份做的对不对啊，会不会有问题？”
“腾讯云都挂了，阿里云是不是也会挂？”早上起来，室友(某司行政)一脸朦胧的对我说:“ 我们公司上云了，不会丢数据吧？”
至此，我觉得有必要再专门写一篇关于云灾备的文章，让大家更好的了解了云上灾备的机制，对自身灾备结构有更清晰、更客观的认识。
一、灾备保护的什么？
对于各行各业而言，用户数据、系统数据均是企业最核心、最重要的财富，但以下种种原因，都可能给数据带来不可逆转的损坏。只有完善的灾备方案，才能最终保障数据安全、业务连续性。
image.png
随着互联网市场的蓬勃发展，及用户对数据重视程度的日益提高，据智研数据中心统计数据，灾备行业的市场规模已达百亿规模，且预计会逐年持续增长。
fig_02
二、什么是灾备？
灾备是容灾和备份的简称。灾备方案=容灾方案+备份方案。
- 容灾的定义：指在相隔较远的两地（同城或者异地）建立两套或多套功能相同的IT系统，互相之间可以进行健康状态监视和功能切换。当一处系统因意外（天灾、人祸）停止工作时，整个应用系统可以切换到另一处，使得该系统功能可以继续正常工作。侧重数据同步和系统持续可用。
- 备份的定义：指用户为应用系统产生的重要数据（或者原有的重要数据信息）制作一份或者多份拷贝，以增强数据的安全。侧重数据的备份和保存。
三、灾备的两个关键技术指标
RTO：RecoveryTime Object，恢复时间目标。指灾难发生后，从IT系统宕机导致业务停顿之刻开始，到IT系统恢复至可以支持各部门运作，业务恢复运营之时，此两点之间的时间段称为RTO。
RTO是反映业务恢复及时性的指标，体现了企业能容忍的IT系统最长恢复时间。设目标RTO值设定的越小，代表对容灾系统的恢复能力要求越强，但企业投资也越高。
RPO：Recovery Point Object，恢复点目标。指灾难发生后，容灾系统进行数据恢复，恢复得来的数据所对应的时间点称为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、结合公共云同城灾备和异地灾备
如：两地三中心，
七、分析几起严重的数据丢失事故
炉石传说故障
2017年1月18日，由网易代理的暴雪旗下卡牌类游戏《炉石传说》遭遇了重大故障，从1月17日凌晨1点开始开始维护，直到1月18日下午18点才完成。
而更为可怕的是，《炉石传说》的数据并没有恢复，备份数据库也出现了故障，因此这款游戏的玩家被迫回档到1月14日15点20分。
案例分析：高可用没做好，导致实际RTO很长；
数据备份方案设计不完善，应充分考虑同机房不同机器+异地备份等方式，避免备库一起损坏。
Gitlab数据库被删除
2017年2月1日，GitLab 一位身处荷兰的疲惫系统管理员在进行数据库复制过程中不小心在一台错误的服务器上删除了一个目录，他删除了一个包含 300GB 实时产品数据的文件夹，在取消 rm -rf 删除命令后该文件夹只剩下 4.5GB 数据。并且最近的数据还是在6小时前备份的。
GitLab.com号称有五重备份机制：常规备份（24小时做一次）、自动同步、LVM快照（24小时做一次）、Azure备份（只对 NFS 启用，对数据库无效）、S3备份。这次事故发生时，所有备份全部无效！
案例分析：备份方案设计多么重要！周期性的灾难恢复演练（验证备份的有效性）多么重要！
腾讯云盘故障,致用户数据完全丢失
腾讯称该故障缘起于因磁盘静默错误导致的单副本数据错误，再加上腾讯运维人员在数据迁移过程中的两次不规范的操作，导致云盘的三副本安全机制失效，并最终导致数据完整性受损。
案例分析：单一的数据备份方式可能造成不可逆转的损失；多种备份方式结合使用，可最大概率的降低风险。
