备份与恢复

• 合规备份的加密、留存、审计三大支柱
• HIPAA 等法规对数据保护的强制要求
• 落地路径与可审计性设计

合规备份的核心是"加密、留存、审计"三要素。加密方面，备份数据无论在传输（TLS 1.2+）还是静态存储（AES-256）都必须加密，且密钥敏感性监管要求较高，建议使用 KMS 托管密钥并支持客户管理密钥（CMK）。留存方面，备份保留周期必须满足法规要求（如 HIPAA 要求 6 年），过期的备份需加密删除或安全擦除，且删除行为本身要留痕。审计方面，所有备份制作、恢复、导出、删除操作都需要记录操作人、时间、来源 IP、操作对象，日志需防篡改（immutable）并集中留存，满足合规审查时可追溯。落地时建议：启用云厂商的加密容器与 KMS、采用不可变备份桶（WORM）防止恶意覆盖、通过 IAM 与审计日志将备份操作与身份绑定，并周期性把审计日志投递到 SIEM 或合规归档桶。

合规的关键不是"做了备份"，而是"能证明在安全、受控、可审计的前提下做了备份"。加密防止泄露，留存满足法定期限，审计闭环保证可追溯与可问责，三者缺一不可。

• 3-2-1-1 的组成要素
• 异地与不可变/离线副本的落实
• 与勒索防范的关联

3-2-1-1 策略是：至少 3 份数据副本；存放在 2 种不同的介质/存储类型上（如本地磁盘 + 对象存储）；其中 1 份副本存放在异地（跨区域），防止单点故障；最后 1 份"1"通常指不可变（immutable）、离线（air-gap）或 WORM 副本，用于抵御勒索病毒对备份的篡改与删除。落地时：生产环境为第一份；将备份写入本地存储或备份服务器（第二份）；再复制到异地/跨区域对象存储（第三份）；第四份通过对象存储的版本控制、对象锁（WORM）或磁带离线副本实现不可变。该策略同时满足灾难恢复与勒索防护两重需求。

3-2-1-1 是在传统 3-2-1 基础上的演进，新增的"1"专门针对勒索软件——攻击者常会先删除/加密备份，所以必须有一份不可变或离线的副本作为最后防线。

• 备份系统三层的职责划分
• 数据平面与控制平面的分离
• 分层设计的扩展性

企业级备份系统典型分为三层：备份代理（Agent）负责在数据源上执行具体的备份/恢复动作，采集数据、执行快照、压缩去重；调度引擎（Scheduler/Orchestrator）作为控制平面，负责备份策略管理、任务编排、依赖关系、重试与告警，并跟踪任务状态；备份存储（Storage）提供容量与介质组织，包括去重池、异地副本、对象存储等，通过目录/索引（Catalog）维护备份内容的元数据。三者通过"控制平面（调度）与数据平面（代理到存储的数据流）"分离的设计，使调度与数据流转互不阻塞、便于扩展。此外还需索引与管理层，用来统一管理备份任务、策略、保留期与恢复点目录。

分层设计让备份系统能独立扩展：新增数据源只需部署代理并注册，调度层可扩展节点支撑高并发，存储层可横向扩容并支持分层（本地/异地/云）。控制面与数据面分离也便于限流与容错。

• 三种备份类型的差异
• 恢复链长度对 RTO 的影响
• 合成全量原理

全量备份包含全部数据，单独即可恢复；增量备份只备份自上次备份（无论全量还是增量）以来的变化，恢复时需从全量开始按顺序重放所有增量，链长越长 RTO 越大；差异备份备份自上次全量以来的所有变化，恢复时只需全量+最近一次差异，链短但日常占用更大。增量链过长的代价是：单个增量文件损坏会导致其后所有备份失效，且恢复时需读取大量文件、RTO 显著增大。合成全量（synthetic full）通过把已有全量与应用增量"合成"出一个新的完整备份，无需重读生产数据，既保住了增量备份的低流量，又让恢复链始终保持在较短的全量+增量结构，显著降低 RTO 与恢复风险。

增量链的本质是"恢复所需的数据序列长度"决定 RTO。合成全量通过周期性合并生成新的全量基线，重置链长，平衡了备份流量与恢复速度，是大型备份系统中常用手段。

• 存储级快照的机制
• 与备份软件的集成
• 快照恢复的限制

基于存储快照的 SAN 备份利用存储阵列（如 SAN）的快照能力，在指定时间点对卷创建一个一致性快照，再把这个快照挂载到备份服务器或备份存储上，由备份软件读取并转存到备份介质。优势是：对生产几乎没有性能影响（无需在主机上占用大量 I/O）、可快速创建多个时间点、恢复时可直接把快照克隆/回滚成可用的卷，秒级甚至瞬时恢复。限制包括：快照通常依赖存储阵列的容量与缓存，快照不可能无限保留；快照本身不是灾备，若阵列失效则快照也丢失，需再转存到备份介质；应用一致性依赖与应用协同（如 quiesce 数据库），否则快照可能是崩溃一致而非应用一致。

存储快照备份将从"应用内备份"转移到"存储层复制"，把备份开销从主机搬到存储，从而降低对生产的影响，但代价是引入了对存储阵列的依赖，且需要额外把快照转存到异地/独立介质才能构成真正的灾备副本。

• 两种一致性的定义
• 对数据库恢复的影响
• 适用场景选择

应用一致备份在创建备份前会通过 VSS、数据库 quiesce 或 flush 等手段让应用将内存中的脏数据与事务落盘，形成一组逻辑上自洽、可被数据库直接识别为有效恢复点的数据，恢复后无需重放日志即可正常启动。崩溃一致备份则只保证文件系统层面的一致性，不保证应用内部事务的完整性，可能包含"半提交"状态，恢复时数据库需通过重放/回滚日志（redo/undo）自行修复，但若备份恰好在事务提交中途拍摄，可能丢失部分已提交事务或需人工介入。应用一致适用于数据库、事务系统等强一致性场景；崩溃一致适用于文件、对象等可容忍某些不一致的应用，或对恢复后能自动修复的数据库也可接受。生产数据库优先应用一致，文件/静态内容可用崩溃一致。

核心区别在于"是否需要应用层参与、恢复后是否直接可用"。应用一致以备份时暂停/协调应用为代价换取干净的恢复点；崩溃一致则牺牲一致性换取更简单、更快的备份流程。

• 两种密钥管理方式的差异
• 安全性与运维复杂度权衡
• 合规与审计考量

KMS 集成方式将备份加密密钥托管给云厂商的 KMS 服务，可实现密钥自动轮换、集中管理、权限与审计统一，密钥与密文分离存储，安全性高且运维简单，适合大多数云上备份场景；客户可进一步使用 CMK（客户管理密钥）实现更高自主权。自管密钥（BYOK/自管加密）则把密钥保存在本地或自建密钥库，密钥完全由企业掌控，适合对数据主权、合规要求极高（如金融、监管）或无法信任云厂商的场景，但需自行承担密钥的存储、轮换、备份与安全，一旦密钥丢失或泄露将导致数据无法解密或泄露，运维与安全风险更高。一般建议优先 KMS 集成，必要时用 CMK 增强自主性；自管密钥仅在强合规或私有云场景采用。

密钥管理本质是"安全性与运维自主性的权衡"。KMS 牺牲一定自主权换取低成本、高可靠与审计融合；自管密钥换取完全控制权但把安全责任转嫁给企业自身。密钥丢失是加密备份的灾难性风险，需配套密钥备份与恢复。

• 备份完整性校验的方法
• 自动化调度与告警
• checksum 与 restore test 的互补

备份数据完整性校验主要通过两类手段：一是校验和（checksum/hash）比对，在备份写入时计算源数据与备份文件的哈希值，在读取时重算比对，从而发现位翻转、传输损坏、介质错误；二是恢复测试（restore test），将备份恢复到临时环境并验证可启动、可查询、数据行数一致，这是最直接的"备份可用"证明。自动化上，将校验与恢复测试编排为按计划自动执行的任务（如每日 checksum、每周/每月 restore test），执行结果写入报告，失败即触发告警，并与监控平台（如 Prometheus/Nagios）集成。落地时可以在备份完成后对文件做校验和并记录，恢复测试用脚本化地拉起实例、执行数据一致性 SQL 校验、再清理。

checksum 证明"数据没坏"，restore test 证明"能恢复且可用"，两者缺一不可。很多企业"备份失败"常常不是没备份，而是恢复不出来，所以定期自动恢复测试是保障可恢复性的关键机制。

• 备份 SLO 的指标维度
• 频率、窗口与可恢复性的度量
• 与业务目标对齐

备份 SLO 通常围绕三类指标设计：一是备份频率（Frequency），决定 RPO 上限，越高可能丢失的数据越少，需与业务允许的数据丢失量对齐；二是完成窗口（Completion Window/RTO），即备份必须在指定时间内完成，避免影响后续备份或生产，也直接决定恢复速度；三是可恢复性（Recoverability），用"恢复成功率"衡量，即恢复测试通过的比例，理想接近 100%。度量时定义 SLA 指标如"每日备份成功率 ≥ 99.9%""P95 备份完成时间 ≤ 4 小时""每月恢复演练通过率 100%"，并通过监控平台持续采集与告警。保障上通过容量规划、增量/合成全量、带宽限流、去重压缩等手段满足窗口，通过定期恢复演练与完整性校验保障可恢复性。

备份 SLO 必须由业务 RPO/RTO 反推得出，而不是拍脑袋设定。频率、窗口、可恢复性三者共同刻画"备份能多大程度上兑现业务的数据保护承诺"，且可恢复性往往比频率更关键——备份做得多但恢复不出来毫无意义。

• 恢复演练频次设计
• 自动化验证手段
• 演练结果纳入治理

恢复演练频次应结合系统的重要级别与变更频率设定：核心系统（如交易库、订单库）建议每月至少一次，甚至每周进行"白盒"恢复抽检；一般系统可每季度一次；合规要求严格的场景按监管要求执行（如金融行业每年至少一次全量灾备演练）。每次重大变更（升级、迁移、配置改变）后也应补充恢复演练。自动化验证方面，利用脚本或编排平台自动拉起临时实例、恢复备份、执行数据一致性校验（行数、checksum、关键业务查询）、启动服务并验证可用性，验证通过后自动清理，全程记录结果并生成报告，失败自动告警。结果应纳入备份治理的度量（如恢复成功率），并作为持续改进的输入。

恢复演练的价值在于"把假设变成验证"。自动化让演练可持续、低成本、可重复，从而能高频执行；只有演练频率匹配系统的重要性和变更节奏，才能及时发现备份链断裂、恢复脚本失效等问题。

• 三种工具的能力差异
• 逻辑备份 vs 物理备份
• 对恢复与 PITR 的影响

mysqldump 是 MySQL 的逻辑备份工具，导出为 SQL 文本，兼容性好、便于迁移与部分恢复，但备份慢、需锁表或依赖 MVCC 一致性快照，不适合大数据量在线备份。xtrabackup 是 MySQL 的物理热备工具，基于 InnoDB 物理文件 + 日志，备份快、在线无锁、支持增量备份与恢复，是生产 MySQL 大库备份的主流选择，配合 binlog 可实现 PITR。pg_basebackup 是 PostgreSQL 的物理备份工具，直接复制数据目录，配合 WAL 归档可实现 PITR，是 PostgreSQL 在线备份的标准方式。选择原则：小库/迁移/逻辑需求用 mysqldump；MySQL 大库热备优先 xtrabackup；PostgreSQL 一律用 pg_basebackup + WAL 归档。

逻辑备份（mysqldump）灵活但慢、重放消耗大；物理备份（xtrabackup/pg_basebackup）快、恢复快，且与日志联动支持 PITR。生产环境大库普遍采用物理备份，逻辑备份用于迁移、抽数等场景。

• 传输加密与存储加密
• 密钥轮换机制
• 常见配置要点

备份加密分三个层面：传输加密确保备份数据在代理到备份存储之间传输时不被窃听，通常通过 TLS/HTTPS 连接（如 mysqldump 走 SSH、S3 用 HTTPS），并双向校验证书；存储加密确保备份数据落盘后为密文，分静态加密（如磁盘加密、S3 服务端加密 SSE-KMS）与应用层加密（如 xtrabackup --encrypt、pg_basebackup 加密、tar 加密），静态加密更多依赖存储平台，应用层加密则更彻底、密钥独立。密钥轮换方面，KMS 集成支持自动轮换（管理员配置轮换周期），应用层加密需定期更换加密密钥并妥善处理旧密钥（旧备份仍能解密，新备份用新密钥），轮换时需保证密钥的备份与恢复。配置要点：先用 TLS 加密传输链路，再启用静态加密或应用层加密，最后配置密钥轮换策略并保留密钥历史用于解密历史备份。

传输加密防"路上泄露"，存储加密防"落盘泄露"，密钥轮换防"密钥长期单一引发的泄露面扩大"。三者叠加才构成完整加密链条，且密钥管理（含历史密钥保留）是备份可解密的前提。

• 备份存储分层策略
• 容量与带宽规划
• 成本与生命周期管理

备份存储通常分三层：本地磁盘（本地/近端备份池）用于快速恢复与短期保留，容量按需配置、带宽充足、恢复快，但成本最高且不达灾备；异地副本（异地备份服务器或机房）用于跨机房容灾，RPO/RTO 由复制带宽决定，需规划足够的网络带宽并做压缩去重；云对象存储（S3/OSS）用于长期归档与合规留存，容量近乎无限、成本随存储类（热/冷/归档）递减，用生命周期策略自动降级归档。规划时：容量按"数据量 × 保留周期 × 副本数 × 去重冗余"估算；带宽按"每日增量 × 复制窗口内可用带宽"计算，避免挤占生产带宽，可设置限流；成本采用分层存储，热数据放本地、冷数据放对象存储并自动归档，平衡恢复速度与成本。

备份分层是"性能-成本-安全性"的平衡。本地保证快恢复，异地保证灾备，对象存储保证长期留存与合规，三者通过生命周期与保留策略联动，实现成本可控下的完整数据保护。

• 保留策略的要素
• 版本与过期清理
• 合规留存

备份保留策略需同时考虑版本保留、过期清理与合规留存。版本保留设定"保留多少份时间点备份"或"保留多长周期"，常见策略如"每日备份保留 7 天、每周保留 1 个月、每月保留 1 年"（多重保留/金字塔策略），兼顾近期恢复与长期回溯。过期清理指达到保留期限后自动删除过期备份，释放存储，需在备份软件/存储策略中配置保留期与自动清理任务，防止无限累积。合规留存指某些数据需按法规（如审计、金融监管要求 N 年）受限保留，不能被提前清理，且删除需审计留痕。设计时用"保留策略标签 + 生命周期管理"实现不同数据类别差异化保留，并设置"不可删除（immutable）"保护期，确保合规数据在期限内绝对安全。

保留策略是"恢复能力"与"存储成本"的平衡。版本太多浪费空间，太少则无法回溯到更早时间点；合规留存则是一票否决项，不可因成本而删减，需通过不可变与审计机制硬性保障。

• 监控指标与告警阈值
• 异常检测方法
• 超时自动重试机制

备份监控体系围绕关键指标构建：任务成功率（失败/成功比例）、任务耗时（P50/P95、是否有超时）、备份大小（与基线比是否异常，如突然变小可能数据丢失，突然变大可能异常增长）。告警策略：失败任务立即告警；耗时超过阈值（如超过历史 P95 的 2 倍）或超过完成窗口告警；备份大小与近 N 天均值偏差超过设定百分比（如 ±30%）告警，提示数据异常。超时任务自动重试：设定重试次数与退避策略（如失败后隔 5 分钟重试，最多 3 次），重试仍失败则升级为人工告警并记录；同时做幂等设计，避免重试产生重复或损坏的备份。落地可通过备份软件的告警接口 + 监控平台（Prometheus/Alertmanager）采集指标，用阈值规则或异常检测触发告警，配合事件通知（邮件/短信/IM）。

备份监控的核心是"发现异常及时干预，避免备份失败被掩盖"。成功率保障最基本可用性，耗时保障 SLO 窗口，大小异常往往是数据问题的早期信号；自动重试减少人工介入，但需配合重试上限与幂等，防止无限重试制造风暴。

• 三种防勒索机制
• 选型考量
• 落地要点

三种手段都是为了就算备份端被勒索软件入侵也无法篡改/删除备份。immutable（不可变）指备份文件在设定保留期内不可修改、不可删除，通常由对象存储的版本控制/对象锁或备份软件实现；air-gap（物理或逻辑隔离）指备份与生产网络隔离，勒索软件无法通过正常网络路径触达备份，物理隔离（磁带、离线存储）或网络隔离（独立 VLAN、路由隔离）都是 air-gap；WORM（Write Once Read Many，一次写入多次读取）是存储级别的一次写多次读保护，数据写入后不可改写，常用于合规与防篡改。选型：成本敏感且需快速恢复用 immutable 对象存储；对勒索防护要求最高用 air-gap 离线副本；合规归档场景优先 WORM。落地时建议"immutable + air-gap"组合，日常备份用 immutable 对象存储，另设一份离线/隔离副本作为最后防线，并定期验证其可恢复性。

防勒索的本质是"把备份与攻击者的可视触达面隔离"。immutable 依赖存储平台保证，air-gap 从网络路径上隔离，WORM 从存储语义上锁定，三者可组合使用，且都需配套恢复演练确认"不可变数据"确实可用。

• 恢复 SOP 的内容
• 验证清单与演练记录
• 文档的持续更新机制

标准化恢复流程通过三类文档支撑：恢复 SOP（Standard Operating Procedure）是分步骤、可执行的恢复操作手册，需明确触发条件、责任人、恢复步骤、依赖的联系方式与升级路径，并区分不同场景（单表恢复、整库恢复、PITR、跨机房灾备）；验证清单（Checklist）列出恢复后必须验证的项目，如服务启动、数据行数、关键业务查询、权限与连通性，确保恢复被"确认可用"而非"看起来恢复"；演练记录（Drill Log）记录每次演练的时间、参与人、执行步骤、遇到的问题与结论，形成可追溯的痕迹。文档更新机制：每次真实恢复或演练后复盘，修订 SOP 与清单；每次架构/配置变更后同步更新；定期（如每季度）评审文档与实操的一致性，并用演练结果反哺优化。

恢复的成败往往取决于"预案是否准确、是否按流程执行"。SOP 保证可执行性，清单保证可验证性，记录保证可追溯与持续改进，三者缺一不可，且必须随演练和变更持续更新，否则文档会成为"过时的正确"。

• 跨组件一致备份点的难点
• 协调机制（quiesce/事务协调）
• 队列与缓存的一致性处理

要获得数据库与应用（如消息队列、缓存）的一致备份点，难点在于各组件备份时刻不同，可能产生"数据库已提交但队列未处理"或"缓存已更新但数据库未持久化"的不一致。协调方法：一是通过应用级 quiesce/pause 让应用在备份窗口内暂停写入，先冻结应用，再冻结数据库并做快照，最后恢复应用，从而保证备份点一致；二是利用分布式事务/协调框架（如两阶段提交、CDC 的 offset 对齐）使数据库快照与队列 offset、缓存版本处于同一逻辑时间点；三是对采用"数据库为准、队列/缓存可重建"的架构，只需保证数据库一致，队列 offset 与缓存可在恢复后从数据库回放重建。落地时通常"先备份数据库、再记录队列消费位点与缓存状态，恢复时按数据库时间点回放队列到对应位点"。

一致备份点问题的本质是"多个组件的时间点如何对齐"。若队列/缓存可幂等重建，则可只保证数据库一致；若必须严格一致，则需 quiesce 或事务协调。设计时优先简化架构（数据库为唯一事实源）以降低协调成本。