备份恢复与容灾

系统讲解 ClickHouse 备份恢复与容灾:FREEZE/DETACH 文件级备份原理、clickhouse-backup 工具与配置、增量备份、分布式集群多节点备份、DROP TABLE 后的恢复演练,以及副本/跨机房容灾架构与备份健康监控。

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 的原理:

  1. 为每个 active Part 建立硬链接(不是拷贝),不占额外磁盘;
  2. 硬链接目录复制到 /var/lib/clickhouse/shadow/N/;
  3. 后续的写入/合并生成新 Part,不影响快照;
  4. 只有手动删除 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 原生 BACKUPClickHouse 协调服务端统一打包,易落地

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

恢复内部流程:

  1. 读取备份元数据,重建 CREATE TABLE DDL;
  2. 拷回 Parts 到数据目录;
  3. ATTACH 挂载(不重新导入,直接挂目录);
  4. 校验行数是否与备份一致。
-- 恢复后校验
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 跨机房

层级手段RTORPO成本
同机房副本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生产标配,支持分区/增量/远端存储
原生 BACKUPON CLUSTER 一键备份,zip 落 S3
增量24h 窗口自动增量,恢复时按链还原
演练每周恢复一次,量化 RTO/RPO
容灾同机房副本 + 跨机房双集群 + S3 冷备三层
监控退出码 + 大小 + 时效 + 演练四要素

「能恢复」才叫有备份。ClickHouse 备份的本质是 Part 快照 + 元数据还原,工具已经足够成熟——缺的往往是定期演练和远端副本。把备份当代码一样做版本管理和演练,才是真正的容灾。

继续阅读

探索更多技术文章

浏览归档,发现更多关于系统设计、工具链和工程实践的内容。

全部文章 返回首页

「数据库」更多文章

  1. 权限与安全加固
  2. Kafka 引擎与实时管道
  3. 查询优化器与执行引擎深入