数据库备份与恢复方案

数据仓库（DW）备份与跨区域灾备切换方案概述

一、目标与SLA
- 恢复点目标（RPO）：数据允许丢失的最大时间窗口。典型目标为秒级（热备）、5–15分钟（温备）、24小时（冷备）。
- 恢复时间目标（RTO）：从故障到业务恢复的最长时间。典型目标为5–15分钟（热备）、1–2小时（温备）、4–24小时（冷备）。
- 一致性要求：备份需在事务一致点进行，确保跨分片/节点数据一致，支持点时间恢复（PITR）。

二、数据范围与分层
- DW存储层：事实表、维度表、聚合表、分区数据、列存索引/编码、统计信息。
- 元数据与目录：模式、视图、UDF、存储过程、权限、数据血缘、数据质量规则。
- 作业编排与配置：ETL/ELT管道定义、调度状态、依赖关系、任务运行历史与水位线（watermark）。
- 外部数据与依赖：外部表引用的对象存储路径、数据湖文件、字典/主数据。
- 安全与连接：密钥/证书、连接端点（DNS/VIP）、网络策略（ACL/防火墙/白名单）。

三、备份方案设计
1. 备份类型与策略
- 物理备份（首选）：存储层级快照或数据库级物理备份（包含数据文件、日志/WAL/redo、控制文件）。支持快速恢复和PITR。
- 日志归档与PITR：持续归档事务日志（WAL/redo）至跨区域对象存储，实现任意时间点恢复到最近一致点。
- 逻辑备份（补充）：架构与对象定义（DDL）、小体量关键表的导出，用于跨版本或跨引擎迁移；不作为主恢复路径。
- 存储快照：使用卷/文件系统快照（需应用一致性，先数据库“quiesce”或checkpoint），对MPP/分布式DW须执行集群一致快照。

2. 频率与保留
- 日志归档：每分钟或近实时（取决于系统与网络）。
- 增量备份：每小时或每4小时一次（视数据变更率）。
- 全量备份/快照：每日一次（低峰时段）。
- 保留策略：增量/日志保留7–35天，月度全量保留12个月，合规归档按法规（例如7年）。
- 分层存储：近线（热）存储快速恢复，长期归档转低成本存储。

3. 跨区域冗余与不可变性
- 备份落地对象存储并开启跨区域复制（异步，多目标），确保主区域不可用时可在备区域读取。
- 开启不可变/防篡改策略（如对象锁/WORM），并启用清单与校验（清单文件、块级校验和）防止静默损坏。

4. 安全与合规
- 全程加密：传输（TLS）与静态（服务端或客户端加密），密钥托管在KMS并定期轮转。
- 访问控制：最小权限、隔离备份账户与生产账户，审计日志完整保存。

5. 一致性与停写控制
- 备份窗口前执行数据库级一致性点：事务冻结/短暂停写或checkpoint，确保跨分片与多节点一致。
- 针对高并发管道，使用双写或缓冲队列，在备份窗口内削峰或重放。

6. 备份验证与演练
- 自动化还原验证：定期在隔离环境复原至最新备份，运行校验查询（行数、哈希、聚合比对）、权限检查与ETL冒烟测试。
- 指标与告警：备份年龄、日志延迟、校验通过率、容量与失败率，超过阈值告警。

四、跨区域灾备拓扑与切换
1. 拓扑选型
- 冷备（备区域仅存备份与基础资源）：RPO≈24小时，RTO≈4–24小时。成本低，恢复慢。
- 温备（异步日志/快照复制，备区域预部署DW实例与网络）：RPO≈5–15分钟，RTO≈1–2小时。平衡成本与时效。
- 热备（流复制/双活读写隔离，主备持续一致）：RPO≈秒级，RTO≈5–15分钟。成本高，需冲突避免与严格变更管理。

2. 主数据中心宕机跨区域切换步骤（温备/热备示例）
- 事件确认与宣告灾难：触发DR流程，冻结主区新写入与管道推进，记录最后已确认一致时间点。
- 在备区域恢复DW：
  - 冷/温备：从最近全量或快照恢复数据文件。
  - 回放日志至目标时间点（最近可达一致点），确保PITR完成。
  - 恢复统计信息、列存索引与分区元数据；重建必要的物化视图与聚合。
- 恢复元数据与编排：
  - 部署目录/元数据服务，导入DDL与权限、UDF/视图。
  - 恢复作业编排系统与队列；加载上次水位线与断点。
- 外部依赖与对象存储：
  - 验证对象存储跨区域复制完成，修正外部表路径或命名空间。
  - 更新密钥/凭证与网络策略（VPC、ACL、DNS）。
- 验证与一致性检查：
  - 关键表行数与哈希比对、事实与维度参照完整性、最近分区数据新鲜度、权限校验。
- 切换流量：
  - 更新服务端点（DNS、VIP、连接字符串），放行防火墙与白名单。
  - 将只读切换为读写（如热备），解冻摄取通道。
- 恢复管道与数据补偿：
  - 重新启动CDC/批处理，依据水位线重放漏写数据，启用幂等写入避免重复。
  - 监控落后指标，直至恢复正常。
- 事后审计与沟通：
  - 记录RPO/RTO达成情况，分析改进点。

3. 回切与再平衡
- 主区恢复后，执行数据双向比对与增量同步（以备区为源），在低风险时段回切。
- 回切前冻结写入、进行一致性点与校验，更新端点与网络策略。
- 清理与重启原复制链路，恢复标准备份与监控。

五、DW专项注意事项
- 分区与列存结构：备份需包含分区元数据与列存字典/编码，恢复后重建统计信息以保证查询性能。
- MPP/分布式一致性：跨节点快照需原子性，避免不同节点处于不同事务点；使用集群级备份协调器。
- 外部表与数据湖：确保对象存储与元数据同步；恢复后修正外部引用前缀/区域。
- 元数据版本化：UDF、视图与物化视图变更需版本管理，备份时保留历史以支持回滚。
- CDC与幂等：事件去重、主键/业务键冲突处理、Exactly-once/At-least-once策略落地；在恢复后防止重复消费。
- 作业水位线：保留运行状态、断点与重试记录，恢复后平滑续跑；对延迟敏感任务配置补偿窗口。

六、监控与自动化
- 关键指标：备份成功率、最近备份时间、日志复制延迟、PITR可达性、恢复演练成功率、对象存储复制滞后、容量与成本。
- 自动化与IaC：备份与DR资源通过IaC定义（网络、存储、计算、密钥），一键化演练与恢复流水线。
- 演练频率：按季度进行全链路演练；重大架构变更后进行专项演练。

七、示例计划（可依据业务调整）
- 全量快照：每日02:00。
- 日志归档与跨区域复制：每1分钟触发，延迟监控阈值≤5分钟。
- 元数据与编排备份：每15分钟。
- 每周一次隔离环境还原校验与性能冒烟测试；每季度一次跨区域切换演练。

该方案兼顾数据一致性、恢复时效、成本与合规要求，可根据具体DW引擎（自建MPP或云托管）进行实现细化。实施前应结合业务SLA、变更流程与网络拓扑完成风险评估与试运行验证。

以下内容概述订单库的备份方案与在误删表场景下的按时间点恢复（Point-in-Time Recovery, PITR）方案。内容聚焦数据可用性、完整性与可恢复性，覆盖通用策略与主流数据库的实现要点。

一、目标与恢复指标
- 恢复点目标（RPO）：建议≤5–15分钟，确保因故障丢失的数据量可控。
- 恢复时间目标（RTO）：建议≤30–60分钟（依规模与环境而定）。
- 覆盖范围：库级、表级、Schema、事务日志/WAL、二进制日志、元数据（DDL、用户与权限）。
- 合规与安全：备份加密、隔离存储（跨可用区/Region）、访问审计。

二、备份方案设计
- 备份类型与组合
  - 全量备份：定期（如每日/每周），用于基线恢复。
  - 增量/差异备份：缩短备份窗口与传输量，提高RPO。
  - 事务日志/WAL/二进制日志持续归档：实现PITR到任意时间点。
  - 逻辑备份（导出DDL与数据）：用于表级恢复与跨版本迁移。
  - 存储快照（块级/卷级）：作为快速应急手段（需与数据库一致性配合）。
- 关键配置与保障
  - 打开并保留事务日志（PostgreSQL WAL、MySQL Binlog、SQL Server Log），确保持续归档与足够保留周期。
  - 备份一致性：使用热备工具/快照协调（如冻结写入或使用一致性快照）。
  - 校验与可恢复性：备份校验（checksum）、周期性演练恢复、自动告警。
  - 元数据备份：定期导出全库DDL、用户/权限，以支持表级精准重建。
  - 存储与安全：多副本、跨区域、不可变存储（WORM、Object Lock）、加密（传输与静态）。
  - 自动化与可观测性：调度、日志、指标、失败重试、告警，记录备份时的日志/位点信息。

三、备份实现示例（按主流数据库）
1）MySQL（InnoDB）
- 必要配置
  - 开启二进制日志：log-bin=ON，设置server_id。
  - 推荐Row格式：binlog_format=ROW（确保重放行级变更的准确性）。
  - 落盘与一致性：sync_binlog=1（提高崩溃安全性），innodb_flush_log_at_trx_commit=1。
  - 保留周期：binlog_expire_logs_seconds（或expire_logs_days）满足PITR窗口。
- 物理热备
  - 使用Percona XtraBackup或MySQL Enterprise Backup执行每日全量与多次增量备份，记录备份时的binlog文件与position。
- 逻辑备份
  - 使用mysqldump/mysqlpump定期导出DDL（--no-data）与关键表数据（用于表级恢复）。
- 存储与校验
  - 压缩、加密、校验后上传到对象存储，并记录元数据（备份时间、binlog位点、版本）。

2）PostgreSQL
- 必要配置
  - wal_level=replica，archive_mode=on，配置archive_command将WAL归档到冗余存储。
  - 保留周期：确保WAL归档覆盖所需PITR窗口。
- 物理备份
  - pg_basebackup定期全量（如每晚），WAL持续归档以支持PITR到任意时间。
- 逻辑备份
  - pg_dump定期导出Schema与关键表数据。
- 恢复时通过recovery.signal与restore_command进行WAL回放。

3）SQL Server
- 必要配置
  - 数据库处于FULL恢复模式：ALTER DATABASE [Orders] SET RECOVERY FULL;
- 备份策略
  - 每日全量：BACKUP DATABASE ... WITH COMPRESSION, CHECKSUM;
  - 每小时差异（可选）：BACKUP DATABASE ... WITH DIFFERENTIAL;
  - 每5–15分钟事务日志：BACKUP LOG ... WITH COMPRESSION, CHECKSUM;
- 校验与维护
  - RESTORE VERIFYONLY校验备份可用性；维护日志链完整性与保留周期。

四、场景：误删表的按时间点恢复（PITR）
通用原则
- 避免影响线上写入与其他表：建议在“恢复实例/克隆库”上恢复到误删前的时间点，然后将目标表提取并导入生产库。
- 精准时间点：从审计日志/应用日志/数据库日志中确定DROP TABLE发生的时间；或使用日志解析工具扫出相应事件与位点。
- 表级导入前保障
  - 精确重建DDL（列类型、默认值、索引、约束、触发器）。
  - 处理外键依赖与数据一致性（必要时先恢复父表或暂时禁用约束）。
  - 控制并发写入窗口，避免数据冲突；在导入时使用事务与锁策略。

1）MySQL按时间点恢复步骤
- 前提：已启用binlog且有最近的全量/增量备份。
- 恢复到“误删前时间点”的恢复实例
  - 使用XtraBackup恢复最新全量并顺序应用增量：
    - 准备全量：xtrabackup --prepare --target-dir=/backups/full
    - 逐个应用增量：xtrabackup --prepare --apply-log-only --target-dir=/backups/full --incremental-dir=/backups/inc1（依序直至最后一个）
    - 最终准备：xtrabackup --prepare --target-dir=/backups/full
  - 启动恢复实例，回放binlog到误删前：
    - 确定起始位点（备份记录的binlog文件与position）
    - 回放：mysqlbinlog --start-position=<pos> --stop-datetime="YYYY-MM-DD HH:MM:SS" --database=orders /archive/binlog.* | mysql -h <recovery_host> -u <user> -p
    - 若需定位事件：mysqlbinlog --verbose --base64-output=DECODE-ROWS /archive/binlog.* | grep -n "DROP TABLE `schema`.`table`"
- 提取与导入目标表
  - 简单方式（推荐）：在恢复实例导出表数据与DDL
    - 导出DDL：mysqldump -h <recovery_host> -u <user> -p --no-data orders table > table_ddl.sql
    - 导出数据：mysqldump -h <recovery_host> -u <user> -p --single-transaction orders table > table_data.sql
  - 在生产库执行：
    - 先重建表：mysql -h <prod_host> -u <user> -p < table_ddl.sql
    - 再导入数据：mysql -h <prod_host> -u <user> -p < table_data.sql
  - 备选方式（InnoDB可传输表空间，需file_per_table=ON）：
    - 恢复实例：FLUSH TABLES table FOR EXPORT（生成.cfg），复制table.ibd与.cfg
    - 生产库：按相同DDL重建表，ALTER TABLE table DISCARD TABLESPACE，复制.ibd/.cfg到数据目录，ALTER TABLE table IMPORT TABLESPACE
- 校验与收尾
  - 比对行数与校验和；恢复索引与约束；重新启用触发器；记录变更。

2）PostgreSQL按时间点恢复步骤
- 前提：已开启WAL归档并有最近的基线备份。
- 恢复到“误删前时间点”的恢复实例
  - 将基线备份还原到新数据目录，准备归档WAL路径
  - 创建recovery.signal并配置：
    - restore_command='cp /archive/%f %p'
    - recovery_target_time='YYYY-MM-DD HH:MM:SS UTC'
    - recovery_target_action='pause'（回放达到目标时间后暂停）
  - 启动PostgreSQL，等待回放完成（日志显示到达目标时间）
- 提取与导入目标表
  - 在恢复实例：pg_dump -h <recovery_host> -U <user> -d orders -t schema.table --column-inserts > table.sql
  - 在生产库：psql -h <prod_host> -U <user> -d orders -f table.sql
- 校验与收尾：数据一致性检查、约束与索引验证。

3）SQL Server按时间点恢复步骤
- 前提：FULL恢复模式，完整日志链（全量/差异/日志）。
- 恢复到“误删前时间点”的克隆库
  - RESTORE DATABASE [Orders_PITR] FROM 'full.bak' WITH NORECOVERY, MOVE ...;
  - 可选差异：RESTORE DATABASE [Orders_PITR] FROM 'diff.bak' WITH NORECOVERY;
  - 顺序恢复日志：RESTORE LOG [Orders_PITR] FROM 'log1.trn' WITH NORECOVERY; ... 最后一个使用STOPAT并RECOVERY：
    - RESTORE LOG [Orders_PITR] FROM 'last.trn' WITH STOPAT='YYYY-MM-DDTHH:MM:SS', RECOVERY;
- 提取与导入目标表
  - 生成表DDL（SSMS或脚本）在生产库重建
  - 数据导入：INSERT INTO [Orders].[dbo].[table] SELECT * FROM [Orders_PITR].[dbo].[table];
  - 若存在IDENTITY列：SET IDENTITY_INSERT [Orders].[dbo].[table] ON后插入，再关闭
  - 若有约束/触发器：根据需要暂时禁用，导入后恢复
- 校验与收尾：校验行数、约束与索引，记录操作。

五、备份验证、监控与演练
- 周期性恢复演练：在隔离环境执行全链路恢复与表级PITR，验证RPO/RTO达标。
- 备份可用性校验：校验和检查、试恢复、日志链完整性验证（SQL Server）、binlog/WAL可读性与覆盖窗口核对。
- 监控与告警：备份失败、归档延迟、存储容量、WAL/binlog保留期、复制/归档错误。
- 变更与文档：备份与恢复Runbook、DDL变更记录、关键时间点与位点记录、权限与密钥管理。

该方案确保订单库在误删表等操作失误场景下，可以在不影响线上整体数据与写入的情况下，通过恢复实例执行精准的按时间点恢复，并以表级粒度回填生产数据。同时通过严谨的备份策略、日志归档与验证机制，达成既定的RPO/RTO目标。

概述
目标是为数据库用户服务库制定可执行的备份方案、发布失败的回滚方案，以及主从故障切换的恢复方案。内容包含备份类型与频率、恢复与校验步骤、发布变更的控制与回退流程、以及主从复制架构下的故障检测、切换和一致性恢复。

一、备份方案
1. 备份类型
- 物理热备：数据库数据目录的块级或文件级拷贝，结合事务日志（例如 Binlog/WAL）归档。用于快速恢复与点时间恢复（PITR）。适合大数据量与严格RTO场景。
- 逻辑备份：按库/表导出数据与结构（如 SQL dump）。用于跨版本迁移、单表级恢复、审计与数据选择性恢复。对大库恢复速度较慢。
- 存储快照：基于卷/文件系统快照（如 LVM、云盘快照）获取一致性副本，结合数据库日志归档实现PITR。快照触发时需确保数据库处于一致状态（短暂锁或备份模式）。

2. 备份频率与保留
- 全量备：每日一次（低峰时段）；保留7–30天。
- 增量/日志归档：每5–15分钟上传事务日志（Binlog/WAL）到对象存储；保留与全量备份一致或更长。
- 周/月保留：每周归档一份全量，每月归档一份长期保留，用于满足审计与合规。
- 元数据备份：同时备份数据库用户、权限、触发器、存储过程、序列、事件调度配置与版本号。备份清单与校验和一并保存。

3. 一致性保障
- 备份前置操作：启动备份模式或获取一致性快照，确保在同一事务点；对于逻辑备份，启用一致性读取（可重复读）并避免并发 DDL。
- 负载影响控制：备份限速、I/O隔离、读副本执行逻辑备（避免阻塞主库）。

4. 安全与合规
- 传输与静态加密：备份文件使用加密（如 AES-256），传输采用 TLS。
- 访问控制与密钥管理：分离职责，审计访问；密钥轮换与最小权限。
- 存储多地冗余：本地存储 + 远端对象存储（跨区域）。

5. 备份验证与演练
- 校验：生成与核对校验和；解压与解密验证能否成功。
- 可恢复性演练：按季度在隔离环境进行全链路恢复与PITR演练，记录RTO/RPO与问题清单。
- 自动化报告：备份成功、容量、耗时、日志上传延迟告警。

二、恢复与点时间恢复（PITR）流程
- 选择恢复点：基于故障发生时间或发布回滚时间戳，确定目标时间。
- 准备环境：新建隔离恢复实例或读副本，加载最近一次全量物理备份。
- 应用增量日志：按顺序回放事务日志直至目标时间点（精确到秒级，避免超出）。
- 数据一致性校验：
  - 运行数据库内置一致性检查与系统表校验。
  - 样本表行数、哈希校验与关键业务表约束检查。
- 只读验证：以只读模式对关键查询与接口进行验证（烟囱测试）。
- 切换上线：
  - 通过负载均衡或连接字符串切换应用至恢复实例。
  - 观察关键监控（错误率、延迟、连接数），稳定后解除只读。

三、场景发布失败回滚方案
1. 变更策略
- 版本化的迁移工具：使用版本号管理的迁移与基线（如迁移脚本、校验摘要），确保变更可追踪与可重放。
- 兼容性发布（Expand-Contract）：先增加新结构（如添加列/表、双写），应用切换到新结构后再移除旧结构。
- 事务性变更：尽可能使用可回滚的事务性 DDL/DML；对于不可事务 DDL，准备对称的回滚脚本。
- 数据变更审慎：大批量更新采用分批与可重入脚本；记录变更前快照或变更清单以便反向恢复。

2. 发布前保障
- 预发布检查：干跑（dry-run）、权限与锁检查、与读写流量冲突分析。
- 快照与标记：在发布前做一次可快速恢复的物理备或存储快照；记录发布版本号与时间戳以便PITR定位。
- 回滚预案：每个迁移脚本提供反向脚本（包含索引、约束、默认值的还原），评估回滚副作用。

3. 发布失败回滚流程
- 立即止损：冻结新的写入或启用只读，避免扩大影响。
- 应用层回滚：回退应用版本或关闭新功能开关，恢复旧读写路径。
- 数据库回滚：
  - 可事务变更：执行回滚事务或反向脚本。
  - 不可事务或结构性问题：执行PITR至发布前时间点，在新实例验证后切换。
- 验证与解冻：完成数据完整性与性能验证后恢复正常写入。
- 复盘与记录：记录失败原因、影响范围、恢复耗时，更新回滚与发布清单。

四、主从（主备/主从）故障切换与恢复方案
1. 架构与前提
- 至少一个同步或低延迟的只读副本（从库/备库），启用事务日志复制。
- 应用通过中间层（连接代理、负载均衡或服务发现）连接数据库，便于快速重定向。
- 监控与心跳：持续监控主库可用性、复制延迟、错误率。

2. 故障检测与切换策略
- 触发条件：主库不可达、崩溃、严重性能退化或复制落后超阈值。
- 防分裂脑：
  - 主库失联时先隔离（下线、关闭写入、移除负载均衡目标）。
  - 采用仲裁/投票或外部协调服务，确保只有一个主库被提升。
- 提升副本为主库：
  - 在副本上停止复制并提升为可写主库。
  - 确认最后已应用的事务位点（日志位置/LSN），评估与主库的偏差。
- 客户端重配置：更新连接目标或服务发现记录，缩短DNS/缓存TTL，确保应用写入到新主库。
- 写入恢复：逐步放开写入，观察复制延迟与错误。

3. 原主恢复与重新加入
- 原主健康修复：完成崩溃恢复、数据校验，确保不再对外提供写入。
- 重新拉起为副本：
  - 清理不一致数据，使用新主库的全量备份重新同步。
  - 配置复制并从新主库最新事务位点开始追赶。
- 一致性验证：
  - 比对关键表的计数与校验和，抽样数据一致性检查。
  - 对复制延迟与错误进行持续监控。

4. 自动化与演练
- 使用故障切换控制器或编排工具进行自动化切换（具备仲裁与隔离能力）。
- 半年度演练：模拟主库宕机、网络分区、日志落后，验证RTO/RPO与操作步骤。
- 变更窗口策略：在低风险时段进行大规模DDL或拓扑变更。

五、监控与运行指标
- 备份：成功率、耗时、备份大小、日志归档延迟、恢复演练结果。
- 复制：延迟、错误计数、重试次数、当前位点差异。
- 可用性：连接错误率、查询延迟、锁等待、死锁。
- 安全：访问审计、密钥轮换状态、加密有效性。
- 容量与增长：表/索引膨胀、数据增长率、热点表写入分布。

附注与实施建议
- 引擎适配：上述方案适用于主流关系型数据库。事务日志归档与PITR分别对应如 Binlog（MySQL/MariaDB）或 WAL（PostgreSQL）。物理热备可采用对应引擎的热备工具或官方基线备份机制，逻辑备采用引擎自带导出工具。
- 文档与Runbook：为备份恢复、发布回滚、故障切换分别维护标准操作指引与检查清单，确保在值班与演练中可重复执行。
- 变更治理：所有DDL/DML迁移纳入评审与预演流程，含性能影响评估与回滚可行性评估。