一、灾备保护的什么？
对于各行各业而言，用户数据、系统数据均是企业最核心、最重要的财富，但以下种种原因，都可能给数据带来不可逆转的损坏。只有完善的灾备方案，才能最终保障数据安全、业务连续性。随着互联网市场的蓬勃发展，及用户对数据重视程度的日益提高，据智研数据中心统计数据，灾备行业的市场规模已达百亿规模，且预计会逐年持续增长。
二、什么是灾备？
灾备是容灾和备份的简称。灾备方案=容灾方案+备份方案。
- 容灾的定义：指在相隔较远的两地（同城或者异地）建立两套或多套功能相同的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备份。这次事故发生时，所有备份全部无效！
案例分析：备份方案设计多么重要！周期性的灾难恢复演练（验证备份的有效性）多么重要！
腾讯云盘故障,致用户数据完全丢失 腾讯称该故障缘起于因磁盘静默错误导致的单副本数据错误，再加上腾讯运维人员在数据迁移过程中的两次不规范的操作，导致云盘的三副本安全机制失效，并最终导致数据完整性受损。
案例分析：安全管理机制
微盟运维删库走人，连灾备服务器都没放过！通过个人VPN登入公司内网跳转机，因个人精神、生活等原因对微盟线上生产环境进行了恶意的破坏。因为连灾备服务器上的数据也删除了
“数据安全保障计划”分析
吃一堑长一智，记忆惨痛，微盟恐怕会记一辈子了。来分析一下微盟公布的“数据安全保障计划”，三个重点：
1）安全管理机制建设； ——这个是造成这次破坏如此严重的根本，也是互联网企业的通病，人员少，问题多，遇到问题只想着向前冲，核心人员的权限制约并不在考虑范围内，或者是想到了，但是觉得不会发生；
2）加强灾备体系建设； ——关键词：同城双活，本地备份、异地灾备；通用的容灾备份建设，这里微盟没有公布自己的灾备体系建设目标RTO/RPO，我觉得再次遇到同样的问题，业务可能不会像这次这样停摆这么长时间，但是这套灾备体系能使RTO降到多低，我觉得RTO不会太低，你觉得呢？
3）全面上云； ——腾讯云这次可能虚惊一场，在问题发生之初，大家都在质疑在腾讯云上为什么会发生删库这种事情，业务修复、恢复时间为什么会这么长时间？其实发生问题的核心业务并没有完全上云。但是全面上云是否能够解决所有问题？是不是最优的解决办法？是不是适用于所有的客户？
“数据安全保障计划”之我见
以上“数据安全保障计划”，能不能解决问题？肯定能；是不是最优？我觉得是有空间的；
1）安全管理机制建设，我觉得没问题，百年老店、大企业都这么玩；只是要保持一个度，风险操作多次授权，使用上不要太繁琐即可，别从一个极端到另一个极端；
2）灾备建设，同城双活、本地备份、异地灾备，这些方法没有问题；但是备份所采用的方式有问题，选择的存储介质有问题；
采用云主机快照的方式进行备份，快照数据和生产主机存在一个篮子里（同一个存储），存在着公有云存储可靠性带来的很大风险；之前就发生过某公有云因为存储问题造成企业数据丢失的事件；
采用对象存储来存放非结构化数据的备份，遇到问题，大量的数据，能否快速的使用？
最好的解决办法，建议使用专业的第三方软件来做这些工作，一方面做备份，使备份数据脱离生产环境；一方面遇到问题快速恢复业务；对象存储建议只做磁带备份的替代，用于备份数据的长期存放使用，
3）全面上云；我觉得全面上云是可以的，企业成立初期，采用公有云的方式，利用公有云的灵活性，按需使用，快速的上线业务，极好的选择；但是不一定是最优的；
当前IT蓬勃发展至此，数据几乎是全部企业的生命线、尤其是互联网企业；将自己的“生命”全部交给别人，自己不握一份，真的好吗？
如此重要的数据自己不打算好好进行利用吗？比如测试、开发、甚至大数据分析，挖掘数据金矿等等