冷备份与热备份：哪种方案最适合您的系统

选择合适的备份策略通常归结为一个问题：您的业务能否在备份期间承受停机？

冷备份会关闭系统以捕获干净、一致的快照。热备份则保持系统运行，在用户继续工作的同时复制数据。本文从恢复时间、恢复点、成本和安全角度对比这两种方法，帮助您为系统匹配正确的策略。

什么是冷备份和热备份

冷备份和热备份处于同一权衡的两端：系统可用性与操作简便性。每种方法处理系统状态、文件锁定和事务一致性的方式不同，这正是指南其余部分所讨论差异的根源。

什么是冷备份

冷备份，也称为离线备份，是在数据库或应用程序完全关闭的状态下执行的。由于数据库引擎处于非活动状态，在此期间没有任何用户或进程可以读取或写入数据。系统捕获的是数据在最后稳定、非活动状态下的快照。

执行冷备份时，系统管理员通常遵循以下步骤：

1. 停止所有应用连接以防止新查询进入。
2. 完全关闭数据库管理系统。
3. 将原始数据库目录复制到安全的备份存储位置。
4. 重新启动数据库管理系统并恢复应用流量。

在此过程中，备份工具捕获所有关键系统文件，包括原始数据文件、控制文件、事务日志和配置文件。由于数据库完全离线，这些文件处于静止状态，意味着复制过程中不会有数据块发生变化。

此方法的常用工具包括手动文件复制工具，如 cp、tar 或 robocopy，用于克隆数据目录。一些管理员还会在锁定数据库以防止外部修改后，使用逻辑备份工具（如 mysqldump）。

该策略提供最高级别的数据一致性，但需要计划停机窗口，在此期间系统完全不可用。

什么是热备份

热备份，即在线备份，是在数据库持续运行且用户可访问的状态下进行的。应用不间断地读写数据，近实时地捕获变更。

由于在线备份期间数据不断变化，系统需要一种机制来防止损坏。预写式日志（WAL）或归档日志模式满足了这一需求：数据库在将每次状态变更写入实际数据库文件之前，会先将其记录到专用的顺序日志中。

热备份工具在备份窗口期间复制数据文件并持续追踪这些事务日志。

[活动数据库事务] ---> [预写式日志（WAL）/ 归档日志]
                                                    |
[备份工具复制数据文件] <----------------+ （应用日志以确保一致性）

有几种专门的工具可以在不锁定用户访问的情况下处理此过程，包括 Percona XtraBackup、MySQL Enterprise Backup（mysqlbackup）和 Oracle Recovery Manager（RMAN）。这些工具并发读取数据块和事务日志。

热备份为最终用户提供零停机体验，但需要更高的 CPU 和磁盘 I/O 资源，同时需要仔细验证日志配置。

冷备份与热备份——逐项对比

为了评估哪种方法适合您的业务，我们可以从性能、成本和可用性三个维度进行并排比较。

上述每个参数在灾难恢复体系中都扮演着关键角色。以下章节详细说明这些权衡在生产环境中的实际表现。

系统可用性

系统可用性指备份操作期间数据库是否仍对用户可访问。这是冷备份与热备份对比中最显著的差异之一。

• 冷备份：冷备份需要完全关闭数据库，这意味着备份过程中所有读写操作都必须停止。在操作完成之前，用户无法访问系统。
• 热备份：热备份允许数据库在备份运行期间保持在线。用户可以继续访问应用，不会中断。

冷备份需要计划停机，而热备份支持系统持续可用。

数据一致性

数据一致性关注备份是否捕获了数据库在特定时间点的有效且可恢复的状态。

• 冷备份：数据库文件在磁盘上保持冻结状态，没有活跃写入，消除了部分事务或脏块。
• 热备份：依赖预写式日志或归档日志来协调备份运行期间发生的变更。正确配置下同样可靠，但引入了一种冷备份没有的故障模式。

如果冷备份任务中途失败，您只需从干净状态重新开始。如果热备份与日志流的连接中断，可能导致数据文件和日志记录不匹配，在恢复时完全无法使用。

性能影响

性能影响描述备份操作如何影响生产工作负载和系统资源。

• 冷备份：对生产硬件几乎零影响，因为系统已离线，复制过程独占存储和内存访问。
• 热备份：与实时流量竞争磁盘 I/O、CPU 和网络带宽，消耗 IOPS，在存储已接近容量时可能降低响应速度。

恢复速度

恢复速度包含两个层面：恢复过程的运行速度，以及您能恢复到多接近故障时刻的状态。

• 冷备份：无需日志回放即可立即恢复，但只能恢复到备份执行时的确切时间点。凌晨备份、下午2点发生勒索软件攻击，意味着损失一整天的交易数据。
• 热备份：通过保持数据库处于归档日志模式，支持时间点恢复。重做日志可将数据库前滚到故障前的特定时间点，将数据丢失从数小时缩减至数分钟。

冷备份从干净文件恢复更快，但丢失自上次备份窗口以来的所有数据。热备份通过日志回放恢复耗时更长，但可恢复到几乎精确的故障时刻。

成本与基础设施

成本与基础设施关注存储费用和运维复杂度两个方面。

• 冷备份：使用更简单的工具和更廉价的存储层，无需依赖高额许可的代理或高性能备份目标。冷备份可直接面向更便宜的存储层，利用低成本存储进行长期保留。
• 热备份：在存储和许可方面成本更高，但若一小时的停机成本超过层级间的价格差，则其投入是值得的。

冷备份通常运营成本更低，而热备份可降低停机成本。

安全态势

安全态势评估备份过程暴露于威胁的程度。

• 冷备份：由于系统离线，与实时威胁隔离，复制过程中免受活跃勒索软件、电涌或意外覆盖的影响。
• 热备份：暴露于实时系统上发生的任何情况。如果备份作业运行时勒索软件正在加密数据，备份可能捕获已加密的文件。

无论采用哪种方法，结合不可变存储都能增加额外的保护层，因为一旦写入，备份文件即被阻止修改或删除。

何时使用冷备份和热备份：RPO/RTO 对比

恢复时间目标（RTO）衡量故障后恢复系统的速度要求。恢复点目标（RPO）衡量业务可承受的数据最大保留时间，这决定了备份频率。

冷备份自然导致较高的 RTO 和 RPO。由于仅在系统离线时捕获快照，RPO 与计划停机的频率相匹配。如果每周执行一次冷备份，潜在数据丢失可达七天。

热备份支持更积极的 RTO 和 RPO。它们捕获实时变更，使您能够恢复到故障的确切时刻，将潜在数据丢失缩减至数分钟或数秒。

为简化选择过程，组织根据对数据丢失和停机的容忍度将应用划分为不同层级。

• 第一层：任务关键型系统。此类包括支付网关、活跃电商数据库和电子健康记录（EHR）系统。这些系统要求 RTO 低于 15 分钟、RPO 低于 1 分钟。它们依赖热备份来捕获事务流并实现即时恢复。
• 第二层：重要内部系统。此层涵盖客户关系管理（CRM）数据库、内部文件共享服务器和非面向客户的 Web 应用。这些系统的目标 RTO 为 1 至 4 小时，RPO 为 12 至 24 小时。在非高峰时段安排每日热备份通常可满足这些目标，无需持续日志传输的开销。
• 第三层：非关键系统与归档。此类别包括历史报表数据库、预发布环境和遗留文件系统。这些系统可容忍 RTO 为 24 至 72 小时，RPO 为数天。冷备份因其简单性和低基础设施成本而最适合此场景。

核心要点：根据系统能够承受的损失来匹配备份方法，而非相反。热备份保护无法容忍停机或数据丢失的系统；冷备份以极低成本保护其他所有系统。

可以同时使用冷备份和热备份吗？

评估这两种方案后往往会得出一个共识：您不一定非依赖其中一种备份方法。冷热备份结合的混合策略在企业环境中被广泛采用。

实践中结合冷备份与热备份

例如，可在整个工作周内运行热备份以支持持续业务运营。在低流量维护窗口期间，可执行冷备份以创建干净、高度一致的基线。这种组合有助于保持较低的恢复点目标，同时确保可靠的备选方案。

与现代备份标准的一致性

这种混合模式也符合现代数据保护最佳实践，包括 3-2-1 备份策略，该策略强调冗余、隔离和恢复验证，以提高抵御数据丢失和勒索软件威胁的能力。

分层备份架构

实施此方法通常需要分层备份架构。近期备份存储在高性能系统上以支持快速恢复，而较旧的备份逐步移至低成本归档存储进行长期保留。

成本与效率平衡

这种分层策略帮助组织平衡性能、成本和合规要求，确保关键恢复数据保持立即可访问，同时历史数据得到高效保存。

使用 i2Backup 规模化自动化冷备份与热备份

工作日运行热备份、周末执行干净冷备份、配合生命周期策略将老化数据迁移至更廉价存储——在纸面上是合理的策略。但在不断增长的环境中，使用独立的调度工具和手动日志跟踪来协调这三者，通常会让团队开始寻找集中化平台。

i2Backup 专为在一个控制台内管理这种混合策略而设计，无需为每种备份类型拼凑不同的工具。

关键特性

• 覆盖两种方法的调度：i2Backup 允许您从单一控制台按小时、每日、每周、每月或每年配置备份计划，因此热备份可在工作周内运行，冷备份可安排在周末窗口，无需切换工具。
• 持续重做日志捕获：对于数据库工作负载，i2Backup 持续捕获重做日志和归档日志变更，支持近零 RPO 和时间点恢复，适用于无法承受丢失超过几分钟数据的系统。
• 匹配分层策略的存储：备份可写入本地磁盘、NAS、磁带库、去重存储或对象存储，支持可自定义的保留策略，在备份老化时自动清理——同样的热到冷模式可保持存储成本可控。
• 不可变、加密备份：WORM 合规存储使备份一旦写入即不可变，AES/SM4 加密保护传输中的数据，满足防勒索策略（如 3-2-1）所要求的气隙或不可变副本。

如果您的环境中包含即使丢失几分钟数据也代价高昂的系统，i2CDP 可进一步扩展此能力。它在字节级别实时复制变更数据，可将 RPO 降至秒级或零。对于需要数秒内故障转移而非从备份恢复的第一层系统，这完全是另一项任务，由高可用复制来处理，例如

i2Availability，它可在无需人工干预的情况下自动将生产切换至备用服务器。备份和高可用解决不同的问题，大多数任务关键型环境最终会同时运行两者。

无论您的系统属于第一层、第三层还是介于两者之间，目标始终如一：根据您能承受的损失来匹配备份方法，让平台在后台处理调度、日志记录和存储分层。

结论

冷备份与热备份并非针对同一问题的竞争性答案。它们回答的是两个不同的问题：您的业务能承受多少停机时间，以及它能够承受多少数据丢失。

大多数环境不需要二选一而放弃另一个。每周一次针对归档的冷备份、针对事务密集型系统的每小时热备份，以及将两者结合在一起的清晰保留策略，通常比单独任一种方法覆盖更广。

首先将您的系统映射到上述 RTO 和 RPO 层级。一旦明确，像英方软件的 i2Backup 这样的平台就可以处理两种方法的调度和分层，使策略不再依赖于有人记得手动执行。