一、灾备基础概念：到底什么是灾备？
各位同学好，我是老张。今天咱们聊聊灾备——这个听起来有点「重」的话题。
先问个问题：你电脑里的文件，多久备份一次？
嗯，很多人可能一年都没备份过。但企业系统不行。数据丢了，业务停了，那可不是重装系统就能解决的。
灾备，全称是「灾难备份与恢复」。说白了，就是给 IT 系统买一份「保险」。当火灾、地震、黑客攻击、甚至运维手滑删库这些破事发生时，你能在最短时间内把业务拉起来。
核心定义：灾备 = 数据备份 + 业务恢复。备份只是手段，恢复才是目的。
我在项目中遇到过不少客户，买了昂贵的存储阵列，天天做备份，结果真出事了发现恢复不了。为什么？因为从来没演练过。所以记住一句话：没有经过验证的灾备，等于没有灾备。
1.1 为什么需要灾备？
你想想看，一个电商平台宕机 1 小时，损失可能上千万。银行系统中断 10 分钟，监管罚单就来了。这不是危言耸听。
具体来说，灾备要解决这几类问题：
- 自然灾难：地震、洪水、火灾——物理机房直接没了
- 人为事故：运维误操作、恶意删除、配置错误——我见过有人把生产库当测试库 drop 掉的
- 网络攻击：勒索病毒、DDoS——这两年越来越频繁
- 硬件故障：磁盘阵列坏盘、服务器主板烧毁——概率虽小，但发生了就是 100%
我的经验：别只盯着「天灾」。实际上，80% 的灾备切换触发原因是「人祸」。所以流程自动化比硬件冗余更重要。
1.2 RPO 与 RTO：灾备的两个核心指标
做灾备，绕不开两个字母组合：RPO 和 RTO。这是衡量灾备方案好坏的「硬杠杠」。
| 指标 | 全称 | 通俗解释 | 典型值 |
|---|---|---|---|
| RPO | Recovery Point Objective | 你能容忍丢多少数据？ | 0 ~ 24 小时 |
| RTO | Recovery Time Objective | 你能容忍停多久业务？ | 分钟级 ~ 数天 |
RPO 决定了备份频率。如果 RPO 是 1 小时，那你就得每小时做一次数据同步。如果 RPO 是 0，那就得用同步复制——成本直接翻倍。
RTO 决定了恢复手段的自动化程度。RTO 要求 30 分钟，你就不能靠人工手动启停服务，必须上自动化编排。
避坑指南：我曾经见过一个项目，客户要求 RPO=0、RTO=5 分钟，但预算只够买两台服务器。这根本不现实。RPO 和 RTO 是跟钱挂钩的——指标越严，成本越高。一定要让业务部门签字确认。
1.3 灾备等级标准：SHARE 78 / Tiers
说到灾备等级，业界最经典的标准是 SHARE 78，后来演变为 Tiers 0~6 七个级别。我直接给你画了张图，一看就明白。
从 Tier 0 到 Tier 6，成本和技术复杂度是递增的。我见过大部分企业做到 Tier 4 或 Tier 5 就够用了。只有金融核心系统才需要 Tier 6。
我的建议：别一上来就追求最高等级。先评估业务重要性，再定 RPO/RTO，最后选 Tier。这叫「按需灾备」，不是「炫技灾备」。
1.4 灾备架构的核心模式
讲完等级，咱们看看实际怎么搭。常见的灾备架构就三种：
- 主备模式：一主一备，平时备机不干活。切换时手动或自动拉起。成本低，但资源利用率也低。
- 双活模式：两个站点同时提供服务，流量分担。一个挂了，另一个全扛。成本高，但对业务无感。
- 两地三中心：同城双活 + 异地灾备。最稳，也最贵。一般是银行、证券的标配。
我个人习惯，给客户做方案时优先推荐「主备 + 自动化切换」。为什么？因为双活虽然好，但网络延迟、数据一致性这些坑太多。我踩过不少，后面章节会细讲。
1.5 本章小结
好了，第一课咱们把灾备的底子打好了。记住几个关键点：
- 灾备不是备份，是「备份 + 恢复」的组合拳
- RPO 管数据丢多少，RTO 管业务停多久——这两个指标决定了方案选型
- Tier 0~6 是行业标准，别盲目追高，够用就好
- 自动化是降低 RTO 的关键，也是咱们这门课的核心