1. 备份方案概览
ClickHouse 没有行式数据库那种在线 REDO 日志,恢复必须依赖「Part 快照 + 元数据」。因此备份策略的选择要围绕 Part 展开。
1.1 三种备份手段对比
| 手段 | 原理 | 适用场景 | 成熟度 |
|---|---|---|---|
| 文件级备份(FREEZE/DETACH) | 硬链接 Part 快照 | 自建脚本、全量场景 | 高 |
| clickhouse-backup 工具 | 自动 FREEZE + 打包 + 上传 | 生产标配,支持增量 | 高 |
| 原生 BACKUP/RESTORE | 服务端直接打包成 zip | 单表/库快速迁移 | 中(24.x 起较稳) |
| 副本冗余 | 多副本自动同步 | 容灾兜底,不替代备份 | 高 |
核心原则:副本 ≠ 备份。副本解决的是「硬件故障下的可用性」,备份解决的是「误删、数据损坏、逻辑错误下的可恢复」。两者必须同时具备。
1.2 备份内容的边界
-- 一个完整备份应包含:
-- 1. 表结构(DDL)
-- 2. 数据(Parts)
-- 3. 分区元数据
-- 4. 访问权限(users/roles/quotas/row policies)
-- 5. 集群配置(config.xml / metadata.xml,通常走配置仓库)
2. 文件级备份原理:FREEZE 与 DETACH
2.1 FREEZE:原子快照
-- 生成全表当前 active Parts 的快照,放到 /var/lib/clickhouse/shadow/N/
ALTER TABLE events FREEZE WITH SNAPSHOT 'backup-20240901';
FREEZE 的原理:
- 为每个 active Part 建立硬链接(不是拷贝),不占额外磁盘;
- 硬链接目录复制到
/var/lib/clickhouse/shadow/N/; - 后续的写入/合并生成新 Part,不影响快照;
- 只有手动删除
shadow下的内容才会真正释放空间。
# 查看 shadow 快照
ls -R /var/lib/clickhouse/shadow/
| 特性 | FREEZE | 直接 COPY 数据目录 |
|---|---|---|
| 一致性 | 原子,无中间态 | 可能拷到半新半旧的 Part |
| 磁盘占用 | 硬链接,几乎为 0 | 全量拷贝 |
| 恢复方式 | 拷回 + ATTACH | 拷回即用(需停机) |
2.2 DETACH:分区级备份
针对单个分区做备份时,用 DETACH 把分区移出主目录再拷贝:
ALTER TABLE events DETACH PARTITION '202405';
-- 拷贝 detached/202405 到备份目录
cp -r /var/lib/clickhouse/data/default/events/detached/202405 /backup/202405
-- 处理完后重新挂回
ALTER TABLE events ATTACH PARTITION '202405';
DETACH 会短暂影响该分区的查询(DETACH 后不可见),只适合低频分区归档。日常全量备份请优先 FREEZE。
3. clickhouse-backup 工具
3.1 安装与配置
# 二进制安装
wget https://github.com/Altinity/clickhouse-backup/releases/latest/download/clickhouse-backup-linux-amd64.tar.gz
tar xzf clickhouse-backup-linux-amd64.tar.gz
sudo mv clickhouse-backup /usr/local/bin/
clickhouse-backup --version
核心配置 /etc/clickhouse-backup/config.yml:
general:
remote_storage: s3
max_file_size: 1000000000
clickhouse:
host: localhost
port: 9000
username: default
password: "***"
secure: false
s3:
access_key: "AKIA..."
secret_key: "***"
bucket: "ch-backup-bucket"
path: "/backups"
region: ap-east-1
compression_format: tar
backup:
allow_to_backup_frozen: true
use_embedded_backup_restore: false
restore:
allow_to_restore_frozen: true
3.2 常用命令
# 备份全部数据库
clickhouse-backup create
# 只备份指定库表
clickhouse-backup create events --tables=default.events
# 按分区备份
clickhouse-backup create events_part --tables=default.events --partitions=202406
# 查看备份列表
clickhouse-backup list
# 查看备份包含的表
clickhouse-backup tables events
# 上传到对象存储
clickhouse-backup upload events
# 删除本地/远端备份
clickhouse-backup delete events
clickhouse-backup delete_remote events
| 命令 | 作用 | 说明 |
|---|---|---|
create | 本地创建备份 | 默认 24 小时内自动增量 |
list | 列出本地备份 | 显示大小与创建时间 |
upload / download | 对象存储往返 | 远端存一份才安全 |
restore | 本地恢复 | 见第 5/6 节 |
tables | 查看备份内容 | 恢复前核对 |
delete / delete_remote | 清理 | 防止备份无限膨胀 |
4. 增量备份
4.1 自动增量机制
clickhouse-backup 在距上次备份 24 小时内创建的备份默认是增量的——只打包自上次以来的新 Part,体积大幅缩小:
# 第一次全量
clickhouse-backup create full_0901
# 第二次自动增量(仅新 Parts)
clickhouse-backup create incr_0902
# 查看大小差异
clickhouse-backup list
| 备份类型 | 内容 | 体积 | 恢复依赖 |
|---|---|---|---|
| 全量 | 所有 Parts + 元数据 | 大 | 无 |
| 增量 | 上次以来的新 Parts | 小 | 需要基准备份 |
| 远端增量 | 增量包上传 | 小 | 需按链还原 |
4.2 恢复增量备份
# 需要指定基准备份链时
clickhouse-backup restore incr_0902 --diff-from=full_0901
增量链越拉越长时恢复越慢。建议:每周一次全量,每日增量,保留最近 2 周全量 + 1 个月增量,超期自动清理。
5. 分布式集群备份与恢复
5.1 多节点协调策略
分布式表本身不存数据,备份要针对每个分片上的本地表:
# 在每个分片节点上分别执行(只备份本机 local 表)
clickhouse-backup create node_backup --tables=default.events_local
| 方式 | 协调 | 优缺点 |
|---|---|---|
| 逐节点独立备份 | 无 | 简单,但需要知道每个分片 |
| 中心节点调度 | SSH/Ansible | 统一管理,方便上传 |
| ON CLUSTER 原生 BACKUP | ClickHouse 协调 | 服务端统一打包,易落地 |
5.2 原生 BACKUP/RESTORE(分布式)
原生备份支持 ON CLUSTER,是集群级备份的最简路径:
-- 定义备份磁盘(config.xml 中加一块 disk)
-- <disks><backups><type>s3</type><endpoint>...</endpoint></backups></disks>
-- 备份全库(在任意节点执行,ON CLUSTER 分发)
BACKUP DATABASE default ON CLUSTER my_cluster
TO Disk('backups', 'cluster_20240901');
-- 查看备份进度与结果
SELECT status, error FROM system.backup_log
ORDER BY start_time DESC LIMIT 5;
-- 恢复
RESTORE DATABASE default ON CLUSTER my_cluster
FROM Disk('backups', 'cluster_20240901');
| 原生备份要点 | 说明 |
|---|---|
| 需要 BACKUP 权限 | GRANT BACKUP ON default.* TO backup_user |
| 备份物是 zip 文件 | 支持上传到 S3/GCS |
ON CLUSTER | 各节点协调,元数据一致 |
system.backup_log | 记录每次操作的状态 |
6. 恢复演练:DROP TABLE 后恢复
恢复能力是「练」出来的,不是「配置」出来的。以下是标准演练剧本。
6.1 场景:误删整个表
-- 模拟事故
DROP TABLE default.events;
# 用 clickhouse-backup 恢复
clickhouse-backup restore events --tables=default.events
恢复内部流程:
- 读取备份元数据,重建
CREATE TABLEDDL; - 拷回 Parts 到数据目录;
ATTACH挂载(不重新导入,直接挂目录);- 校验行数是否与备份一致。
-- 恢复后校验
SELECT count(), sum(rows) FROM system.parts
WHERE table = 'events' AND active = 1;
SELECT count() FROM events;
6.2 恢复策略决策
| 数据丢失范围 | 恢复方式 | 影响 |
|---|---|---|
| 单表误删 | restore --tables=db.table | 分钟级 |
| 单分区误删 | restore --partitions=202406 | 秒级 |
| 全库误删 | restore(全量) | 需停机窗口 |
| 节点磁盘损坏 | 副本自动补齐 + 备份兜底 | 视网络 |
演练要点:每周定时在测试集群执行一次恢复,记录「备份 → 恢复」的完整耗时(RTO)与可容忍数据丢失窗口(RPO)。
7. 容灾架构
7.1 副本容灾 vs 跨机房
| 层级 | 手段 | RTO | RPO | 成本 |
|---|---|---|---|---|
| 同机房副本 | Replicated 引擎 | 分钟 | 秒级 | 中 |
| 跨可用区副本 | 分布式集群分片 | 分钟 | 秒级 | 高 |
| 跨机房独立集群 | 双写 + 定期同步 | 小时 | 分钟 | 中 |
| 冷备 | 对象存储备份 | 小时 | 备份间隔 | 低 |
7.2 跨机房双集群架构
生产常见做法:双活写入 + 备份兜底。
主集群(AZ-A)
└── 业务写入 → 本地副本
备集群(AZ-B,独立 Keeper)
└── 通过 clickhouse-copier / 客户端双写同步
└── 每日快照备份到 S3
# 用 clickhouse-copier 做跨集群数据同步(官方工具)
clickhouse-copier --config /etc/clickhouse-copier/config.xml --task-id sync_task
| 架构要点 | 说明 |
|---|---|
| 副本路径 | 跨 AZ 的 ZooKeeper/Keeper 延迟高,避免把副本跨机房 |
| 双写 | 业务层同时写两个集群,容错靠客户端 |
| 异步同步 | copier 按 partition/part 搬运,适合日级对齐 |
| 备份 | 每个集群各自备份到独立 bucket |
7.3 远程磁盘(S3)与零拷贝
把数据直接落到 S3(storage_policy 冷盘或全 S3 表),配合 s3 磁盘 + 副本,可实现零拷贝复制:多个副本共享同一份 S3 对象,本地只存元数据,恢复时直接重新挂载。
8. 监控备份健康与总结
8.1 备份健康监控
# 每日凌晨跑备份的 cron,输出退出码与日志
0 1 * * * /usr/local/bin/clickhouse-backup create daily 2>&1 | tee /var/log/ch-backup.log
监控指标:
| 指标 | 健康信号 | 告警阈值 |
|---|---|---|
| 备份退出码 | 0 | 非 0 立即告警 |
| 备份大小 | 与增量预期相符 | 突增/突减都值得检查 |
| 最近备份时间 | 每日存在 | 超过 2 天无新备份告警 |
| 远端上传成功 | upload 成功 | 上传失败告警 |
| 恢复演练时长 | 达标 RTO | 超时告警 |
# 自动核对备份行数
clickhouse-backup tables daily
clickhouse-backup list
8.2 恢复演练清单
# 每月例行恢复演练(测试集群)
clickhouse-backup restore daily --tables=default.events
clickhouse-client --query "SELECT count() FROM default.events"
8.3 总结
| 主题 | 核心结论 |
|---|---|
| 备份边界 | 副本 ≠ 备份;DDL + 数据 + 权限都要备份 |
| FREEZE | 硬链接原子快照,秒级生成、近乎零占用 |
| clickhouse-backup | 生产标配,支持分区/增量/远端存储 |
| 原生 BACKUP | ON CLUSTER 一键备份,zip 落 S3 |
| 增量 | 24h 窗口自动增量,恢复时按链还原 |
| 演练 | 每周恢复一次,量化 RTO/RPO |
| 容灾 | 同机房副本 + 跨机房双集群 + S3 冷备三层 |
| 监控 | 退出码 + 大小 + 时效 + 演练四要素 |
「能恢复」才叫有备份。ClickHouse 备份的本质是 Part 快照 + 元数据还原,工具已经足够成熟——缺的往往是定期演练和远端副本。把备份当代码一样做版本管理和演练,才是真正的容灾。
继续阅读
探索更多技术文章
浏览归档,发现更多关于系统设计、工具链和工程实践的内容。