3. 金融数据备份需求分析
在金融行业，备份不是“有就行”的运维附属品，而是一项被监管、业务连续性和成本三重约束的工程决策。ClickHouse 作为列式分析数据库，单表动辄数十亿行、单分区数百 GB，如果直接套用传统关系库的“每日全备”思路，往往会在备份窗口、存储成本和恢复速度上同时失控。因此，在动手写备份脚本之前，必须先完成需求分析：监管要求什么、业务能容忍丢多少数据、数据本身值多少钱、备份能占用多长时间、以及最终要花多少存储和网络成本。
一、核心原理：五个维度共同决定备份策略
备份需求分析的本质，是把模糊的“要备份”翻译成可执行的参数。这五个维度并非独立，而是相互制约：监管合规决定最低保留期限与不可篡改性；RPO/RTO 决定备份频率与恢复方式；数据分级决定哪些数据值得高频备份；备份窗口决定单次任务的时间上限；成本与容量规划则决定最终能落地哪套方案。
二、监管合规：先划红线，再谈技术
金融监管对数据备份的要求通常集中在三点：保留期限、可恢复性和不可篡改性。例如证券行业常要求交易相关数据至少保留 20 年，银行核心账务数据保留期限更长；同时要求备份介质与生产环境隔离，防止勒索软件同时加密生产库和备份库。ClickHouse 场景下，合规落地要特别注意：备份文件必须带校验和与时间戳，恢复演练要留痕，冷备数据应写入对象存储的合规保留桶或 WORM 存储。
三、RPO/RTO 与数据分级：把资源花在刀刃上
RPO（恢复点目标）决定备份频率，RTO（恢复时间目标）决定恢复方式。金融数据不能一刀切，建议按业务影响分为三级：
| 数据级别 | 典型数据 | RPO | RTO | 备份策略 |
|---|---|---|---|---|
| 核心级 | 交易流水、账务明细 | ≤5 分钟 | ≤30 分钟 | 实时副本 + 增量备份 + 异地容灾 |
| 重要级 | 客户画像、风控中间结果 | ≤1 小时 | ≤2 小时 | 小时级增量 + 每日全备 |
| 一般级 | 日志、报表快照、历史归档 | ≤24 小时 | ≤8 小时 | 每日全备或每周全备 |
ClickHouse 中可用 system.parts 和 system.mutations 辅助判断数据变更范围，从而设计增量备份粒度。例如按分区做增量，比按行做增量更符合列式库的物理结构：
-- 查看各表分区大小与最后修改时间，辅助确定增量备份范围
SELECT
database,
table,
partition,
formatReadableSize(sum(bytes_on_disk)) AS part_size,
max(modification_time) AS last_modified
FROM system.parts
WHERE active = 1
GROUP BY database, table, partition
ORDER BY last_modified DESC
LIMIT 20;四、备份窗口与成本容量：算得清才能落得地
备份窗口是业务低峰期允许备份任务占用的时间。ClickHouse 备份会消耗磁盘 IO 和网络带宽，若窗口只有 2 小时，而全量备份需要 4 小时，就必须改为“全量 + 增量”组合，或使用 BACKUP 命令配合限速参数。成本容量规划则要回答三个问题：备份数据保留多久、副本存几份、冷热如何分层。
一个可落地的参数清单如下：
- 备份频率：核心级 5 分钟增量、每日全量；重要级 1 小时增量、每日全量；一般级每日全量。
- 保留策略：核心级 20 年，重要级 3 年，一般级 1 年；采用“日备保留 30 天、月备保留 12 个月、年备长期归档”的 GFS 策略。
- 备份窗口：核心级避开交易高峰，重要级可放宽至夜间，一般级可全天错峰。
- 存储分层：近 7 天放高性能对象存储，30 天以上转低频存储，1 年以上转归档存储。
- 恢复演练：核心级每季度一次，重要级每半年一次，一般级每年一次，演练结果纳入合规审计。
五、常见误区与复盘
第一个误区是“备份成功即安全”。ClickHouse 的 BACKUP 命令返回成功，只代表文件写入完成，不代表可恢复。必须定期做恢复验证，尤其是跨版本恢复和跨集群恢复。第二个误区是“全量备份最省心”。在金融数据量下，全量备份会迅速吃满窗口和存储，增量与分区级备份才是可持续方案。第三个误区是“RPO/RTO 拍脑袋定”。RPO 每缩短一个数量级，成本可能翻倍，必须与业务方共同确认，而不是运维单方面承诺。