备份策略：3-2-1 规则

备份策略

有弹性的备份策略是抵御数据丢失的最后一道防线，这些数据丢失可能由勒索软件、硬件故障、自然灾害、人为错误、数据损坏或摧毁生产系统的恶意攻击所导致——若没有充分的备份，一起本可通过数小时恢复即可解决的事件，可能演变为关键数据的永久丢失、长达数天或数周的停机，甚至可能导致企业倒闭。基本的 3-2-1 规则（3 份数据副本，存放于 2 种不同类型的介质，其中 1 份副本异地保存）依然有效，但需要针对现代环境进行扩展，纳入诸如用于防勒索软件保护的不可变备份（在保留期内即使管理员也无法删除或修改的备份）、定期恢复测试以验证备份在需要时确实可用（许多组织只有在紧急情况下需要备份时才发现备份已损坏）、明确定义 RPO（Recovery Point Objective——我们可承受多少数据丢失，以距上次备份的时间衡量）和 RTO（Recovery Time Objective——在系统恢复之前我们可承受多长时间的离线）、将备份凭据与主域分离以防止攻陷 Active Directory 的攻击者同时摧毁所有备份，以及通过监控和告警实现备份流程自动化以确保备份按预期进行等概念。一个常见的错误是把备份当作「set and forget」——备份需要持续的关注、验证、随着基础设施演进而更新流程，最重要的是：要有一种像重视新功能开发一样重视数据保护的组织文化。

3-2-1 规则：冗余的基础

3-2-1 规则规定，您应保留 3 份数据副本（生产 + 2 份备份），存放于 2 种不同类型的存储介质，并有 1 份副本在地理上分隔的异地保存。例如：生产数据存放于 SAN（Storage Area Network），主备份存放于同一 datacenter 内的 NAS（Network Attached Storage），辅助备份存放于不同区域的云存储（S3、Azure Blob）。介质多样性可防范特定技术的故障——如果您所有备份都在磁带上，而发现您的 tape drive 已停止工作，那么即使拥有磁带，您也可能无法恢复。异地副本可防范局部灾害（火灾、洪水、盗窃、对 datacenter 的物理攻击）——如果所有备份都在同一栋被烧毁的建筑内，您将失去一切。3-2-1 的现代演进是 3-2-1-1-0：3 份副本、2 种介质、1 份异地、1 份不可变、0 错误（通过恢复测试验证）。实施方法：配置备份软件（Veeam、Commvault、Bacula、Acronis、AWS Backup、Azure Backup）以创建关键系统的每日 snapshots，将这些备份复制到本地存储（第一份副本），将一份副本发送到云端（第二份异地副本），并使用 Object Lock（S3）或 Immutable Blobs（Azure）将云副本标记为不可变。根据以下公式计算所需存储：数据量 × 保留期 × 变更率——如果您有 10TB 数据，希望保留备份 30 天，且每天有 10% 的数据发生变更，那么您将需要约 10TB + (10TB × 0.1 × 30) = 40TB 的存储用于备份。使用去重和压缩来降低成本，但要警惕 crypto ransomware，它可能使数据看起来呈随机状态并降低 dedupe 的效率。

防勒索软件的不可变备份

现代勒索软件不仅加密生产数据，还会主动搜寻并摧毁备份，以最大化对受害者支付赎金的压力——攻击者利用被攻陷的管理凭据删除 snapshots、禁用备份服务、损坏 backup catalogs，甚至加密备份本身。不可变备份（也称为 WORM - Write Once Read Many，或 air-gapped backup）通过使备份在所定义的 retention period 内无法被删除或修改来防范这种情况，即使是拥有最高权限的管理员也无法做到。实现方式：处于 Compliance 模式的 AWS S3 Object Lock（即使是 root account 也无法在 expiration date 之前删除对象）、带有 legal hold 或 time-based retention policies 的 Azure Blob Immutable Storage、被物理移除并保存在异地 vault 中的磁带备份，以及具备 WORM mode 的 backup appliances（Dell EMC Data Domain、Cohesity）。配置适当的 retention period——通常为 30 至 90 天，具体取决于您的 RPO 以及需要保留历史版本的时长。重要：不可变性可防止删除，但无法防止创建新的已损坏备份——如果攻击者在触发勒索软件之前已攻陷系统数周，您的不可变备份可能包含已被感染的数据。解决方案：保留多个版本的备份（而不仅仅是最新的），使用可检测数据异常的 backup validation（熵的突然增加可能预示 encryption），并考虑物理「air gap」，即定期将备份复制到与网络完全断开的存储中。定期测试不可变备份的恢复，因为某些系统存在 bugs，会导致不可变性甚至阻止 legitimate restore operations。

恢复测试与验证

未经测试的备份是不可靠的备份——有无数有据可查的案例：企业多年来虔诚地进行备份，却在 disaster recovery 期间发现备份已损坏、配置有误、介质已退化，或恢复流程根本无法运作。请实施正式的 backup testing 计划：每月在测试环境中进行完整的生产恢复（full system restore），每周恢复关键 VMs/数据库（partial restore），每天验证 backup job logs（确认备份无错误地完成）。使用以下脚本实现测试自动化：在隔离环境中启动恢复、验证已恢复数据的完整性（checksums、database consistency checks）、测量恢复时间（验证您是否能满足 RTO），并生成带有指标的 reports。对于数据库，使用 DBMS 自带的 backup restore validation：SQL Server RESTORE VERIFYONLY、MySQL mysqlcheck、PostgreSQL pg_restore --list。对于应用程序备份，进行恢复并运行自动化的 smoke tests 以验证关键功能。记录每次测试：日期、测试的系统、结果（成功/失败）、耗时、发现的问题以及纠正措施。将 restore tests 的失败视为 P0 incidents——如果备份测试失败，应假定在修复之前您没有可用的备份。可考虑进行「surprise restore drills」，即在不预先通知的情况下告知团队需要在 Y 小时内恢复系统 X，以模拟真实的紧急情况。除了验证备份之外，这些 drills 还能训练团队掌握 recovery 流程，并发现文档或自动化中的 gaps。

RPO 与 RTO：定义 Recovery 目标

RPO（Recovery Point Objective）是您可承受丢失的最大数据量，以时间衡量——如果您的 RPO 为 4 小时，则您至少需要每 4 小时进行一次备份，并且在发生灾难时您可能会丢失最多 4 小时的事务。RTO（Recovery Time Objective）是系统在被恢复之前可保持离线的最长时间——如果您的 RTO 为 2 小时，则从检测到事件到系统再次投入运行，您有 2 小时的时间。RPO 和 RTO 必须由 business requirements 来定义（业务能容忍多少数据丢失和多少 downtime），并决定备份架构：关键的 tier-1 应用可能要求 RPO=0（通过同步复制实现零数据丢失）和以分钟计的 RTO（high availability cluster），tier-2 应用可以容忍 RPO=1h（每小时增量备份）和 RTO=4h，tier-3 应用可以是 RPO=24h（夜间备份）和 RTO=8h。计算成本与风险：较小的 RPO 需要更频繁的备份（更多存储、更多性能 overhead），较小的 RTO 需要更复杂的 recovery 系统（hot standby、automated failover）。不同 tiers 的架构示例：Tier-1（ERP、Payment Processing）——同步复制到 DR site + 15 分钟 snapshots + 每日不可变备份，RPO 小于 15 分钟，RTO 小于 1h；Tier-2（CRM、Email）——1h 增量备份 + 每日 full 备份，RPO=1h，RTO=4h；Tier-3（File Shares、Logs）——每日备份，RPO=24h，RTO=8h。在 Disaster Recovery Plan 中记录每个系统的 RPO/RTO，获取 business stakeholders 的 sign-off（以确保期望一致），并监控您是否能够达成所定义的目标（在事件中跟踪 actual recovery times）。

备份凭据的分离

如果 backup system 使用与同一 AD 相同的凭据，则攻陷具有 Domain Admin 权限的 Active Directory 的攻击者有可能访问并摧毁所有备份——这是勒索软件攻击中常见的攻击向量，攻击者首先在 AD 中建立 persistence，然后绘制整个备份基础设施的图谱，最终在触发 encryption 之前摧毁备份。请通过凭据隔离来缓解：为 backup infrastructure 创建一个独立的域或 standalone workgroup，在可能的情况下使用本地 service accounts 而非 domain accounts，为 backup appliances 配置独立于 AD 的自有身份验证，对 backup console 和存储的访问实施 MFA，并对云备份使用具有受限权限的 API keys 而非具有广泛访问权限的凭据。对于 Veeam 环境，实施「hardened Linux repository」，其中 backup server 为 Linux（位于 Windows AD 之外），仅可通过使用 key-based auth 的 SSH 访问，并且无法通过 Veeam console 删除备份（immutability 在 Linux filesystem 层级强制执行）。对于 AWS 备份，使用 cross-account backup vault，其中备份被发送到由另一团队以非共享凭据控制的独立 AWS account，并配置 Vault Lock 以防止删除。应用 least privilege 原则：执行备份的账户只需在生产环境中拥有 read access，在 backup destination 中拥有 write access，而无需 delete permissions。将对 backup infrastructure 的访问作为 high-value targets 来监控——任何在备份窗口之外或来自意外 IPs 的访问尝试都应生成安全告警。在极端情况下，可考虑「offline backup admin」，即备份管理凭据不以数字形式存在——它们被保存在物理 vault 中，仅在紧急情况下访问。