在ClickHouse生产运维中，绝大多数团队都会遇到同一个痛点：每日全量备份体积大、耗时长、占用大量带宽和存储资源。

ClickHouse作为列式存储数据库，数据量动辄几十GB、上百GB，如果长期执行每日全量备份，不仅备份耗时长达数十分钟，远程存储成本也会持续堆积，造成资源严重浪费。

针对这个问题，最佳解决方案就是基于基准全量的增量备份策略。本文给大家分享一套生产可用、零级联风险、自带清理+告警+定时任务的 clickhouse-backup 增量备份完整方案，无需反复踩坑，复制即可落地。

一、方案核心优势（为什么不用普通增量？）

市面上很多CK增量方案存在致命缺陷：增量层层依赖，链条断裂全部报废，只要某一天增量备份损坏，后续所有备份都无法恢复，生产风险极高。

本次落地方案采用固定全量基准+每日增量的核心设计，彻底规避级联风险：

• 备份安全：所有增量均基于每周固定全量基准，不依赖上一次增量，杜绝链条雪崩问题

• 极致省资源：仅备份新增/变更的data parts，备份体积从GB级压缩至MB级

• 速度大幅提升：全量备份数十分钟，增量备份仅需1-10分钟

• 全自动运维：自带微信告警、过期备份清理、本地缓存自动删除

• 恢复可靠：恢复逻辑清晰，先基准全量、后叠加增量，数据零丢失

二、核心原理讲解

本方案基于 clickhouse-backup --diff-from-remote 官方差异备份参数实现，核心逻辑如下：

工具会自动对比远程基准全量备份与当前数据库的数据part，仅上传新增、修改的数据分片，完全跳过未变动内容，从底层实现真正的高效增量备份。

同时搭配关键配置 freeze_by_part: true，开启Part级别快照对比能力，这是增量备份能够精准生效的必要前置条件，缺一不可。

三、生产级备份策略设计

采用「周度全量基准 + 日度增量更新」的黄金备份组合，兼顾数据安全性、存储成本和恢复效率。

备份类型	执行周期	核心逻辑	执行命令
全量基准备份	每周日 00:00	生成全局基准备份，作为一周所有增量的依赖基础，覆盖全库数据	create + upload
日常增量备份	周一至周六 00:00	基于周日全量基准，仅备份当日变更数据，无层级依赖	create + upload --diff-from-remote

核心亮点：所有增量均直连全量基准，不接力上一日增量，彻底规避增量链条损坏、断层无法恢复的生产事故。

四、完整落地步骤（从零部署）

步骤1：修改核心配置（增量必备）

修改 clickhouse-backup 主配置文件，开启Part级冻结对比，否则增量备份失效、数据对比异常：

clickhouse: 
  freeze_by_part: true # 必须开启！增量备份核心依赖配置

步骤2：初始化远程基准备份目录

在远程备份服务器创建专属基准目录，用于存放每周全量基准备份，统一管理备份链路：

ssh root@110.12.117.121 "mkdir -p /home/data_dev/clickhouse_backup/base/"

步骤3：部署全自动备份脚本（核心）

在业务服务器创建脚本 /home/tools/clickhouse_backup_incremental.sh，整合全量/增量自动判断、微信告警、日志记录、本地清理等全能力：

#!/bin/bash
export PATH=/usr/local/bin:/usr/bin:/bin:$PATH
# ===== 通用配置 =====
. /home/tools/wechat_notify.sh
SERVER_IP=$(hostname -I | awk '{print $1}')
REMOTE_IP="147.126.112.160"
# 远程全量基准标记文件
BASE_MARKER="/home/data_dev/clickhouse_backup/base/.last_full_backup"
# 本地增量追踪文件，记录最新全量基准
LOCAL_TRACKER="/home/tools/.ck_incremental_tracker"

# 时间参数
DOW=$(date +%u) # 1=周一 7=周日
TIMESTAMP=$(date +%Y-%m-%dT%H-%M-%S)
START_TIME=$(date +%s)

# ====================== 周日：执行全量基准备份 ======================
if [ "$DOW" -eq 7 ]; then
 BACKUP_NAME="full_global_backup_${TIMESTAMP}"
 # 本地创建全量备份
 /usr/local/bin/clickhouse-backup create -t webfunny_cloud_db.* $BACKUP_NAME
 if [ $? -ne 0 ]; then
 send_wechat "国内CK全量备份失败❌" "服务器IP：${SERVER_IP}\n备份名称：${BACKUP_NAME}\n阶段：本地创建全量备份失败"
 exit 1
 fi
 # 上传至远程存储
 /usr/local/bin/clickhouse-backup upload $BACKUP_NAME
 UPLOAD_CODE=$?
 if [ ${UPLOAD_CODE} -eq 0 ]; then
 # 本地、远程双记录最新全量基准
 echo "$BACKUP_NAME" > "$LOCAL_TRACKER"
 ssh root@${REMOTE_IP} "echo '$BACKUP_NAME' > ${BASE_MARKER}"
 fi

# ====================== 周一~周六：执行增量备份 ======================
else
 # 校验是否存在全量基准备份
 if [ ! -f "$LOCAL_TRACKER" ]; then
 send_wechat "国内CK增量备份失败❌" "服务器IP：${SERVER_IP}\n原因：未找到全量基准备份记录，请先执行一次全量备份"
 exit 1
 fi
 BASE_BACKUP=$(cat "$LOCAL_TRACKER")
 BACKUP_NAME="inc_global_backup_${TIMESTAMP}"

 # 本地创建增量备份
 /usr/local/bin/clickhouse-backup create -t webfunny_cloud_db.* $BACKUP_NAME
 if [ $? -ne 0 ]; then
 send_wechat "国内CK增量备份失败❌" "服务器IP：${SERVER_IP}\n备份名称：${BACKUP_NAME}\n阶段：本地创建增量备份失败"
 exit 1
 fi

 # 基于远程全量基准，增量上传差异数据
 /usr/local/bin/clickhouse-backup upload \
 --diff-from-remote "$BASE_BACKUP" \
 $BACKUP_NAME
 UPLOAD_CODE=$?
fi

# ====================== 耗时统计 ======================
END_TIME=$(date +%s)
COST_SEC=$((END_TIME - START_TIME))
COST_H=$((COST_SEC / 3600))
COST_M=$(((COST_SEC % 3600) / 60))
COST_S=$((COST_SEC % 60))
TIME_TEXT="${COST_H}时${COST_M}分${COST_S}秒"

# ====================== 微信结果告警 ======================
if [ ${UPLOAD_CODE} -eq 0 ]; then
 send_wechat "ClickHouse备份成功✅" "源服务器IP：${SERVER_IP} → 目标：${REMOTE_IP}\n备份名称：${BACKUP_NAME}\n类型：$([ "$DOW" -eq 7 ] && echo '全量基准' || echo '增量(基准:'${BASE_BACKUP}')')\n总耗时：${TIME_TEXT}"
else
 send_wechat "国内CK远端上传失败❌" "源服务器IP：${SERVER_IP} → 目标：${REMOTE_IP}\n备份名称：${BACKUP_NAME}\n本地备份完整，SFTP远端上传失败"
 exit 1
fi

# ====================== 清理本地备份缓存 ======================
rm -rf /var/lib/clickhouse/backup/$BACKUP_NAME

步骤4：配置自动过期清理策略

备份长期堆积会占用远程存储，在脚本末尾追加每周清理策略，自动删除超期备份，保留近7天可用备份，兼顾安全与存储成本：

# ===== 每周三定时清理14天前过期备份 =====
if [ "$DOW" -eq 3 ]; then
 # 筛选远程老旧备份并删除，保留最近7天备份
 OLD_BACKUPS=$(docker exec clickhouse-server clickhouse-backup list remote 2>/dev/null | awk '{print $1}' | grep -E '^(full_|inc_)' | head -n -7)
 for OLD in $OLD_BACKUPS; do
 docker exec clickhouse-server clickhouse-backup delete remote "$OLD" 2>/dev/null
 done
fi

步骤5：配置定时任务，全自动执行

配置crontab定时任务，每日凌晨自动执行备份，全程无人值守：

00 00 * * * PATH=/usr/local/bin:/usr/bin:/bin /bin/bash /home/tools/clickhouse_backup_incremental.sh > /home/tools/backup_incremental.log 2>&1

五、增量备份标准恢复流程

增量备份恢复遵循先基准、后增量的原则，先恢复周度全量备份，再叠加当日增量变更，数据可完整还原：

# 1、恢复基准全量备份（本周周日备份）
clickhouse-backup download full_global_backup_2026-06-21T00-00-01
clickhouse-backup restore full_global_backup_2026-06-21T00-00-01 -t "webfunny_cloud_db.*" --rm

# 2、叠加恢复对应日期增量备份
clickhouse-backup download inc_global_backup_2026-06-22T00-00-01
clickhouse-backup restore inc_global_backup_2026-06-22T00-00-01 -t "webfunny_cloud_db.*" --rm

六、方案落地效果对比

落地该增量方案后，备份效率和存储成本得到质的优化，实测数据如下：

指标	全量备份方案	本文增量方案
单份备份大小	约1.2GiB	几十~几百MiB
单次备份耗时	20~60分钟	1~10分钟
每周总存储占用	7份全量 ≈ 8.4GiB	1份全量+6份增量 ≈ 3~4GiB
数据恢复风险	低（单步恢复）	极低（无层级依赖）

七、生产关键注意事项

• 连通性校验：--diff-from-remote 依赖远程SFTP连通性，容器化部署需提前确认容器内可正常访问远程备份服务器

• 配置必开：freeze_by_part: true 是增量备份生效核心，关闭后无法实现Part级别差异对比，增量等同于全量

• 基准不断层：每周日全量备份必须执行成功，否则后续一周增量备份全部失效

• 定期演练：每月至少一次备份恢复演练，验证备份文件可用性，避免备份失效无人发现

• 日志监控：定期查看备份日志，结合微信告警，及时发现备份失败、上传超时等异常

八、方案总结

这套 clickhouse-backup 周全量+日增量 生产方案，解决了传统全量备份臃肿、耗时久、成本高，以及普通增量备份链条易断裂的双重痛点。

方案具备高安全、低成本、全自动、易恢复的特点，适配绝大多数生产环境，无需二次开发，直接复制配置、脚本即可落地，是ClickHouse大数据集群运维的最优备份方案之一。

Webfunny全链路监控埋点平台是一站式前端监控 + 用户行为埋点 + 大数据分析平台，天然适配点位细查、用户行为回溯、批量导出等场景：

一体化架构：监控 + 埋点同一套 SDK，数据互通无壁垒
私有化部署：数据完全本地化，满足企业合规要求
高吞吐支撑：基于 ClickHouse 构建，亿级日志秒级查询
全端覆盖：H5 / 小程序 / APP / 鸿蒙全覆盖，统一导出口径
可定制强：支持接口扩展、分布式锁、限流降级等企业级能力