ClickHouse备份与恢复实战：从FREEZE快照到clickhouse-backup避坑指南

ClickHouse备份与恢复实战：从FREEZE快照到clickhouse-backup避坑指南

发布时间：2026/10/1 4:27:38
ClickHouse备份与恢复实战：从FREEZE快照到clickhouse-backup避坑指南 ClickHouse 的备份恢复大概是很多团队从“能跑”到“敢挂”之间最容易被跳过的一道坎。我印象很深刻的一次事故某个凌晨节点磁盘报错同事第一反应是去执行备份脚本结果发现上次成功全量备份已经是一个月前的存量期间所有增量因为脚本里的路径写错一直在静默失败。那种在故障现场硬着头皮恢复数据的感觉经历过一次就再也不想经历。所以这篇东西我宁可写啰嗦一点也要把 ClickHouse 备份与恢复当中那些容易踩、踩了又很难查的细节摊开讲清楚尤其是版本更新后命令和行为的差异足够新也足够“保姆级”。这篇文章适合谁刚把 ClickHouse 从单机玩到集群、准备接生产的人被领导要求“做个备份机制”但不知道从哪下手的运维开发以及已经用过clickhouse-backup但遇到过恢复失败、对不上数据的人。我会尽量先从底层逻辑讲起再进入完整实操最后还附上我实际踩过的坑和排查思路照着做基本能覆盖日常 90% 的场景。1. 先搞懂数据落盘的底层逻辑备份才不会抓瞎1.1 MergeTree 家族在磁盘上到底长什么样ClickHouse 最常用的表引擎是 MergeTree 系列它的数据组织方式和 MySQL、PostgreSQL 那种“一个库一个目录、里面一堆文件”完全不同。默认数据目录是/var/lib/clickhouse/往下依次是data/、{database}/、{table}/、{partition_id}/、{part_name}/。列表展开大概是这个结构/var/lib/clickhouse/ ├── data/ │ └── default/ │ └── my_table/ │ ├── 20240101_20240101_1_1_0/ │ │ ├── id.bin │ │ ├── id.mrk2 │ │ ├── ts.bin │ │ ├── ts.mrk2 │ │ └── primary.idx │ └── 20240102_20240102_2_2_0/ └── shadow/每个 part 目录里放的是这一小块数据对应的列文件.bin是压缩后的列数据、标记文件.mrk2和主键索引文件primary.idx。ClickHouse 写数据是“先写内存缓冲区再按 block 落盘生成一个不可变的 part”后台再由后台 merge 线程把多个小 part 合并成大 part。这个机制直接决定了备份策略的走向如果你在业务正在写入的时候直接cp -r整个数据目录拷贝过程中 ClickHouse 可能正在 merge、正在把内存中的数据刷成新 part甚至正在把某些 part 标记为删除。你拿到的文件集合可能处于“某个 part 只拷了一半”的状态。MySQL 的物理备份还得先FLUSH TABLES WITH READ LOCKClickHouse 的可变 part 机制让简单拷目录更不可靠。所以理解 ClickHouse 备份的第一步不是背命令而是理解它本质上是“一堆不可变的小文件 plus 后台的合并动作”。真正安全的备份必须建立在“文件系统级别的一致性”上或者干脆绕开文件系统、走官方快照机制。1.2 part 命名里藏着的全量/增量线索如果你进到某个 MergeTree 表目录里会看到类似这样的目录名ls /var/lib/clickhouse/data/default/my_table/ # 20240101_20240101_1_1_0 # 20240101_20240102_5_8_1这里20240101是 partition id它来自表的分区键。比如按月分区2024 年 1 月的分区 id 可能长这样如果按toYYYYMMDD分区那这个 id 就是日期。后面四个数字是_minBlockNum_maxBlockNum_levelminBlockNum/maxBlockNum每次插入操作会从全局的 block 序号里取一段这两个数字表示这个 part 涵盖的数据块范围。如果同一个分区下有多个 part它们的块号区间一般不重叠。level这个 part 经历了多少次 merge。新写入的 part level 是 0两个 level 为 0 的 part 被 merge 后新 part 的 level 就变成 1。这些信息对备份恢复很有用比如你在恢复时看到某个分区下有好几个 part而不是一个完整的目录这是正常的说明这些 part 还没来得及被 merge。用ALTER TABLE ... ATTACH PARTITION恢复时ClickHouse 自己会判断哪些 part 需要合并你不用手工合并但如果shadow快照里的 part 和表里已有 part 的maxBlockNum范围发生重叠就可能报 “Part ... intersects previous part” 之类的错误。这个后面恢复篇会详细说。1.3 副本表、分布式表和单机表的备份差异表引擎不同备份方式也要区分MergeTree纯本地存储备份它的数据目录或走 FREEZE / clickhouse-backup 都可以。ReplicatedMergeTree本地也有数据但元数据里的复制队列、zk 路径信息很关键。只拷贝数据文件、不带replicas元数据的话新节点可能起不来或者需要手工处理ReplicatedMergeTree的 zookeeper 路径冲突问题。Distributed本身不存数据只是一个逻辑层。备份它主要是备份表结构以及每个分片的本地表恢复时重建所有分片上的本地表即可。很多人以为 ClickHouse 有副本就可以不做备份这是误解。副本解决的是“节点挂掉”的问题不解决“有人执行了DROP TABLE或误更新了全表数据”的问题。副本会把你的误操作同步复制到所有副本。ClickHouse 的备份本质上还是要在“所有副本之外”留存一份可独立恢复的数据。2. 备份方案选型三种主流思路的取舍边界2.1 为什么直接复制数据目录几乎必挂理论上如果把 ClickHouse 优雅停掉让所有 part 都落盘并处于一致状态再cp -r整个目录然后再启动这操作在单机场景偶尔是可行的。但在生产环境特别是 7x24 写入的场景下你不可能为了备份停库。即便你不停库在拷贝过程中也存在多个风险点拷贝到一半后台 merge 把旧的 part 删了、把新 part 写出来了目录列表在不同时间点看到的内容不一致。正在写入的.bin文件可能只写了一半拷过去就是损坏的文件。detached目录里可能有正在排障时丢进去的孤儿 part拷过去之后 attach 时容易出问题。所以我在团队里定了一条规矩任何没有经过官方快照或专用工具的备份都不算备份。cp -r /var/lib/clickhouse这种看似朴素的方案在灾难恢复时会给你开一个大大的盲盒。2.2ALTER TABLE ... FREEZE官方自带快照机制的底层逻辑ClickHouse 官方提供了一种内置的“备份姿势”执行ALTER TABLE my_table FREEZE;这条 SQL 会把当前表里所有 part 在/var/lib/clickhouse/shadow/目录下建立硬链接。注意是硬链接不是复制。因为 part 文件不可变新写入的 part 不会改老 part所以用硬链接做快照非常高效快照瞬间完成不占额外磁盘空间只有当原始文件被清理、而快照里还引用着它时磁盘空间才会真正被“释放”。这个机制背后的原理是 inode 引用计数。shadow/N/目录下会生成和data/目录结构类似的层级每个目录里就是指向原文件的硬链接。FREEZE 之后你可以把shadow/里的某个表目录拷贝到其他机器上恢复。把 shadow 目录里的 part 移到目标表的detached目录再执行ALTER TABLE my_table ATTACH PART 20240101_20240101_1_1_0;就能把数据挂回去。FREEZE 是理解后面所有备份工具的基础——很多工具本质上是帮你把“FREEZE 复制 恢复”这套流程自动化。2.3 clickhouse-backup 为什么成了社区事实标准虽然官方有 FREEZE但生产环境需要的显然不止是“把快照留在本地”。还需要远程存储、定时调度、增量备份、表级恢复、跨集群迁移这些官方原生 SQL 一时半会做不利索于是社区里出了clickhouse-backup这个工具。它做的事情可以用一句话概括备份时先通过 ClickHouse 的系统表读取表结构、分区信息、part 列表再把每个 part 目录上传到本地或远程存储S3、GCS、SFTP 等同时生成一份元数据 JSON恢复时根据元数据重建表结构再把 part 目录拉回来放到对应位置。和直接 FREEZE 相比它解决了几个很实际的问题备份是“目录级一致性”的工具内部会对一张表先做一次短暂的一致性快照再开始上传不会像手动 cp 那样拷到一半看到不一致状态。原生支持增量备份依赖 part 的不可变特性只需要上传自上次备份以来新出现的 part。支持表级恢复可以只恢复某几个表而不是全库。有远程存储能力备份文件可以传到 S3机器烧了都不怕。我用它做主力备份工具用了很长时间整体稳定性是够的。不过要注意它的命令行参数在不同大版本之间有过不兼容的调整尤其是 v1.x 和 v2.x 的差异所以照着老教程执行clickhouse-backup create之前最好先确认你装的版本对应的参数。2.4 云盘快照 / 文件系统快照适合什么场景除了 FREEZE 和 clickhouse-backup还有一种思路是依赖底层基础设施做磁盘快照比如云服务商提供的云盘快照EBS snapshot / 云盘自动快照本地的 LVM 快照、ZFS 快照虚拟机层面打快照这些方案本质上是对整个数据目录做一次性文件系统一致性快照通常要求你在快照前让 ClickHouse 处于一致性状态。ClickHouse 的文档也提到如果在FREEZE之后再做文件系统快照会是很稳妥的做法但如果你直接对正在运行的实例打 LVM 快照需要先执行SYSTEM FREEZE或者确保写入能够容忍。我的判断标准是方案适合场景不适合场景ALTER TABLE ... FREEZE临时备份、手动操作、部分表恢复没有远程存储、全自动化需求clickhouse-backup日常全量/增量、S3 远程、表级恢复一次性应急、想完全不引入外部工具云盘快照多表全量、整机恢复、不想装任何工具细粒度表级恢复、误删数据精准找回说实话这三者不是互斥关系。我现在的生产环境是每天凌晨clickhouse-backup做全量增量推到 S3同时对数据目录所在云盘开启每日快照作为第二重保险。两者可以同时存在容灾时优先用 clickhouse-backup 做表级恢复万一工具本身有问题还有云盘快照兜底。3. 保姆级实操clickhouse-backup 的安装、配置与全量备份3.1 下载二进制并确认版本匹配clickhouse-backup是开源工具最简单的方式是从它的 GitHub Releases 页面下载和你系统架构匹配的二进制放到/usr/local/bin/下并加执行权限curl -L https://github.com/Altinity/clickhouse-backup/releases/download/v2.6.0/clickhouse-backup-linux-amd64.tar.gz -o ch-backup.tar.gz tar -xzf ch-backup.tar.gz mv clickhouse-backup /usr/local/bin/ chmod x /usr/local/bin/clickhouse-backup clickhouse-backup --version这里有两件事必须确认ClickHouse 版本不能太新或太旧到完全不兼容。clickhouse-backup 的 Release 页面一般会标明支持的 ClickHouse 版本范围比如某些新版依赖系统表字段system.parts的active状态老版本 ClickHouse 可能缺字段备份时就会报错。生产环境升级 ClickHouse 前最好先看一眼当前使用版本的备份工具是否兼容。配置文件路径。首次执行任意命令时工具会提示没有配置文件可以用clickhouse-backup default-config把默认配置导出来再慢慢改。不要手工凭记忆写配置。3.2 细读 config.yml这些字段最容易配错运行下面的命令生成默认配置clickhouse-backup default-config /etc/clickhouse-backup/config.yml打开之后核心节点就几个我直接给你一份注释过的最小可用配置general: remote_storage: s3 # 远程存储类型s3 / gcs / local / none max_file_size: 1099511627776 # 单文件超过这个大小会尝试分片默认 1TB allow_to_create_new_table_restore: true # 恢复时允许自动建表 clickhouse: host: 127.0.0.1 port: 9000 username: default # 建议用专用账号给 SELECT、CREATE、ALTER 等权限 password: your_password secure: false # 如果开了 TLS改成 true timeout: 30s backups: path: /var/lib/clickhouse-backup/backups # 备份在本地暂存的目录 restore_path: /var/lib/clickhouse-backup/restore s3: access_key: AKIA... secret_key: xxxx bucket: my-clickhouse-backup region: ap-northeast-1 endpoint: # 如果用的不是 AWS S3 兼容对象存储填对应的 endpoint配置里最容易踩的坑有三个remote_storage: none会让备份只保留在本地暂存目录很多新手配完以为传到 S3 了实际没有。要传远程必须显式指定 s3 或 gcs。username和password的权限不够时备份过程会在读取系统表或执行FREEZE阶段就报权限错误日志还比较隐晦。建议给备份账号SELECT、CREATE TEMPORARY TABLE、ALTER ... FREEZE权限恢复时还需要建库建表权限。secure如果你连接的是clickhouse-client --secure对应的 9440 端口这里不改成 true 会一直超时。3.3 执行第一次全量备份并验证配置完成后先不要急着接定时任务手动跑一次clickhouse-backup create my_first_backup如果省略备份名工具会生成一个带时间戳的名字。执行完以后用下面的命令确认备份状态clickhouse-backup list输出大致是my_first_backup 2024-01-01 03:00:00 2024-01-01 03:05:00 local 0 B如果你想直接看备份内容是否包含某张表加一个参数查看明细clickhouse-backup list --all另外去本地暂存目录看一眼ls -lh /var/lib/clickhouse-backup/backups/my_first_backup/ # metadata/ # shadow/metadata目录里是建表语句shadow里是各表的数据 part。看到这个结构基本上第一次全量备份就成了。我建议你备份完成后再做一个动作把备份文件大小和源库数据量对比一下确认量级合理。别等到要恢复才发现备份脚本根本没在跑或只备份了系统库。3.4 增量备份、表级备份与保留策略clickhouse-backup 增量备份的实现思路是新 part 具有不可变性所以增量备份只需要找出“上次备份之后新增的 part”上传即可。命令行参数一般是clickhouse-backup create --diff-from my_first_backup incremental_after_first它会把my_first_backup之后新增的 part 作为增量内容保存。对于每天都跑定时任务的场景我习惯这样设计# 周一 03:00 全量 0 3 * * 1 /usr/local/bin/clickhouse-backup create --tables default.* full_$(date \%F) /var/log/clickhouse-backup.log 21 # 其余每天 03:00 增量 0 3 * * 2-7 /usr/local/bin/clickhouse-backup create --diff-from latest --tables default.* inc_$(date \%F) /var/log/clickhouse-backup.log 21注意--tables default.*可以限定只备份某个库或某几张表如果库很多排除掉不重要的日志表能显著降低备份耗时。但引号里的通配符规则要提前在测试环境验证否则很容易出现“备份成功但内容是空的”。保留策略上我一般是保留最近 7 个全量、30 个增量更老的就删除。删除备份文件直接用clickhouse-backup delete local old_backup_name如果远程存储也传了加--remote参数删除远端文件。这里有个经验不要手工去删 S3 桶里的对象目录否则元数据列表里会出现“备份不存在但占着名额”的状态后患无穷。4. 恢复链路实操单表恢复、分区恢复与跨集群迁移4.1 恢复前必须明确的三件事很多人跑到恢复环节心态是“赶紧执行 restore 把数据弄回来”但我在生产环境处理过太多次恢复事故必须严肃地提三个问题要恢复的是整机、整库、单表还是只是某个分区需求不同命令和参数完全不同。恢复到原集群还是新集群如果原集群的节点还活着只是数据被误删可以直接 restore如果是重建环境表结构里如果带ReplicatedMergeTreezookeeper 路径、副本标识都要处理。目标表当前是否已有数据如果表里已经有数据盲恢复可能导致 part 冲突。clickhouse-backup 的处理策略是恢复时对已存在的表默认不会覆盖要么在 restore 参数里加--rm先删掉目标表要么手工清理旧 part。4.2 用 clickhouse-backup 恢复单表的完整过程假设我们误删了default.orders这张表备份名叫full_2024-01-01目标是把这张表恢复到当前集群。先确认备份内容里包括这张表clickhouse-backup list --all # full_2024-01-01 ... default.orders default.users ...然后执行表级恢复clickhouse-backup restore full_2024-01-01 --tables default.orders如果业务涌入、原表还在并且你确定要用备份数据覆盖它可以在恢复前这样操作clickhouse-backup restore full_2024-01-01 --tables default.orders --rm--rm会在恢复前删除目标表并重建这非常危险但确实有效。我建议在命令执行前再确认一次环境变量或者备份名避免把“测试集群”恢复成“生产集群”。恢复过程中会依次做建表如果需要→ 下载 part 到restore_path→ 把 part 移动到detached→ 执行ALTER TABLE ... ATTACH PART。完成后立刻验证数据量和最新分区时间SELECT count(), max(ts) FROM default.orders;如果数据量和误删前对得上恢复链路就闭环了。4.3 FREEZE 快照 ATTACH PARTITION 手动恢复法有些场景你手上没有 clickhouse-backup只有shadow快照目录比如你自己执行过ALTER TABLE ... FREEZE或者从另一台机器拷贝过来一份 shadow 目录。这时候可以手动恢复。假设shadow/1/data/default/orders下有多个 part 目录目标表已经建好。把 part 目录放到目标表的detached目录cp -r /path/to/shadow/1/data/default/orders/20240101_20240101_1_1_0 /var/lib/clickhouse/data/default/orders/detached/ chown -R clickhouse:clickhouse /var/lib/clickhouse/data/default/orders/detached/然后在 ClickHouse 客户端执行ALTER TABLE default.orders ATTACH PART 20240101_20240101_1_1_0;如果detached目录下有很多 part你不想一个个写 SQL可以执行ALTER TABLE default.orders ATTACH PARTITION 20240101;这会把该分区下所有 detached 的 part 一次性挂载回去。注意partition id要写对它不一定是toYYYYMMDD的结果建议用SELECT partition_id, name FROM system.parts WHERE tableorders查一下。为什么要把 part 先丢到detached而不是直接放回data目录因为detached目录是 ClickHouse 专门为“手工导入/排除”设计的中转区服务启动时不会自动加载它只有你显式ATTACH之后才会识别。直接放回 data 目录很可能导致服务启动时加载到不完整 part或者 part 校验失败触发异常。4.4 跨集群迁移macros、集群名和 ZooKeeper 路径的处理跨集群迁移是恢复场景里最容易“卡壳”的领域。比如从旧集群的备份恢复到新集群如果表是ReplicatedMergeTree那么建表语句里通常包含这样的参数ENGINE ReplicatedMergeTree(/clickhouse/tables/{shard}/orders, {replica}){shard}和{replica}是从每个节点的macros配置里读取的。新集群的宏可能和老集群不一致直接恢复会导致两个副本写了同一个 zookeeper 路径或者因为 replica 名称冲突而同步混乱。我在跨集群恢复时的处理顺序备份和元数据拷贝到新集群。在配置文件的macros里保证新集群各节点的shard、replica定义与旧集群一致或者在恢复前手动改掉建表语句里的 zookeeper 路径。用clickhouse-backup restore时如果报 zookeeper 相关错误优先检查system.replicas里表的zookeeper_path和replica_name。恢复完成后执行SYSTEM RESTORE REPLICA或者SYSTEM SYNC REPLICA确保副本队列能正常追上。简单说跨集群恢复不只是在“拉数据”表引擎的分布式元数据也要跟着匹配。否则你看到数据在但副本之间互相不认问题比丢数据还难排。5. 自动化、监控与备份验证别让故障日变成“开盲盒”5.1 定时任务与日志如何设计定时备份我前面给过 crontab 的例子但真正生产级要考虑的不只是“命令跑没跑”还有日志要有时间戳、备份名、耗时、备份大小。如果备份失败要能告警而不是等第二天人工看 log。备份产生的本地临时文件要定期清理否则磁盘会被/var/lib/clickhouse-backup/backups占满。我自己用的脚本结构大概是这样#!/usr/bin/env bash set -euo pipefail LOG_FILE/var/log/clickhouse-backup/backup_$(date \%F).log BK_NAMEfull_$(date \%F) /usr/local/bin/clickhouse-backup create $BK_NAME $LOG_FILE 21 || { echo backup failed at $(date) $LOG_FILE curl -fsS -m 10 https://your-monitor.example.com/api/v1/alert?msgclickhouse_backup_failed || true exit 1 } # 上传到远程存储 /usr/local/bin/clickhouse-backup upload $BK_NAME --remote $LOG_FILE 21 # 清理 7 天前的本地备份 /usr/local/bin/clickhouse-backup delete local $BK_NAME_OLD --dry-run $LOG_FILE 21告警这步很重要它把“备份任务失败”从静默问题变成主动暴露问题。不要等故障当天才发现脚本已经坏了二十天。5.2 备份可还原性的日常巡检备份不等于可恢复。我见过太多环境备份目录存在但从来没恢复过等真要恢复时才发现某个表被跳过了、某个分区没有数据。日常巡检我建议做三件事至少每周挑一个备份在临时环境执行一次restore不需要恢复全量挑一个数据量中等的表验证。用clickhouse-backup list --all检查备份里表和实际表数量是否一致。如果配置了远程存储每两周做一次clickhouse-backup upload后的文件抽查到 S3 桶里看对象数量和大小是否和本地备份一致。有些团队会用“恢复演练”代替“备份监控”效果最好但成本也高。折中下来至少做到“每周真实 restore 一张表”。这个动作在关键时刻救命的概率极大。5.3 定期演练的建议说个真实案例。某次我们需要从 S3 恢复一个 30 节点的 ClickHouse 集群到新机房演练之前以为备份很完整结果发现老集群部分表早就被重命名过备份的元数据里还是旧表名恢复后业务头上顶着“表不存在”的报错。这个问题的根因相当简单几个月前一次建表变更没有同步更新备份元数据或者说备份任务对“重命名表”的感知太弱。后来我把恢复演练固定成季度一次并且明确演练内容不只是“数据能查”还包括新机房能不能靠备份独立拉起一个可用集群。业务查询所需的Distributed表和Dictionary是否也恢复好了。权限账号、物化视图、Kafka/RabbitMQ引擎表是否要单独处理。演练发现的问题越多生产事故越少这个账值得算。6. 高频踩坑实录问题现象、排查链路与根因6.1 备份目录比源库小很多正常吗如果你发现备份目录明显小于你预估的数据量先不要慌看看是不是以下原因ClickHouse 的system.parts里有大量active0的旧 part它们也占磁盘但备份工具默认只备份 active part所以备份会小于du -sh /var/lib/clickhouse/data的统计值。备份工具默认会跳过detached目录如果大量数据被人为移到 detached备份大小会“异常偏小”。遇到这种情况我的排查顺序是先看备份日志里统计的表和 part 数再看备份目录里各表的大小最后去源库执行SELECT table, count() AS part_count, sum(bytes_on_disk) AS total_bytes FROM system.parts WHERE active GROUP BY table;如果这两边对得上就没问题。问题是有些新手看到备份目录小就以为备份失败然后误删了备份目录反而丢了数据。所以“先判断大小差异合不合理”比盲目采取措施更重要。6.2 restore 提示 Schema not found 之类错误clickhouse-backup恢复时报schema not found或表不存在常见原因有三个备份时该表还没有建或者备份元数据里没有该表。--tables参数过滤了表名恢复时没包含进去。备份里表名和当前环境里表名数据库名不匹配。排查方法是先解压或查看备份元数据中的metadata/default/orders.sql确认建表语句存在然后用clickhouse-backup restore 备份名 --tables default.orders -v输出详细日志看卡在哪一步。这类问题大多是备份和恢复命令参数的匹配问题一般不涉及数据损坏。6.3 备份长时间卡在某个表备份卡住的现象往往是日志停在那张表表现为 part 数量多、单个 part 文件特别大、或者备份账号权限不足导致查询system.parts一直等待。还有一个容易被忽略的原因CLickHouse 本身有大量ReplicatedMergeTree表待同步任务执行FREEZE时因为 zookeeper 连接不稳定或复制队列积压导致操作无法快速完成。我的处理方式先找到卡住的具体表用SELECT * FROM system.processes;看当前是否有长时间运行的 DDL 或 SELECT必要时杀掉这个查询进程再重新执行备份。如果多次卡住检查 zookeeper 的延迟和节点间网络这往往是根因所在。6.4 恢复后数据有偏差先查这几个位置恢复完成后数据量和源库对不上先别怀疑工具按顺序检查system.parts里active状态。如果恢复过程有 part 被标记为outdated它可能不会出现在查询里但数据其实还在磁盘上。分区键是否一致。例如备份时表用的toYYYYMMDD(ts)分区恢复后建表语句如果被改动过分区划分可能不同。有没有遗漏Distributed表。只恢复了本地表没恢复分布式表业务查到的数据自然“变少”了。max_ts或者最新分区是否缺失先把数据和备份列表里的时间范围对齐再谈其他问题。最后再分享一个细节每次恢复完成我都会在目标表上执行一遍OPTIMIZE TABLE ... FINAL虽然这会触发一次大 merge、耗时长但它能把分区内的 part 整理干净也会顺带清理掉一些异常状态。这个操作在列式存储里并不便宜但相比数据完整性来说这笔时间开销是值得的。