4. 物理备份与逻辑备份的选型
在数据库备份体系中，物理备份与逻辑备份是两条最根本的技术路线。它们并非“谁更好”的关系，而是面向不同目标、不同约束的两种工具。选型的本质，是把数据库规模、恢复速度要求、跨版本迁移需求这三个核心变量，映射到备份方式的能力边界上。理解这一点，才能避免“用逻辑备份去救 TB 级库”或“用物理备份去做跨大版本迁移”这类典型误用。
一、两种备份的本质差异
物理备份直接复制数据库的物理文件——数据文件、控制文件、重做日志、归档日志等。它不关心文件内部存的是什么表、什么行，只保证这些字节被完整、一致地保存下来。因此物理备份的粒度是“整个数据库实例或表空间”，恢复时也是整块还原，速度快、保真度高。典型代表是 Oracle 的 RMAN 备份、MySQL 的 XtraBackup、PostgreSQL 的 pg_basebackup。
逻辑备份则通过数据库自身的导出接口，把数据以 SQL 语句或中间格式（如 CSV、自定义二进制）逐表逐行读出。它理解表、索引、约束、触发器等逻辑对象，因此可以做到表级、schema 级甚至行级的选择性备份。典型代表是 mysqldump、pg_dump、Oracle Data Pump（expdp/impdp）。逻辑备份的产物是“可读的、可编辑的、可跨平台迁移的”，但代价是导出和导入都要经过 SQL 引擎解析执行，速度慢、CPU 与 I/O 开销大。
二、三个选型维度的具体判断
数据库规模是最先要看的指标。逻辑备份的耗时与数据量近似线性增长，且导出时需要在数据库内产生大量读操作，对生产库有压力。经验上，单库小于 50GB 时，逻辑备份完全可行，甚至更方便；50GB 到 500GB 之间，逻辑备份的导出时间可能达到数小时，恢复时间更长，需要谨慎评估；超过 500GB，逻辑备份往往不再现实，必须采用物理备份。对于 TB 级以上的库，通常采用“物理全备 + 物理增量 + 归档日志”的组合，逻辑备份仅用于个别小表的补充导出。
恢复速度直接对应 RTO（恢复时间目标）。物理备份恢复的本质是文件拷贝加日志重放，一个 1TB 的库用物理方式恢复可能只需 30 到 60 分钟；而同样 1TB 用逻辑备份恢复，需要逐条执行 INSERT 语句、重建索引、校验约束，耗时可能达到 10 小时以上。如果业务要求 RTO 在 1 小时以内，物理备份几乎是唯一选择。逻辑备份更适合 RTO 宽松、以数据找回为目标的场景，比如误删一张表后只恢复该表。
跨版本迁移是逻辑备份的独特优势。物理备份的文件格式与数据库版本、操作系统平台、字节序强绑定，Oracle 12c 的数据文件不能直接挂到 19c 上，MySQL 5.7 的 InnoDB 文件也不能直接给 8.0 使用。逻辑备份导出的是 SQL 语句或平台无关的中间格式，可以在不同版本、不同操作系统之间迁移。因此，当需求是“把 5.7 升级到 8.0”或“从自建机房迁移到云数据库”时，逻辑备份是更稳妥的路径。
三、选型决策表
把上述判断整理成一张可执行的决策表，便于在实际项目中快速定位：
| 场景特征 | 推荐方式 | 理由 |
|---|---|---|
| 库 < 50GB，RTO 宽松，需单表恢复 | 逻辑备份 | 灵活、可读、可选择性恢复 |
| 库 > 500GB，RTO < 1 小时 | 物理备份 | 速度快、保真度高 |
| 跨大版本升级或跨平台迁移 | 逻辑备份 | SQL 层兼容，不受文件格式限制 |
| TB 级库日常备份 | 物理全备 + 增量 + 归档 | 兼顾速度与存储成本 |
| 核心库，RTO 与 RPO 都严苛 | 物理备份 + 逻辑补充 | 物理保恢复速度，逻辑保单表找回 |
四、混合策略才是常态
实际生产环境中，很少只选一种。更常见的做法是：以物理备份作为主力，保证整库可快速恢复；同时每周或每天对关键小表做一次逻辑导出，用于应对误删、误更新等逻辑错误。物理备份解决“库没了怎么快速回来”，逻辑备份解决“数据错了怎么精准找回”。两者互补，而不是互斥。
总结来说，物理备份与逻辑备份的选型不是一道单选题，而是一道基于规模、速度、迁移需求的条件判断题。小库、慢恢复、要迁移，选逻辑；大库、快恢复、同版本，选物理；核心系统，两者并用。把这三个维度想清楚，备份策略就不会跑偏。