2017 年 1 月 31 日晚上，GitLab.com 运维人员在深夜进行数据库维护时，由于疲劳操作失误，使用 rm -rf 命令错误地删除了约300GB的生产环境数据。在意识到错误并尝试恢复时，只有 4.5GB 的数据得以保留。GitLab.com 官方在 2 月 1 日凌晨 1 点左右完成了数据恢复，网站恢复正常访问。恢复过程中使用的是故障发生前 6 个小时的备份数据，因此在这 6 个小时内的数据丢失。尽管 GitLab.com 声称拥有五重备份机制，包括常规备份、自动同步、LVM 快照、Azure 备份和 S3 备份，但在这次事件中，所有备份均未能有效防止数据丢失。

2023 年 10 月 23 日，语雀服务出现了一次重大故障，中断时间超过 7 小时。具体来说，这次故障的起因是在执行系统升级操作期间，新的运维升级工具出现了 bug，导致华东地区生产环境的存储服务器被误下线。由于存储系统使用的机器类别过于陈旧，无法直接将其上线，这导致了恢复过程时间延长。尽管语雀的工程师们立刻进行了恢复工作，但由于数据量大，恢复方案有限，恢复过程耗时 4 小时，数据检验耗时耗时 2 小时。

在这些个案例中我们看到了什么问题？

备份不可用，恢复方案有限，恢复备份数据长，数据丢失等等，有点平时说起来很强大很完善，真有大事就扛不住了。

所以，今天聊聊备份，不局限于数据备份。

作为一名从业多年的老兵，我们深知备份的重要性，它事关系统的安全、业务的连续性和数据的完整性，可以说是任何系统不可或缺的一部分。

行业内有一句话：「备份不做，日子甭过」

1 为什么需要备份

我们为什么需要去做备份呢？主要有以下几点原因:

1.保证数据安全：在信息时代，数据已经成为企业和个人最宝贵的资产之一。而各种硬件故障、人为错误、网络攻击、自然灾害等都可能导致数据丢失或损坏。定期备份数据，可以最大限度地降低数据丢失的风险，即使遇到问题，也可以从备份中恢复数据，将损失降到最低。

2.防范风险，确保业务连续性：对于企业来说，IT 系统的可用性直接关系到业务的正常运转。一旦关键系统发生故障，没有可用的备份，就可能导致业务中断，带来巨大的经济损失和声誉影响。而有了完善的备份和灾备机制，即使发生故障，也可以快速恢复系统，确保业务连续性。

3.满足合规性要求：在某些行业，比如金融、医疗、政府部门等，由于涉及敏感数据和关键业务，往往有严格的合规性要求，需要有完善的备份存档机制。定期备份数据、留存备份一定时间都是合规性的硬性规定。没有备份，可能面临违规处罚的风险。

4.提高竞争力：在当今数字化时代，数据已经成为企业的核心竞争力。拥有完善的备份和容灾能力，意味着企业能够更好地保护和利用数据，从数据中提炼价值，增强市场竞争力。同时，这种能力也能提升客户信任，赢得更多业务机会。比如信息产品安全等级资格认证三级认证需要：本地备份与恢复+异地数据实时备份+本地业务高可用

2 备份什么

看到备份这个词，马上能想到的就是数据备份，数据库备份这些，这些固然重要，但如果你作为一个企业的技术负责人所考虑的备份就不仅仅是这些了，以下是常见的需要备份的内容。

2.1 业务数据

业务数据是备份的重中之重。

对企业来说，最需要备份的就是各种业务数据：

1. 数据库：销售数据、客户数据、财务数据……这些数据通常存储在 Oracle、MySQL 等数据库中，是企业的核心资产，必须优先备份。如果用的是云数据库，云数据库虽然有一定的冗余，但我们仍需有自己备份数据逻辑。
2. 文件数据：合同、报表、设计图、多媒体素材等形式多样的非结构化数据，也包含了大量的业务信息，切不可轻视。
3. 应用数据：ERP、CRM、OA 等业务系统中的数据，与业务流程紧密相关，也需要专门备份。

2.2 系统数据

系统数据是保证业务连续性的关键

除了业务数据，我们还要备份各种系统层面的数据：

1. 操作系统：Windows、Linux 的系统盘，包含了服务器的重要配置，一定要定期备份，特别有一些特殊的配置，最好是有一个内部的 DevOps 系统来承接。
2. 虚拟机：很多业务系统部署在虚拟机上，备份整个虚拟机可以实现快速恢复，如果用的是云服务，境像的备份是一个标准操作。

2.3 配置数据

配置数据是还原系统的关键

系统的各种配置也需要备份，主要包括:

1. 应用配置：各个业务系统的配置参数，如果丢失，恢复系统将非常困难。如果应用配置是存储在一个配置信息中，那就需要对这个系统做备份，包括上面的数据备份。
2. 网络配置：交换机、路由器、防火墙等网络设备的配置，对维持业务连续性至关重要。
3. 安全配置：防病毒、访问控制等安全系统的配置，攸关企业信息安全。

2.4 代码、文档和日志

代码、文档和日志主要是对研发团队来说的，对于软件企业或开发部门，代码和文档是核心资产，日志是问题定位，监控审计的利器：

1. 源代码：软件的生命线，必须做好版本管理和备份。
2. 开发文档：需求、设计、接口等文档，是沟通和维护的基础。
3. 日志：系统和应用的各种日志数据，虽然不直接服务于业务，但对问题定位和事后审计很有价值
   1. 系统日志：记录了系统的运行状况和重大事件。
   2. 应用日志：反映了业务系统的运转细节和潜在问题。
   3. 审计日志：涉及敏感操作和数据访问，对合规和安全审计非常重要。

2.5 第三方服务

我们很多应用会调用第三方提供的服务，如支付、短信、社交登录、地图等。虽然这些服务由第三方负责运维，但作为调用方，我们也需要做一些防范:

• 服务冗余：对于关键服务，不要依赖单一供应商，要有备选方案。比如支付可以同时接入支付宝和微信支付，短信可以同时使用两家供应商等。这样即使一家出问题，也可以快速切换。
• 数据备份：有些第三方服务可能会存储我们的业务数据，比如客服系统中的客户对话记录。这部分数据最好在自己的系统中也保留一份，定期从第三方服务同步，这样即使第三方服务数据丢失，我们也不会受太大影响。
• 接口契约：和第三方服务的调用要有明确的接口契约，包括接口规范、SLA等。这些内容要备份保存，一旦第三方服务变更接口或者停止服务，我们可以据此追究责任。
• 替代预案：要评估每个第三方服务的可替代性，制定替代预案。一旦服务长时间不可用，我们要能够快速启动替代方案，比如临时切换到备用供应商，或者使用本地降级方案等。

除此之外，对于调用第三方服务的 API 密钥、账号密码等敏感信息，要安全备份，防止丢失。

以上就是企业需要备份的主要内容。当然，具体到每个企业，还要根据自身业务特点和 IT 架构来定制备份方案。我们需要全面梳理数据资产，评估数据的重要性和变更频率，搭建分层的备份体系。

3 如何备份

3.1 备份的 3-2-1 原则

在备份领域，有一个著名的 3-2-1 原则，包括:

• 至少保留 3 个副本
• 使用 2 种不同的存储介质
• 将 1 个副本存放在异地

这个原则看似简单，却涵盖了备份的关键要点:

• 多副本可以应对副本损坏的风险，是冗余的基本保证;
• 多介质可规避单一介质故障的影响，比如同时使用磁盘和磁带;
• 异地存放可以防范本地灾难，是灾备的必要手段。

在实践中，我们要根据数据的重要性和预算，灵活采用 3-2-1 原则。比如增加副本数量、类型，利用多个异地机房，甚至上云备份等。

3.2 备份的分类和技术

备份主要可以分为几类:

1. 完全备份与增量备份

   1. 完全备份每次对整个数据集做一个完整的备份，优点是恢复简单，缺点是备份时间长、空间占用大
   2. 增量备份则是在上一次完全备份的基础上，只备份变化的数据，备份时间短，空间利用率高，但恢复时需要依次应用所有的增量包，略显复杂。
2. 物理备份与逻辑备份

   1. 物理备份在底层复制数据文件，对文件系统/磁盘做快照，优点是简单高效，缺点是与平台/格式绑定，缺乏可读性。
   2. 逻辑备份是从上层应用备份数据，比如 SQL dump，优点是与存储解耦，可读性好，易于编辑和跨平台迁移，缺点是备份恢复速度慢。
3. 冷备份、温备份与热备份：这主要是指备份过程对业务的影响程度。

   1. 冷备份需要暂停业务，关闭数据库，确保数据一致性，适用于允许一定业务中断窗口的场景。
   2. 温备份是在业务运行中备份，会有一定的性能影响，需要控制备份速度和资源占用。
   3. 热备份可以实时同步备份，几乎不影响业务，但实现起来最复杂，对软硬件要求也最高。

除了上述分类，备份领域还有很多技术手段，比如:

• 复制：全量复制、增量复制、双向复制等
• 连续数据保护 CDP：通过记录数据修改日志来连续备份
• 去重：备份时过滤重复数据，节省存储空间
• 压缩：减小备份的体积，传输和存储更高效

3.3 灾备预案与流程

除了备份技术本身，做好灾备还需要全局的规划。我们要制定完善的灾备预案与流程，主要包含:

1. 灾备需求与目标设定：不同的系统有不同的可用性要求，核心系统当然需要更高的可用性。我们要评估每个系统的重要性，制定恰当的灾备目标，权衡投入产出。常见的指标有 RTO(恢复目标时间)和 RPO(恢复点目标)，前者是最大恢复时长，后者是允许丢失的最大数据量。指标设定要务实，太低达不到，太高又成本太大。

2. 编写灾备预案文档：灾备预案文档需要明确定义灾难等级、各种场景下的应急流程、通知上报机制、系统恢复步骤、人员角色分工、联系方式等各个细节。使得整个应急响应有章可循，文档要定期评审和更新。

3. 灾备演练与测试：光有预案还不行，必须落到实处。要定期组织演练，模拟各种场景，让团队熟悉灾备流程。比如模拟机房断电、网络中断等场景，检查应急预案的可行性，评估 RTO、RPO 的达成情况。演练中发现的问题要及时修正预案或改进系统。

4. 灾备监控和验证：除了演练，平时也要做好灾备系统的监控，确保灾备系统是随时可用的。比如监控备份的成功率、备份存储的容量使用率等，一旦发现异常要立即处理。

此外，我们还要定期做数据恢复验证，确保备份的数据确实是可用的。俗话说「备份是无用的，恢复才是关键」，定期做恢复测试是验证备份有效性的重要手段。

3.4 云灾备和异地多活

随着云计算的兴起，灾备也有了新的手段。很多公有云平台提供了灾备和备份服务，比如 AWS 的 S3、Glacier，阿里云的 HBR、OSS 等。将备份放到云上是个不错的选择，一是降低了本地存储的投入，二是借助了云的地理分布优势，备份天然就是多地域的。

此外，云平台还提供了跨可用区、跨地域的数据复制功能，以及多活架构支持。利用这些服务，可以打造「异地多活」的架构，也就是在多个地理位置部署服务，互为备份，同时对外提供服务。这样即便一个数据中心发生灾难，其他活跃的数据中心也可以无缝接管服务，实现了很高的可用性。当然，异地多活对技术水平要求极高，网络延迟、数据一致性都是不小的挑战。

4 备份的小结

总结来说，可以分为如下的几个点：

1. 全面规划：灾备不是某个部分的事，而是一个系统工程，需要全局统筹规划。
2. 分级备份：根据数据重要性分级备份，核心数据要更频繁备份，也要留存更长时间。
3. 自动化：备份和恢复要尽可能自动化，减少人工操作可能带来的错误。
4. 实时监控：对备份全程监控，确保备份连续性和及时发现问题。
5. 定期演练：演练不可少，且要尽可能模拟真实场景，检验预案的有效性。
6. 云灾备：合理利用云服务，可以显著提升灾备水平，但切忌过度依赖。
7. 专人负责：安排专人负责灾备，统筹协调，并持续优化灾备体系。

备份灾备是一个复杂的课题，需要持续的投入和改进。做好灾备，并不一定能避免所有灾难，但可以最大限度地降低损失。它不是锦上添花，而是雪中送炭。对个人、对企业而言，灾备都是系统安全、可靠的基石，是我们必须重视、持之以恒去做好的功课。

备份之路，道阻且长。

以上