物理/逻辑备份与 WAL

• 物理备份的定义
• 各物理备份工具
• 一致性保证

物理备份直接复制数据库的数据文件（物理文件），而非导出逻辑数据。方式：文件系统级快照（LVM/ZFS/Btrfs 快照，或云平台快照）在文件系统层复制整个数据目录，需保证快照的一致性（frozen/checkpoint）；pg_basebackup 是 PostgreSQL 的物理备份工具，生成基础备份（base backup），配合 WAL 归档实现恢复；Percona XtraBackup 是 MySQL 的物理备份工具，在线热备（不阻塞写），通过复制数据文件 + redo log 保证一致性。物理备份恢复快（直接拷贝文件）、粒度大（整个库），但跨平台/跨版本可移植性差。相比逻辑备份，物理备份适合大库、快速恢复。

物理备份的核心是"直接拷贝数据文件 + 保证一致性"。pg_basebackup 用 WAL 保证一致，XtraBackup 用 redo log 在线热备，文件系统快照依赖快照一致性。物理备份恢复快、粒度大，适合大库。

• 逻辑备份 vs 物理备份
• 粒度、可移植性、恢复速度
• 选型依据

逻辑备份导出逻辑 SQL/数据（如 pg_dump、mysqldump），可移植性好（可跨版本、跨平台、跨数据库导入），粒度细（可备份单表、单 schema），但恢复速度慢（需逐条执行 SQL 重建索引），适合小库、异构迁移、单表导出。物理备份复制数据文件，恢复速度快（直接拷贝文件），粒度大（整库/表空间），但可移植性差（依赖版本、平台、文件系统），适合大库、快速恢复。取舍：正常备份建议物理备份（快、恢复快），逻辑备份作为补充或用于迁移/细粒度恢复。生产大库通常物理备份为主，逻辑备份为辅。

二者取舍本质上"速度 vs 灵活性"。物理备份快但依赖环境，逻辑备份灵活但慢。实践中大库用物理备份保障恢复，逻辑备份用于迁移与细粒度场景。

• 逻辑备份的实现机制
• 一致性快照
• 两工具的差异

pg_dump 与 mysqldump 都是逻辑备份工具，导出逻辑数据（SQL/数据），但实现有差异。pg_dump 利用 PostgreSQL 的 MVCC 一致性快照（导出时基于某个快照，导出的数据一致），支持并行导出（--jobs），不阻塞读写；mysqldump 默认导出时可能不一致，需配合 --single-transaction（InnoDB 用 MVCC 快照实现一致性）或 --lock-tables/--master-data（FTWRL 全局锁）保证一致。pg_dump 一致性更强（默认 MVCC 快照），mysqldump 需显式指定选项。两者都导出逻辑结构 + 数据，可选择性导表，但恢复慢。pg_dumpall 用于导出全局对象（角色、表空间）。

两者差异核心是"一致性保证方式"。pg_dump 默认 MVCC 快照一致，mysqldump 需 --single-transaction（InnoDB）或 FTWRL 才能一致。理解一致性选项是安全使用逻辑备份的关键。

• binlog 增量备份
• ROW/STATEMENT/MIXED 格式
• 格式对增量备份的影响

MySQL 基于 binlog 的增量备份：全量备份 + 定期归档 binlog，恢复时用全量备份 + 回放 binlog 实现增量/时间点恢复。binlog 格式决定记录内容：ROW 格式记录每行变更的前后镜像（精确但体积大，支持闪回），STATEMENT 格式记录 SQL 语句（体积小但依赖上下文、不确定函数可能不一致），MIXED 格式对大多数语句用 STATEMENT、对不确定语句自动用 ROW（折中）。对增量备份与 CDC，ROW 格式最精确（记录实际变更），是推荐格式；STATEMENT 无法精确反映行级变化，CDC/闪回不可用。增量备份恢复时间 = 全量恢复 + binlog 回放时间。

binlog 格式决定增量备份的精确度。ROW 记录行级变更，是最精确、支持闪回/CDC 的格式；STATEMENT 体积小但不精确。生产增量备份建议 ROW 格式。

• WAL 归档增量备份
• archive_command 机制
• pg_receivewal 流式归档

PostgreSQL 基于 WAL 的增量备份：全量基础备份（base backup）+ 归档 WAL 文件，恢复时用 base backup + 回放 WAL 实现增量/时间点恢复。WAL 归档有两种方式：archive_command（在 wal_level=replica 或 logical 下，把每个已切换的 WAL segment 通过 shell 命令归档到存储，如 cp %p /backup/%f）和 pg_receivewal（流式接收 WAL，从主库实时拉取 WAL 到本地文件，不依赖服务器端 shell，更可靠、延迟低，适合高可用与近实时备份）。archive_command 是"推"模式（服务器推），pg_receivewal 是"拉"模式（客户端拉）。两者都可实现 WAL 归档，pg_receivewal 更现代。

WAL 增量备份的核心是"base backup + WAL 归档"。archive_command 是服务器推 WAL，pg_receivewal 是客户端流式拉取。pg_receivewal 更可靠、延迟低，适合现代架构。

• 全量备份的定义
• 完整数据快照
• 全量备份的频率

全量备份（Full Backup）是对整个数据库或指定对象做完整数据快照，包含所有数据文件/所有数据的备份，是恢复的基础。实现方式：物理全量（pg_basebackup、XtraBackup、文件系统快照）复制整个数据目录；逻辑全量（pg_dump、mysqldump）导出所有数据。完整数据快照指备份时刻数据库的完整、一致状态。全量备份频率通常较低（每日/每周），因为耗时长、占用空间大，配合增量备份（WAL/binlog）覆盖两次全量之间的数据变更。全量备份是恢复的"基线"，增量备份叠加其上。

全量备份提供恢复起点（基线），增量备份覆盖后续变更。全量频率低、空间大、耗时久，是"完整快照"的本质。恢复速度和 RPO 由全量频率与增量叠加决定。

• 增量备份的定义
• 基于 WAL/binlog 的增量
• 增量备份的恢复

增量备份只备份两次备份之间的变更数据，减少数据量与时间。基于 WAL（PostgreSQL）的增量：归档全量备份之后产生的 WAL segment，恢复时回放 WAL 到目标点；基于 binlog（MySQL）的增量：归档全量备份之后的 binlog，恢复时回放 binlog。增量备份的粒度是"日志文件"，恢复 = 全量 + 回放增量日志。增量备份速度快、占用小，但恢复时要回放较长日志，且链条依赖全量。相比差异备份，增量基于上次全量（或上次增量）的逐段日志，粒度更细。增量备份配合定期全量（如每日全量 + 每阶段增量）实现低 RPO。

增量备份的本质是"备份日志变更而非数据本身"。WAL/binlog 记录所有变更，回放即可恢复。增量减少备份窗口，但恢复需回放日志，RPO 与 RTO 需权衡。

• 差异备份的定义
• 基于上次全量的增量
• 与增量备份的差异

差异备份（Differential Backup）备份"自上次全量备份以来"的所有变更数据，每次差异备份都基于同一个全量基线，累积记录全量之后的全部变更。恢复时只需"全量 + 最后一次差异备份"，恢复简单。与增量备份（只备份上次备份后的变更，可能是一连串增量）相比，差异备份恢复更快（只需一个全量 + 一个差异），但每次差异备份体积随距离上次全量的时间增长而增大。选型：差异备份恢复简单但存储增长，增量备份存储小但恢复复杂。通常"全量 + 差异/增量 + 日志归档"组合。

差异备份的关键是"累积自上次全量的所有变更"。恢复=全量+最后一个差异，简单快速；代价是差异备份体积随全量间隔增长。理解差异 vs 增量是备份策略设计基础。

• binlog 增量备份原理
• 全量 + binlog 恢复
• binlog 格式与保存

MySQL binlog 增量备份基于 binlog：先做全量备份（如 XtraBackup 或 mysqldump），然后持续归档 binlog 文件（通过定时拷贝、binlog 服务器或云备份）。恢复时用全量备份恢复基线，再回放 binlog 到目标时间点，实现增量/时间点恢复。binlog 需用 ROW 格式（精确记录变更）并定期归档、清理（防止磁盘满）。binlog 增量备份的 RPO 取决于 binlog 归档频率（基本实时）。binlog 也可用于 CDC（如 Canal）。增量备份的关键是"全量 + binlog 连续归档"，保证任何时间点可恢复。

binlog 增量备份是"全量基线 + 连续 binlog 归档"的组合。归档频率决定 RPO，binlog 格式决定精确度。binlog 是 MySQL 增量恢复与 CDC 的基石。

• WAL 增量备份原理
• base backup + WAL 归档
• 恢复流程

PostgreSQL WAL 增量备份由"基础备份（base backup）+ WAL 归档"组成。先做基础备份（pg_basebackup 或物理复制），备份时刻的数据库状态作为基线；同时开启 WAL 归档（archive_mode + archive_command 或 pg_receivewal），持续归档基础备份之后的 WAL 文件。恢复时，用 base backup 还原基线，再回放 WAL 到目标时间点（PITR），实现增量/时间点恢复。WAL 增量备份是 PostgreSQL 标准恢复方案，配合 recovery.signal 进入恢复模式。WAL 归档的连续性决定 RPO，回放速度决定 RTO。WAL 也支持流式复制与逻辑解码。

PostgreSQL WAL 增量备份是"base backup + WAL 归档 + 回放"的标准模型。WAL 记录所有变更，回放即可恢复。这是 PG 增量恢复与 PITR 的基石。

• binlog 的复制作用
• binlog 的恢复作用
• binlog 的 CDC 作用

MySQL Binlog（二进制日志）记录数据库的变更操作，主要作用：复制（主库把 binlog 推送给从库，从库回放实现主从复制）、恢复（归档 binlog 配合全量备份实现增量恢复与 PITR，误删可回放）、CDC（解析 binlog 捕获变更事件，驱动数据同步、缓存更新、数据仓库，如 Canal、Debezium）。binlog 用 ROW 格式记录行级变更，是精确的变更流。binlog 是 MySQL 的高可用、容灾、数据集成的基础。三种作用都以"binlog 记录变更"为前提，格式与保留策略需相应设计。

binlog 的三大作用（复制、恢复、CDC）都源于"它记录所有变更"。复制是主从基石，恢复是容灾手段，CDC 是数据集成桥梁。理解 binlog 就能理解 MySQL 的可靠性与集成体系。

• WAL 的崩溃恢复作用
• WAL 的复制作用
• WAL 的 PITR 作用

PostgreSQL WAL（预写日志）在数据变更写入数据文件之前先写入 WAL，作用：崩溃恢复（崩溃后靠 WAL 重放未持久化的变更，保证持久性与一致性）、复制（主库把 WAL 流式发送给从库，从库回放实现流式复制，保证一致性）、PITR（归档 WAL 配合 base backup 实现时间点恢复）。WAL 的"先写日志再写数据"保证崩溃时数据可恢复。WAL 是 PostgreSQL 的持久性、高可用与容灾的核心。WAL 级别（minimal/replica/logical）决定记录内容，影响复制与逻辑解码能力。

WAL 的"先写后改"是崩溃恢复的关键，流式复制与 PITR 都依赖 WAL。WAL 是 PG 可靠性的基石。WAL 级别决定功能范围，minimal 不满足复制/PITR。

• InnoDB redo log 的作用
• redo log 的实现机制
• 与 binlog 的区别

InnoDB Redo Log 是 MySQL 的预写日志，记录数据页的物理变更（redo），用于崩溃恢复：数据变更先写 redo log，再刷到数据文件，崩溃后靠 redo log 重放未刷盘的变更，保证持久性。实现：redo log 是循环写入的固定大小文件（或 redo log 组），通过 buffer pool 的脏页与 checkpoint 机制管理，checkpoint 时把已刷入数据文件的 LSN 之前的 redo 覆盖。redo log 与 binlog 不同：redo 是 InnoDB 层的物理日志（记录页变更），binlog 是服务层逻辑日志（记录语句/行变更），redo 用于崩溃恢复，binlog 用于复制/恢复/CDC。两者配合保证崩溃一致性与主从一致。

redo log 是 InnoDB 崩溃恢复的基石，物理记录页变更，循环写入。理解 redo 与 binlog 的分工（物理恢复 vs 逻辑记录）是理解 InnoDB 持久性的关键。

• WAL（物理）vs Binlog（逻辑）
• 记录内容的差异
• 各自用途

WAL（Write-Ahead Log）与 Binlog 是物理日志与逻辑日志的典型代表。WAL（如 PostgreSQL WAL、InnoDB redo log）记录物理层变更（数据页的修改、LSN、页镜像），与存储引擎/数据页布局相关，用于崩溃恢复（重放未刷盘的变更）与物理复制；Binlog（MySQL）记录逻辑层变更（SQL 语句或行级变更），与物理存储无关，可移植，用于逻辑复制、增量恢复、PITR、CDC。物理日志更底层、恢复快但依赖存储；逻辑日志更上层、可移植、便于解析但与引擎耦合弱。WAL 与 binlog 的差异本质是"物理 vs 逻辑"的记录粒度与用途分工。

物理 vs 逻辑是日志的核心差异。物理日志（WAL）用于崩溃恢复与物理复制，逻辑日志（binlog）用于逻辑复制与数据集成。理解这个差异是理解日志体系的前提。

• 各数据库日志实现
• 物理 vs 逻辑日志
• 兼容性差异

各数据库的日志实现不同：PostgreSQL 用 WAL（物理预写日志，记录页变更，用于崩溃恢复、流式复制、PITR）；MySQL 用 InnoDB redo log（物理，崩溃恢复）+ binlog（逻辑，复制/恢复/CDC）双层；Oracle 用 redo log（物理，重做）+ undo（回滚）；SQL Server 用 transaction log（物理/逻辑结合，记录事务与页）。由于实现差异（物理布局、格式、LSN 机制），这些日志互不兼容，无法跨数据库直接使用（如 PG 的 WAL 不能用于 MySQL）。兼容性层面：逻辑日志（binlog、WAL 逻辑解码）相对可移植，可用于跨库数据同步（CDC），但物理日志强绑定特定引擎。理解差异有助于跨库迁移与日志选型。

各数据库日志都是"记录变更用于恢复/复制"，但物理 vs 逻辑、格式、机制不同，物理日志不兼容。逻辑日志/CD 可跨库，物理日志绑引擎。这是跨库迁移的约束。

• checkpoint 频率与恢复时间
• WAL segment size 的影响
• 恢复时间优化

崩溃恢复时间与 checkpoint 频率、WAL segment size 相关。checkpoint 越频繁，崩溃后需要重放的 WAL 越少，恢复时间越短；checkpoint 越少，恢复时要重放大量 WAL，恢复时间越长（但 checkpoint 本身有开销，频繁 checkpoint 会影响性能）。WAL segment size（如 PG 的 16MB）影响 WAL 文件数量与归档粒度，segment size 越大，单个文件包含日志越多，但恢复时间主要取决于"需重放的日志量"而非 segment 大小。恢复时间 = 重放崩溃点到 checkpoint 之间的 WAL 所需时间。优化：合理设置 checkpoint 间隔（平衡性能与恢复时间）、控制 WAL 与脏页积累、监控 checkpoint 与恢复时间。

恢复时间正比于"崩溃点到最近 checkpoint 的 WAL 量"。checkpoint 频率降低恢复时间但增加开销，需权衡。理解 checkpoint 与恢复时间的关系是容量与运维设计的重要部分。

• 三种 WAL 级别
• 级别的功能范围
• 级别对复制/解码的影响

PostgreSQL 的 wal_level 决定 WAL 记录的内容，分三级：minimal（最小内容，仅记录崩溃恢复所需信息，不额外记录，用于初始化/单机，性能最优但无法流式复制/归档/逻辑解码）；replica（默认，在 minimal 基础上多记录 WAL 用于流式复制、归档（PITR）、standby 查询，是生产主备的常用级别）；logical（在 replica 基础上增加逻辑解码所需信息，支持逻辑复制、CDC、逻辑订阅）。级别越高，WAL 记录越多、开销越大，但功能越全。生产如果需要复制或 PITR 至少用 replica，需要逻辑复制/CDC 用 logical。

wal_level 是"WAL 记录内容"的开关，决定支持的功能。minimal 只能崩溃恢复，replica 支持复制/PITR，logical 支持逻辑解码。级别越高功能越全但开销越大。

• page LSN 的概念
• dirty page 刷盘机制
• 协调机制

在 InnoDB 等数据库，每个数据页有 LSN（Log Sequence Number，日志序号），记录该页最后一次修改对应的 redo 位置。buffer pool 中的脏页（dirty page）指被修改但未刷盘的数据页，页面上的 LSN 决定了该页需要重放哪段 redo 才能恢复。协调机制：将 redo 记录与脏页 LSN 关联，checkpoint 时记录一个 checkpoint LSN，flush 时把 LSN 小于 checkpoint 的脏页刷到数据文件，并更新 checkpoint 位置；崩溃恢复时，从 checkpoint LSN 开始重放 redo，把 LSN 大于数据文件页 LSN 的变更应用（即"页面 LSN 落后于 redo 的页需要重放"）。通过 LSN 比对，DB 知道哪些页需要从 redo 恢复，避免重复应用已刷盘的变更。flush 策略（如 adaptive flush、双 write）与 LSN 协调保证崩溃一致。

LSN 是"日志与数据页对齐"的坐标。脏页 LSN 与 redo LSN 比对决定恢复范围，checkpoint 推进刷盘进度。理解 LSN 协调是理解崩溃恢复与刷盘机制的核心。

• log sequence（LSN/WAL 位置）
• 流式复制原理
• 从库的同步推进

在主从复制（streaming replication）中，log sequence（如 PostgreSQL 的 WAL 位置/LSN、MySQL binlog 的 position）作为"复制进度"的坐标。主库把每个 WAL segment（或 binlog event）连同其位置发送给从库，从库记录自己已应用的 log position。从库通过 WAL 位置判断落后多少，主库通过位置判断从库确认进度。复制协议中，从库持续请求主库的新 WAL，主库按位置发送，从库回放并推进自己的位置。位置号也用于故障切换（从库应用到哪个位置）与滞后检测（Seconds_Behind_Master / pg_stat_replication 的 replay_lsn）。log sequence 是复制的"对齐锚点"，保证主从按同一顺序应用变更。

log sequence 是主从复制的进度坐标，主从通过它对齐与应用顺序。理解位置号（LSN、binlog position）是理解复制、切换与滞后检测的基础。

• torn write 问题
• doublewrite 机制
• 崩溃恢复的完整性

partial page write（torn write/半页写）指在写数据页时发生崩溃，导致数据页只写了一部分（某些块已写入、某些未写入），页面呈"撕裂"状态。由于 redo log 记录的是基于页的变更，若页本身不完整（torn），崩溃后重放 redo 无法正确恢复（因为页首尾不一致）。InnoDB 用 doublewrite（双写缓冲）解决：在刷脏页前，先把整页先写入 doublewrite buffer（一个专用的连续区域），再写数据文件；崩溃时若数据页 torn，可从 doublewrite buffer 恢复完整页，再重放 redo。doublewrite 保证"页的原子写入"，避免半页写导致的恢复错误。代价是额外一次写（I/O 开销）。

torn write 是"页写入不原子"导致的恢复难题。doublewrite 用"先写双写缓冲再写数据文件"实现页原子性，崩溃时可恢复完整页。这是 InnoDB 可靠性设计的关键。

• 各数据库日志格式
• 物理 vs 逻辑记录
• 格式差异的影响

三种日志格式差异：InnoDB redo log 记录物理页变更（以 LSN 为序，记录页号、偏移、修改内容），循环写入，物理粒度；PostgreSQL WAL 也是物理日志（记录页级变更、页的 LSN 与整页镜像），按 WAL segment 组织，支持流式复制与逻辑解码；SQL Server transaction log 记录事务级变更（物理 + 逻辑，含事务 ID、操作、页），用于崩溃恢复、复制与时间点恢复。三者都是"先写日志后写数据"，但格式不同：InnoDB/PG 侧重物理页记录，SQL Server 结合事务与页。由于格式互不兼容，各自日志不能跨库使用。格式差异体现各引擎的恢复与复制策略。

三种日志都遵循"WAL 先写"原则，但记录粒度（纯物理 vs 事务+物理）与格式不同，互不兼容。理解差异有助于理解各引擎恢复与复制机制。

• 逻辑解码的概念
• pgoutput/wal2json 插件
• CDC 应用

PostgreSQL 的逻辑解码（Logical Decoding）把 WAL 解析为逻辑变更事件（插入、更新、删除的行级变更），用于 CDC（变更数据捕获）与逻辑复制。wal_level 需设为 logical。实现通过插件：pgoutput（内置，用于逻辑复制协议，是逻辑订阅的默认输出）、wal2json（第三方插件，把变更输出为 JSON，便于外部系统消费）。CDC 场景：应用解析逻辑解码输出，把数据库变更实时同步到数据仓库、缓存、其他系统，或驱动下游业务。逻辑解码相比物理复制更上层、可消费、可跨库，是 PG 数据集成与 CDC 的核心。它对 WAL 有额外开销，且要求 WAL 保留足够长。

逻辑解码把 WAL 变成可消费的行级变更流，pgoutput/wal2json 是两种输出格式。CDC 依赖它实现变更同步。理解逻辑解码是 PG 数据集成与实时同步的基础。

• MySQL PITR 原理
• 全量 + binlog 回放
• 目标时间点定位

MySQL PITR（时间点恢复）通过"全量备份 + binlog 回放"实现：先用全量备份（XtraBackup/mysqldump）恢复基线，然后回放 binlog 到目标时间点，恢复到某一时刻的状态。过程：恢复全量备份 → 确认 binlog 起点（备份时记录的 binlog position）→ 回放该起点之后的 binlog 到目标时间（--start-datetime/--stop-datetime 或位置）→ 到达目标点停止。binlog 需为 ROW 格式并连续归档。PITR 用于误删/误更新恢复、恢复到特定时间点。实现上可用 binlog 回放工具（mysqlbinlog）或云备份。恢复时间是"全量还原 + binlog 回放"之和。

MySQL PITR = 全量基线 + binlog 回放到目标点。关键在于 binlog 的连续性与起点定位。理解 PITR 是容灾与误删恢复的核心。

• 目标时间定位
• 时间戳 vs 位置
• 精确定位技巧

PITR 的目标时间（Target Time）需要精确定位，以便恢复到目标时刻。定位方式：时间戳（--stop-datetime / recovery_target_time）指定恢复到的具体时间；日志位置（--stop-position / LSN）指定精确到日志位置；也可用事务 ID（recovery_target_xid）。精确定位技巧：先确定误删/误操作的时间点，然后回放到该时间点之前（或目标事务之前）；若目标点发生在事务中间，需回放到目标事务前（避免把目标事务也包含进来）。PostgreSQL 可用 recovery_target_time 配合 recovery_target_action 处理。为精确定位，可先回放到目标时间附近，核对数据后再调整。

目标时间定位是 PITR 的关键精度。时间戳是最直观，位置/XID 更精确。精确定位需结合误删时间点并注意事务边界，避免恢复过头或不足。

• PITR 的定义
• 恢复原理
• 应用场景

PITR（Point-in-Time Recovery，时间点恢复）指把数据库恢复到过去某个特定时间点（或日志位置）的状态，而不是只恢复到最近一次备份。原理：用全量备份（base backup）恢复基线，再回放归档日志（WAL/binlog）到目标时间点，覆盖目标时间之前的所有变更。这样可从备份点之后任意时刻恢复，用于误删、误更新、逻辑错误、被攻击等场景。恢复精度取决于日志连续性（WAL/binlog 归档）与目标时间定位。PITR 是容灾体系的重要能力，比"恢复到最近备份"更灵活。RPO 与日志归档频率相关。

PITR 的"任意时间点"由"全量基线 + 日志回放"实现。它比恢复最近备份更精细，能返回误操作之前。核心依赖日志归档的完整性与目标定位精度。

• base backup + WAL 归档
• recovery.signal/standby.signal
• PG 12+ 的配置方式

PostgreSQL PITR 由"base backup + WAL 归档 + 恢复模式"实现。先用 base backup（pg_basebackup）恢复基线，再用归档的 WAL 回放到目标时间点。PG 12 起用信号文件（signal files）控制恢复行为：recovery.signal 表示进入恢复模式（PITR/master 恢复），若存在则服务器以恢复模式启动并回放 WAL 到 recovery_target；standby.signal 表示进入 standby 模式（作为备机持续跟随主库）。这两个文件配合 postgresql.conf 中的 recovery_target_time 等参数实现 PITR。恢复完成后，PG 12+ 删除 recovery.signal 并进入正常模式（或按 recovery_target_action 处理）。相比旧版 recovery.conf，PG 12+ 用信号文件 + 主配置参数更清晰。

PG 12+ 用信号文件区分恢复与备机模式。recovery.signal 触发 PITR 回放，standby.signal 触发备机跟随。配合 base backup 与 WAL 归档实现 PITR。

• 误删的应急响应
• 恢复手段
• 预防措施

误删（DROP TABLE、TRUNCATE）应急流程：1) 立即停止可能产生新写入的业务（或只读），防止污染（避免新数据覆盖 binlog 位置）；2) 确认误删对象与时间，评估恢复手段；3) 用 PITR 恢复到误删前的时间点（DROP 表可用全量备份 + binlog/WAL 回放到误删前），或从备份恢复整表（若误删单表）；4) 恢复后校验数据一致性；5) 若误删只影响单表且无备份，可用 binlog 闪回（如 binlog2sql --flashback）生成回滚 SQL。预防措施：定期备份、权限管控（DROP/TRUNCATE 权限限制）、延迟从库（误删可用延迟从库找回）、操作前验证。恢复优先用 PITR 或延迟从库，避免直接对生产造成二次破坏。

误删恢复的关键是"先止血（停止写入）再恢复（PITR/备份/闪回）"。PITR 是最可靠手段，延迟从库提供快速找回窗口，binlog 闪回用于单表。预防（权限、备份、延迟从库）更重要。

• 延迟从库的配置
• 误删恢复窗口
• 延迟从库的局限

延迟从库（delayed replica）刻意让从库复制滞后于主库一段时间（如 1 小时），用于误删/误操作恢复窗口。MySQL 用 CHANGE REPLICATION SOURCE TO SOURCE_DELAY=3600（旧版 MASTER_DELAY）设置延迟；PostgreSQL 用 recovery_min_apply_delay 设置延迟应用 WAL。当主库发生误删，延迟从库还没应用该删除，可从延迟从库找回误删数据（在延迟窗口内）。局限：延迟期内从库无法用于读（数据不新鲜，读会读到旧数据）；延迟从库仍占磁盘空间（完整数据副本）；延迟时间超过则恢复窗口失效；误删发生时间超过延迟窗口就无法找回。因此延迟从库适合"预留短窗口"的误删恢复，需权衡延迟时长与读可用性。

延迟从库是"时间机器"，利用复制滞后提供恢复窗口。代价是延迟期读不可用、磁盘占用、窗口有限。它是误删恢复的补充手段，配合 PITR 使用。

• binlog 闪回原理
• 反向生成回滚 SQL
• 前提与验证

binlog 闪回工具（binlog2sql --flashback、MyFlash）把 binlog 的 ROW 事件反向解析，生成回滚 SQL。原理：binlog 的 ROW 格式记录每行变更的前后镜像（before_img/after_img），闪回工具把"删除"反转为"插入"、把"更新"反转为"反向更新"、把"插入"反转为"删除"，从而生成撤销误操作的 SQL。使用前提：binlog 必须为 ROW 格式（STATEMENT 格式无行镜像，无法闪回）；需要完整镜像（binlog_row_image=FULL，记录 before 与 after 完整值）；需有误删时间窗口内的 binlog。上线前验证流程：先在测试库执行生成的回滚 SQL，核对数据与期望一致，再在生产执行，并做好备份与风险预案。闪回是误删恢复的精细手段，但只适用于行级误操作。

闪回依赖 ROW 格式的 before/after 镜像。前提是 ROW 格式 + 完整镜像 + 有 binlog。验证流程（测试库演练再上生产）保证安全。闪回适合单表/行级误操作，全表 DROP 用 PITR。

• PITR 的性能影响
• RTO/RPO 评估
• 平衡策略

PITR 的性能影响主要来自 WAL/binlog 归档（持续 I/O 与网络）与归档日志的存储。评估要用 RTO（恢复时间目标）与 RPO（恢复点目标）：RPO 由备份频率与日志归档频率决定（全量备份之间靠日志归档，理论上 RPO 接近 0，即日志不丢则任意点可恢复）；RTO 由全量恢复速度 + 日志回放速度决定（全量越大恢复越慢，日志越长回放越久）。PITR 性能影响与 RPO 目标权衡：要低 RPO 需频繁归档日志（增加 I/O），要低 RTO 需更频繁的全量备份或更快的回放。评估时需实测全量还原速率与日志回放速率，并设定备份窗口、日志保留策略。RTO/RPO 决定备份策略的激进程度。

PITR 的 RPO 由日志归档决定（可接近 0），RTO 由全量 + 回放决定。归档频率影响性能与 RPO，全量频率影响 RTO。二者权衡是备份策略设计的核心。

• 恢复时长估算
• 并行回放（MTS、逻辑复制并行应用）
• 缩短 RTO

PITR 恢复时长 = 全量还原时间 + 日志回放时间。全量还原时间取决于实际数据量与还原速率（磁盘 I/O、网络）；日志回放时间取决于需回放的日志量与回放速率。估算可实测：全量还原速率 = 数据量/还原耗时，回放速率 = 日志量/回放耗时，两者相加即恢复时长。缩短 RTO 的关键是并行回放：MySQL 的 MTS（Multi-Threaded Slave，基于 logical clock 的并行复制）把 binlog 按事务并行应用到从库，加速回放；PostgreSQL 16+ 的逻辑复制订阅端支持并行应用大事务（max_parallel_apply_workers_per_subscription），可加速复制回放，而物理 PITR 的 WAL 重放目前仍为单进程顺序应用。并行回放利用事务间的独立性，显著加快日志回放，从而缩短 RTO。

恢复时长 = 全量 + 回放，并行回放是缩短回放的核心手段。MySQL MTS 与 PG 逻辑复制并行应用都利用并行度加速日志应用（PG 物理 WAL 重放仍为顺序应用）。估算时需实测速率并考虑并行效果。

• 备份 vs 可恢复的误区
• 日志归档的误区
• 恢复验证的误区

PITR 常见误区包括：1) 以为"有全量备份就够"——若无日志归档（WAL/binlog），无法恢复到备份点之后任意时间，只能恢复到最近备份；2) 以为"备份了就不用测试恢复"——备份未验证恢复能力，关键时刻恢复失败；3) 以为"日志归档不丢就 RPO=0"——归档本身可能中断、丢失，需监控归档连续性；4) 以为"恢复只是跑一遍流程"——恢复涉及目标时间定位、数据校验、回切，需演练；5) 以为"闪回/延迟从库能替代 PITR"——它们只是补充，不能替代完整备份体系；6) 忽略恢复时长（RTO）的实测，实际恢复超出预期。误区本质是"重备份、轻恢复验证"。

PITR 误区集中在"备份≠可恢复、日志连续性、恢复未验证"。正确做法是"备份 + 日志归档 + 定期恢复演练 + 监控归档"。恢复验证是 PITR 可靠性的关键。

• 3-2-1 原则
• 3 份副本、2 种介质、1 份异地
• 备份策略设计

3-2-1 备份原则是经典的数据保护策略：3 份数据副本（1 份生产 + 2 份备份）、2 种不同介质（如磁盘 + 磁带/云存储，避免介质故障）、1 份异地（异地存储/灾备，避免单点区域故障）。该原则提高容灾能力：单一介质故障时用另一介质，区域故障时用异地副本。落地：备份做多份（本地 + 异地），用不同存储介质，并定期验证。除 3-2-1 外，还有 3-2-1-1-0（+1 份离线/不可变副本 + 0 份恢复失败）等扩展。备份保留策略还涉及保留周期（按时间/版本），与 RPO/RTO 目标匹配。

3-2-1 原则通过"多副本、多介质、异地"提升数据安全性，抵御介质故障与区域故障。它是备份策略的基准，实际落地还要结合保留周期与恢复演练。

• 备份校验的目的
• checksum 校验
• 工具校验

备份校验用于确认备份可用、完整、一致，避免"备份存在但不可恢复"。校验手段：checksum 校验（对备份文件或数据计算校验和，验证完整性，防止传输/存储损坏）；pg_verifybackup（PostgreSQL 工具，校验 pg_basebackup 生成的备份是否完整一致，检查文件与 WAL）；xtrabackup --prepare（对 XtraBackup 备份做"预准备"，应用 redo log 使备份一致可恢复，是恢复前的必要步骤，也是校验备份可用的手段）。此外还通过恢复演练验证备份可用。备份校验应在备份后执行，并定期做恢复演练。checksum 发现损坏，pg_verifybackup 验证 PG 备份，--prepare 使 InnoDB 备份一致。

备份校验是"备份可用性"的保障。checksum 验完整性，pg_verifybackup 验 PG 结构，--prepare 使物理备份一致。校验 + 恢复演练确保备份关键时刻可恢复。

• 备份演练的必要性
• 定期恢复测试
• 演练的时机与频率

备份演练（DR Drill）指定期在测试/隔离环境执行恢复演练，验证备份可用性与恢复流程。必要性：备份存在不代表"关键时候能恢复"，未演练的备份可能在恢复时失败（文件损坏、归档不完整、流程错误、权限问题）。定期恢复测试能：验证备份完整性、恢复流程正确性、恢复时间（RTO）是否达标、演练人员熟练度。演练可验证 PITR、全量恢复、主从切换等场景。频率常为月度或季度（根据业务重要性），演练后记录结果、修复问题。备份演练是"备份体系可靠性"的最终检验，是容灾能力的关键。

备份演练把"备份可用性"从假设变为验证。未演练的备份是不可靠的。定期恢复测试发现备份/流程问题，确保关键时刻可恢复。这是 DR 的核心实践。

• 备份加密的目的
• 应用层加密 vs 文件系统加密
• 加密的取舍

备份加密保护备份数据不被泄露（备份常含敏感数据，若存储介质/异地泄露则数据泄露）。实现方式：应用层加密（pg_dump 可配合 openssl/gpg 对备份文件加密；mysqldump 可配合 gpg 加密；云备份服务自带加密），在生成备份时加密；文件系统加密（LUKS、BitLocker、云盘加密），在存储层加密所有备份文件。区别：应用层加密粒度更细（可对单个备份加密、密钥管理更灵活），但需应用支持与密钥管理；文件系统加密透明、无需改应用，但加密粒度是整个文件系统。实践中常用"应用层密钥管理 + 存储加密"组合。备份加密需管理密钥（丢失密钥则备份无法解密），并评估加密开销。

备份加密是"数据安全"的最后防线。应用层加密粒度细、文件系统加密透明。两者可组合，密钥管理是关键（密钥丢失=备份不可用）。

• 备份压缩的目的
• 各压缩算法
• 压缩率 vs 速度的取舍

备份压缩减少备份体积与存储成本。常见算法：gzip（通用、压缩率中等、速度一般，兼容性最好）；zstd（高压缩率、速度快、支持多级压缩，现代推荐，兼顾压缩率与速度）；lz4（压缩速度极快、压缩率低，适合对速度要求高、对体积不敏感的场景）。取舍：压缩率与速度呈反比——lz4 最快但体积大，zstd 在压缩率与速度间平衡最佳，gzip 兼容性最好但速度较慢。备份场景选 zstd 较多（兼顾压缩率与备份速度）；对备份速度敏感、存储充足可选 lz4；对兼容性要求高（老旧工具）选 gzip。压缩还影响 CPU 开销与备份/恢复时间。

压缩算法在"压缩率 vs 速度"间取舍。zstd 综合最优，lz4 快但率低，gzip 兼容但慢。选型取决于存储成本、备份窗口与 CPU 预算。

• 数据类型映射
• 函数/存储过程转换
• 兼容性处理

异构数据库迁移（如 Oracle→PostgreSQL、MySQL→PostgreSQL）的 Schema 转换处理：数据类型映射（SQL Server 的 VARCHAR→PG 的 VARCHAR、Oracle 的 NUMBER→PG 的 NUMERIC、MySQL 的 DATETIME→PG 的 TIMESTAMP 等，需按映射表转换并处理边界差异）；函数转换（各库内建函数不同，如 Oracle 的 NVL→PG 的 COALESCE、MySQL 的 NOW()→PG 的 now()，需重写）；存储过程/触发器转换（语法不同，如 PL/SQL→PL/pgSQL、MySQL 的存储过程语法→PG 的 PL/pgSQL，需重写并处理异常、游标、事务差异）。异构转换通常用工具（如 AWS DMS、pgloader、ora2pg）辅助 + 人工调整。转换重点是数据类型兼容、函数语义一致、存储过程逻辑与异常处理正确。

异构迁移的核心是"映射与重写"。数据类型按映射表，函数按语义等价重写，存储过程按语法重写。工具辅助 + 人工校验是常见做法，兼容性测试是保障。

• 跨平台迁移的流程
• Oracle→PostgreSQL
• MySQL→PostgreSQL

跨平台迁移（如 Oracle→PostgreSQL、MySQL→PostgreSQL）流程：1) 评估与规划（分析对象、数据量、停机窗口、兼容性）；2) Schema 转换（数据类型、函数、存储过程映射重写）；3) 数据迁移（全量导出导入 + 增量同步，可用工具如 pgloader、ora2pg、AWS DMS）；4) 应用改造（SQL 语法、驱动、连接层适配）；5) 验证与切换（对账、影子流量、灰度切换）。Oracle→PG 差异：PL/SQL→PL/pgSQL、NUMBER→NUMERIC、序列/语法、包、触发器。MySQL→PG 差异：存储引擎、AUTO_INCREMENT→SERIAL/IDENTITY、datetime/ON UPDATE、语法细节。迁移工具 + 人工适配 + 充分验证是成功关键。

跨平台迁移是"评估→转换→迁移→改造→验证"的工程。每对数据库差异不同，需针对性处理。工具辅助 + 充分测试是保障成功率的关键。

• crash-consistent snapshot
• 一致性与崩溃恢复
• 与应用一致快照的区别

crash-consistent snapshot（崩溃一致快照）指文件系统/存储层快照在"崩溃时刻"的状态是"崩溃一致"的：即快照反映的是某个瞬间的磁盘状态，可能包含部分写入（如数据库还没刷盘的数据），但文件系统层面是一致的（没有崩溃导致的损坏）。数据库恢复时，靠数据库自身的 redo/WAL 崩溃恢复机制，把 crash-consistent 快照恢复到一致状态（重放未完成的日志）。与应用一致快照（application-consistent，如 DB 冻结/checkpoint 后快照）不同，crash-consistent 快照不保证应用层一致，但利用数据库崩溃恢复机制也能恢复。因此 crash-consistent 快照可用于数据库备份，恢复时需数据库执行崩溃恢复。优点是快照快、无需停库，缺点是需要数据库恢复。

crash-consistent 快照是"存储层一致、应用层需恢复"的快照。它靠数据库自身的崩溃恢复（WAL/redo）恢复到一致状态。理解它与应用一致快照的区别是快照备份设计的关键。

• 云数据库快照
• RDS 快照机制
• 快照的恢复与限制

云数据库（AWS RDS、阿里云 RDS）提供托管快照（Snapshot）机制：基于存储层（如 EBS/云盘）的一致性快照，对数据库实例做全量/增量备份。AWS RDS 快照：可手动或自动（自动备份窗口）创建，快照是 crash-consistent 或应用一致的（RDS 会协调数据库冻结），可恢复到新实例或用于复制；阿里云 RDS 快照类似，支持自动备份与手动快照，可恢复到指定时间点（PITR 配合 binlog）。云快照特点：托管、无需自建备份；恢复快（从快照创建新实例）；成本随快照数量与增量；支持跨区域复制（灾备）。注意：快照是存储级，恢复粒度是实例级（或单库/表受限），跨版本需验证兼容。

云快照是托管的存储级备份，简单可靠，支持自动备份与 PITR。恢复为实例级，成本随快照增量。选型时考虑快照频率、保留策略与跨区域复制。

• XtraBackup 的功能
• 在线热备
• 应用场景

Percona XtraBackup 是 MySQL/Percona 的物理备份工具，支持在线热备（不阻塞业务写入）。它通过复制数据文件 + 应用 redo log 保证一致性：备份时增量复制数据文件并捕获 redo log，--prepare 阶段应用 redo 使备份一致。应用场景：全量物理备份（大库快速备份）、增量备份、配合 binlog 做 PITR、主从搭建（备份 + 恢复为从库）、快速恢复。XtraBackup 比 mysqldump 快（物理复制）、支持大库、在线不阻塞。其后 XtraBackup 8.0 支持 MySQL 8.0。它是 MySQL 物理备份的标准工具。

XtraBackup 是 MySQL 物理在线备份的标准工具，通过 redo 保证一致，适合大库、快速恢复、主从搭建。物理备份替代逻辑备份是大库场景的必然。

• DMS 的功能
• 同构/异构迁移
• 持续同步

AWS Database Migration Service（DMS）是云数据迁移服务，用于把数据库迁移到 AWS（或跨库迁移）。功能：全量迁移（一次性迁移现有数据）+ 持续同步（CDC，把源库增量变更持续同步到目标，实现近乎零停机迁移）；支持同构（MySQL→MySQL）与异构（Oracle→PostgreSQL、SQL Server→Aurora）迁移，异构时自动做 Schema 转换（利用 AWS SCT，Schema Conversion Tool）。DMS 应用场景：上云迁移、数据库引擎更换、跨区域复制、持续数据同步。DMS 减轻了迁移工具链的搭建负担，但仍需应用层适配与验证。DMS 适合云端迁移与异构转换。

DMS 是托管迁移服务，提供全量 + CDC 持续同步与异构转换。它把迁移工具链托管化，但边界是应用适配与兼容性验证仍需人工。适合上云与引擎更换。

• 数据库快照与文件系统快照协同
• frozen filesystem 一致性
• 快照一致性保证

数据库快照与文件系统快照协同指用文件系统快照（LVM/ZFS/云盘）备份数据库时，需保证快照时刻数据库一致。frozen filesystem（冻结文件系统）指在快照前暂停/冻结文件系统写入，使文件系统处于一致性状态，再创建快照，避免快照捕捉到部分写入导致不一致。协同方式：数据库配合冻结（如 MySQL 的 FLUSH TABLES WITH READ LOCK 让数据文件一致，或 PG 的 checkpoint + 一致快照点），然后冻结文件系统、创建快照、解除冻结。这样快照是"应用一致"的。若不做冻结，快照是 crash-consistent，需数据库恢复。数据库 + 文件系统快照协同能在不停库的情况下获得一致性快照。

数据库与文件系统快照协同的关键是"一致性"。frozen filesystem 冻结写入保证文件系统一致，配合数据库冻结（FTWRL/checkpoint）得到一致快照。这比纯 crash-consistent 更快恢复。

• 各文件系统快照
• 一致性保证
• 快照与数据库配合

LVM、ZFS、Btrfs 都支持文件系统快照，但一致性保证需配合。LVM 快照基于 COW（Copy-on-Write），快照是块级一致，但需在快照前冻结文件系统（或配合数据库 FTWRL）保证应用一致；ZFS 快照基于 COW，快照原子且一致，ZFS 本身保证文件系统一致，但数据库数据的一致性仍需数据库配合（如 ZFS 快照 + 数据库 checkpoint）；Btrfs 快照也基于 COW、原子，但文件系统一致不等于数据库一致。总之，文件系统快照保证"文件系统层面一致"，数据库层面需配合冻结/checkpoint 才能得到"应用一致"快照。否则快照是 crash-consistent，恢复时靠数据库 WAL/redo 恢复。文件系统快照的优点：快、成本低、容易回滚。

文件系统快照的一致性分两层：文件系统一致（COW 快照保证）与应用一致（需数据库配合）。理解这个分层是正确使用文件系统快照备份数据库的关键。crash-consistent 快照靠数据库恢复。

• --single-transaction vs FTWRL
• 大库改用物理备份
• 异构迁移与逻辑导数据

mysqldump 是逻辑备份工具，应用边界：适合小库、逻辑导数据、异构迁移、单表导出。一致性：--single-transaction（InnoDB 用 MVCC 快照，在单事务内导出，不阻塞写，但 MyISAM 表不受支持且导出期间 DDL 可能中断）保证 InnoDB 一致性；FTWRL（FLUSH TABLES WITH READ LOCK）是全局只读锁，保证所有引擎一致，但阻塞写入。大库改用物理备份（XtraBackup）因为：mysqldump 导出 SQL 慢、内存占用高、恢复慢、耗时长，物理备份直接复制文件快且恢复快。mysqldump 适用异构迁移（导出 SQL 可导入其他库）与逻辑导数据（按需导出表/数据），但大库备份应选物理备份。mysqldump 无法实现 PITR（需配合 binlog）。

mysqldump 的边界是"小库、逻辑、迁移"。--single-transaction 用 MVCC 快照，FTWRL 用全局锁，精度不同。大库因逻辑导出慢而改用物理备份。理解边界是选型关键。

• pg_basebackup 的功能
• 物理基础备份
• 应用场景

pg_basebackup 是 PostgreSQL 的物理备份工具，生成基础备份（base backup），默认在线执行（不阻塞生产读写）。功能：复制整个数据目录（含 WAL），生成一致的基础备份；配合 WAL 归档可实现 PITR 与增量恢复；也可用于搭建备库（克隆一张备机数据目录）。应用场景：定期全量物理备份、搭建流式复制从库、作为 PITR 的基线。pg_basebackup 支持 --wal-method=stream（边备份边流式 WAL 保证一致）、并行（-j）、压缩（-Z）。它是 PG 物理备份与高可用搭建的标准工具。pg_basebackup 生成的备份需结合 WAL 归档才能做时间点恢复。

pg_basebackup 是 PG 物理基础备份标准工具，在线执行、生成一致基线，用于全量备份、搭从库、PITR 基线。配合 WAL 归档实现完整恢复体系。

• pg_dump 一致性快照与并行导出
• pg_dumpall 的全局对象
• 为什么不能替代 WAL 归档

pg_dump 是逻辑备份工具，导出数据库逻辑数据（SQL），利用 MVCC 一致性快照保证导出一致（不阻塞读写），支持并行导出（--jobs 加速）、单表/单库选择导出。pg_dumpall 导出全局对象（角色、表空间、数据库级配置）。应用边界：适合小库、异构迁移、单表导出、跨版本迁移。但它不能替代 WAL 归档实现 PITR：因为 pg_dump 只导出"备份时刻"的快照，不包含后续变更；WAL 归档记录备份之后的持续变更，配合恢复才能实现时间点恢复。若只有 pg_dump 而无 WAL 归档，只能恢复到备份时刻，无法恢复到任意时间点。因此 PITR 必须依赖 base backup + WAL 归档，pg_dump 只是逻辑快照。

pg_dump 是一致性逻辑快照，无持续变更记录，不能 PITR。WAL 归档提供持续变更，才支持 PITR。理解"逻辑快照 vs 日志归档"的分工是恢复体系设计的关键。

• WAL 先写后改
• 写入路径
• 持久性保证

WAL（Write-Ahead Log）的写入路径遵循"先写日志，再写数据"：事务修改数据时，先把变更写入 WAL（并持久化 WAL），再更新数据页（buffer pool 中的页，异步刷盘）。这样崩溃时，只要 WAL 已持久化，就能靠重放 WAL 恢复，即使数据页未刷盘。因为顺序写 WAL（追加）比随机写数据页快，且 WAL 是恢复的权威记录。写入路径：事务提交→写 WAL（fsync）→标记提交→数据页随后刷盘（checkpoint/后台）。若先写数据后写日志，崩溃时数据页可能已改但 WAL 没记录，无法恢复。WAL 先写保证"日志在数据之前"，是持久性与崩溃恢复的基础。

"先写日志再写数据"是 WAL 的核心原则，保证日志是恢复的权威。顺序写 WAL 快于随机写页，且确认提交即可返回。理解写入路径是理解崩溃恢复的前提。

• recovery.conf 的移除
• 配置迁移到 postgresql.conf
• signal 文件的使用

PG 12 起移除 recovery.conf，恢复/备机配置迁移到 postgresql.conf 主配置，并用 signal 文件控制模式。具体：原先 recovery.conf 中的参数（如 restore_command、primary_conninfo、recovery_target*）现在写入 postgresql.conf（这些参数在旧版不可放主配置，现在可以）。模式由信号文件决定：存在 recovery.signal 则进入恢复模式（PITR，从归档恢复），存在 standby.signal 则进入备机模式（持续跟随主库，配合 primary_conninfo）。若两者都有，优先 standby。恢复完成后 PG 删除 recovery.signal（或按 recovery_target_action 处理）。迁移步骤：把旧 recovery.conf 参数并入 postgresql.conf，创建对应 signal 文件，重启。这样配置更统一、更清晰。

PG 12+ 把恢复参数并入 postgresql.conf，用 signal 文件区分模式。这简化了配置管理，recovery.signal 触发 PITR，standby.signal 触发备机。理解迁移是 PG 12+ 运维的基础。

• 演练频率
• 月度 vs 季度
• 演练窗口

演练频率取决于业务重要性与恢复复杂度。月度演练：对关键业务、恢复要求高、变更频繁的场景，每月一次恢复演练，及时发现备份/流程问题，保持团队熟练度；季度演练：对一般业务、变更较少、恢复要求相对低的场景，每季度一次。选择因素：数据重要性（核心业务频次高）、变更频率（变更多则演练更频繁）、成本（演练占用资源与时间）、合规要求。演练窗口选业务低峰，避免影响生产。实践上"按季度为底线、核心业务月度"是常见做法，且演练后要记录结果、修复问题、更新 Runbook。频率匹配风险：别让演练频率低于风险承受度。

演练频率是"风险 vs 成本"的权衡。核心业务月度、一般业务季度是常见基准。演练窗口选低峰，演练后复盘整改。频率过低则备份可靠性无法保障。

• RTO 实测
• RPO 实测
• 演练指标评估

备份演练的指标重点实测 RTO 与 RPO。RTO（恢复时间目标）实测：从开始恢复（或故障打卡）到系统恢复可用的时间，具体为"全量还原时间 + 日志回放时间 + 切换时间"，演练中打表记录实际耗时，与目标 RTO 对比。RPO（恢复点目标）实测：演练恢复到的数据点与故障点的时间差，即"丢失的数据量"，验证恢复点是否满足目标（如 RPO=0 是否达到，即日志是否完整回放）。演练用实测数据评估：RTO 是否达标、RPO 是否满足、恢复流程是否顺畅。若实测 RTO 超目标，需优化（更频繁全量、并行回放、更快介质）；若 RPO 不达标，需检查日志归档完整性。实测指标是演练的核心产出，驱动改进。

演练的核心是实测 RTO/RPO。RTO 测恢复耗时，RPO 测数据丢失量。实测与目标对比驱动优化。演练不是走过场，而是用数据验证容灾能力。

• Btrfs 子卷与快照
• 写时复制（COW）
• 碎片化代价

Btrfs 中快照是对子卷（subvolume）的写时复制（COW）副本。子卷是可独立管理/挂载的文件系统层级，快照共享子卷的原始数据（COW），只有当数据被修改时才复制新块。COW 的优点是快照创建快、节省空间（只存差异）。代价：碎片化——COW 导致数据块被分散写入，文件系统碎片化增加，长期读写性能下降；写放大——快照存在时，修改共享块需复制，增加写开销。权衡：快照越多、COW 引用越多，碎片化与写放大越明显；保留快照需控制数量与保留期，必要用去碎片化（defrag）或重写数据。适合数据库这类频繁写场景，需谨慎使用过多快照。

COW 快照用"共享 + 时复制"节省空间，但代价是碎片化与写放大。权衡快照数量与保留期，必要时 defrag。数据库场景需谨慎，过多快照影响写性能。

• LVM 快照 COW 原理
• 适用场景
• 快照空间耗尽管理

LVM 快照基于 COW（Copy-on-Write）：创建快照时分配一个快照区（snapshot 卷），当原卷数据被修改时，先把原块复制到快照区，再写入新数据。这样快照保存的是"创建时刻的原始数据"，修改时靠 COW 保留旧数据。适用场景：数据库/文件系统的一致性备份前快照、测试环境回滚、快速恢复。风险：快照区空间耗尽——若原卷被大量修改，快照区需要存储大量被覆盖的旧块，空间不足时快照失效（如 active 状态异常）。管理：为快照区预留足够空间（按修改量估算）、监控快照占用率、及时删除过期快照、必要时扩容快照卷。快照区耗尽会导致快照无法使用，是 LVM 快照的主要风险。

LVM 快照靠 COW 保留旧块，快照区空间取决于"修改量"而非原卷大小。空间耗尽使快照失效，需预分配、监控、及时清理。理解 COW 是管理快照风险的关键。

• ZFS 快照 COW
• 克隆与回滚
• 快照保留策略

ZFS 快照基于 COW（写时复制），创建快照时零成本（共享数据），只有数据修改时才复制新块，因此快照快、节省空间。ZFS 快照支持克隆（clone，从快照创建可写的独立数据集，共享底层数据）与回滚（rollback，把数据集恢复到快照时刻）。快照保留策略：按时间/频率保留（如每日快照保留 N 天），考虑空间与恢复需求；快照数量影响空间（虽 COW 但保留的差异块累积），需定期清理；配合发送/接收（zfs send/receive）把快照复制到异地做备份。设定保留策略要权衡：保留周期（满足 RPO/RTO）、空间成本、自动清理快照。ZFS 快照是高效的数据保护机制，适合数据库备份与快速回滚。

ZFS 快照 COW 高效，支持克隆回滚与传承。保留策略要平衡空间与恢复需求，定期清理并可用 send/receive 异地备份。它是文件系统级快照的先进方案。