Backup：ClickHouse 数据如何备份恢复

做的事：真实备份一张表，真实DROP掉原表再恢复

代码BACKUP TABLE demo.threadtest TO Disk('backups', 'threadtest_backup1.zip'); SELECT count() FROM demo.threadtest; -- 备份前先记录真实的行数 DROP TABLE demo.threadtest; -- 真实删掉整张表 EXISTS demo.threadtest; -- 真实确认表已经不存在 RESTORE TABLE demo.threadtest FROM Disk('backups', 'threadtest_backup1.zip'); SELECT count() FROM demo.threadtest; -- 真实的数据找回来了吗

验证：真实DROP之后，RESTORE把数据完整找回来了

实测 · 本机执行输出

BACKUP TABLE ... → BACKUP_CREATED（真实生成135633字节的zip文件）

SELECT count() FROM demo.threadtest;  → 2000000
DROP TABLE demo.threadtest;
EXISTS demo.threadtest;               → 0   ← 真实表已经不存在了

RESTORE TABLE demo.threadtest FROM Disk('backups', 'threadtest_backup1.zip');
→ RESTORED

SELECT count() FROM demo.threadtest;  → 2000000   ← 真实分毫不差地找回来了

这是一次真实的、有真实破坏性动作(DROP TABLE)参与的完整验证——不是只测试BACKUP命令能不能跑通，而是真的把表删掉之后，确认RESTORE能不能把数据真实完整地找回来。

验证：真实的增量备份，文件大小比全量备份还小

实测 · 本机执行输出（插入50万行新数据后做增量备份）

INSERT INTO demo.threadtest SELECT ... FROM numbers(500000);   -- 真实新增50万行，总共250万行

BACKUP TABLE demo.threadtest TO Disk('backups', 'threadtest_backup2.zip')
SETTINGS base_backup = Disk('backups', 'threadtest_backup1.zip');

ls -la backups/
→ threadtest_backup1.zip   135633 字节   （200万行的全量备份）
  threadtest_backup2.zip    68884 字节   （250万行，但只是增量备份）

这组真实的字节数对比很有说服力：backup2真实代表的是250万行(比backup1的200万行更多)，但文件大小只有backup1的一半左右——因为base_backup参数真实告诉了ClickHouse"这次备份可以假设backup1已经存在"，只需要真实记录backup1创建之后新增/变化的那部分part(本文场景下就是新插入的50万行对应的part)，加上一份指向base_backup里已有part的引用清单，不需要把200万行的老数据再重新压缩打包一遍。真实的备份策略里，这套增量机制价值很直接：数据量越大、增量比例越小，全量备份的时间和存储成本就越不划算，本文这次验证的场景虽然增量占比不算小(新增50万/总250万，20%)，效果已经很明显，真实生产环境里"每天只新增1%数据"这类场景，增量备份能省下的空间和时间会更加可观。真实使用增量备份时要注意的一点是：backup2本身不是一份独立完整的备份，恢复它真实需要base_backup指向的backup1依然存在且完整，链条中任何一环丢失，依赖它的增量备份都无法真实完成恢复。

分步演示：从真实的DROP+RESTORE到增量备份的体积优势

每一步都是本文上面用真实BACKUP/RESTORE跑出来的原始结果。

真实DROP再RESTORE，数据分毫不差找回来

这一步新验证的动作

本文用到的工具

本机 ClickHouse 26.9.4（单节点），真实的 BACKUP TABLE / RESTORE TABLE 与 base_backup
真实包含破坏性的 DROP TABLE 动作，验证恢复的完整性而非只测试命令能否跑通

下一篇 · CLICKHOUSE 内部原理 90

冷热数据分层和存储策略