当前位置：首页 > news >正文

【Clickhouse从入门到精通】第53篇：ClickHouse数据备份方案全面解析

news 2026/6/4 3:50:59

上一篇【第52篇】ClickHouse熔断机制_系统过载保护策略
下一篇【第54篇】ClickHouse服务监控_系统表与监控指标体系

摘要

本文是《ClickHouse原理解析与应用实践》系列博客的第53篇文章，深入解析ClickHouse生态中的各类数据备份方案。与传统关系型数据库（如MySQL）相比，ClickHouse基于列式存储与MergeTree引擎架构，其备份策略的设计复杂度远超简单的逻辑导出——需要同时考虑数据分片、副本同步、增量备份、零丢失恢复等多个维度。本文将系统梳理ClickHouse 22.4+原生BACKUP/RESTORE命令、FREEZE PARTITION快照备份、第三方开源工具clickhouse-backup以及逻辑导出等多种方案，并通过对比表格与实战案例，帮助读者构建一套完整的ClickHouse数据保护体系。

关键词：ClickHouse备份、BACKUP RESTORE、FREEZE PARTITION、clickhouse-backup、S3、增量备份、快照备份

1. 引言

1.1 为什么ClickHouse备份比MySQL更复杂

在MySQL等传统关系型数据库中，数据通常以行式存储在独立的表空间中，备份方案（如mysqldump或XtraBackup）已经非常成熟，生态工具链丰富。然而，ClickHouse的设计哲学与上述系统存在本质差异，理解这些差异是制定有效备份策略的前提。

ClickHouse的数据存储具有以下特点：第一，数据按列压缩存储在多个*.bin文件中，每个列独立一个文件，数据按mark（标记）分组；第二，MergeTree引擎持续进行后台合并操作（merge），同一分区的多个数据部件（parts）会合并为更大的parts；第三，ClickHouse支持表级与数据库级的副本复制（ReplicatedMergeTree），备份过程中需要考虑副本间的一致性；第四，ClickHouse支持多种存储后端（本地磁盘、S3、HDFS、Azure Blob Storage），备份目标位置的选择直接影响恢复粒度和成本。

因此，ClickHouse的备份不能简单套用MySQL的经验，而需要根据数据规模、恢复时效要求、存储成本等因素综合选择方案。本文的第6节将给出各方案的对比分析，帮助读者做出决策。

2. BACKUP/RESTORE命令（ClickHouse 22.4+原生备份）

2.1 语法概述

从ClickHouse 22.4版本开始，官方引入了原生的BACKUP和RESTORE命令，这是迄今为止最完善的原生备份机制。相比之前的FREEZE方案，BACKUP/RESTORE支持增量备份粒度、原子性操作、细粒度表级控制，并且支持通过ON CLUSTER语法一次性备份整个集群。

基本语法如下：

-- 备份整个数据库BACKUPDATABASEdefaultTODisk('backup_disk','backup_name_20260519')-- 备份指定表BACKUPTABLEmydb.eventsTODisk('backup_disk','backup_name_20260519')-- 备份多个表BACKUPTABLEmydb.events,mydb.metricsTODisk('backup_disk','backup_name_20260519')-- 带密码加密的备份（24.3+新增功能）BACKUPTABLEmydb.eventsTODisk('backup_disk','backup_name_encrypted')SETTINGS password='secure_password_123'

恢复操作使用RESTORE命令：

-- 恢复到新表（默认行为，不覆盖已存在的表）RESTORETABLEmydb.eventsFROMDisk('backup_disk','backup_name_20260519')-- 恢复到指定位置RESTORETABLEmydb.eventsTOmydb.events_restoredFROMDisk('backup_disk','backup_name_20260519')-- 如果目标表已存在，可以替换RESTORETABLEmydb.eventsASmydb.events_restoredFROMDisk('backup_disk','backup_name_20260519')-- 恢复整个数据库RESTOREDATABASEdefaultFROMDisk('backup_disk','backup_name_20260519')

2.2 增量备份（BASE BACKUP语法）

原生BACKUP命令支持增量备份，这是通过BASE BACKUP参数实现的。首次全量备份后，后续增量备份只存储自上次备份以来发生变化的数据块，极大节省了存储空间和备份时间。

-- 第一次全量备份（BASE BACKUP）BACKUPDATABASEanalyticsTODisk('backup_disk','base_backup_v1')SETTINGS base_backup=NULL-- 表示这是全量基准备份-- 第二次增量备份BACKUPDATABASEanalyticsTODisk('backup_disk','incremental_backup_v2')SETTINGS base_backup=Disk('backup_disk','base_backup_v1')-- 第三次增量备份（基于前一次增量）BACKUPDATABASEanalyticsTODisk('backup_disk','incremental_backup_v3')SETTINGS base_backup=Disk('backup_disk','incremental_backup_v2')

增量备份的工作原理基于ClickHouse内部的数据块标识。每个MergeTree表的数据变更都会产生新的parts或对现有parts进行合并，base_backup参数告诉ClickHouse只备份那些在基准备份之后新产生或被修改的parts。这种方式对大型表的增量备份尤为有效——假设一张表有10亿行数据，其中只有100万行发生了变更，增量备份只需处理这100万行的数据块，而非整个10亿行。

2.3 备份元数据与数据文件

当执行BACKUP命令时，ClickHouse在备份目标位置生成以下结构：

backup_name_20260519/ ├── metadata/ -- 元数据目录 │ ├── default/ │ │ ├── events.sql -- 表结构DDL │ │ └── metrics.json -- 元信息 │ └── ... ├── data/ -- 数据目录 │ ├── default/ │ │ └── events/ -- 各表数据 │ │ ├── part_uuid_1/ │ │ │ ├── columns.bin │ │ │ ├── primary.idx │ │ │ ├── checksums.txt │ │ │ └── ... │ │ └── part_uuid_2/ │ └── ... └── .backup -- 备份元信息文件

需要注意的是，BACKUP命令会锁定被备份的表（通过ALTER TABLE ... LOCK），在备份期间对该表的写入操作会被暂时阻塞。对于高并发写入的生产环境，建议在业务低峰期执行备份，或使用副本机制在备副本上执行备份以避免影响主副本的写入性能。

2.4 ON CLUSTER 集群级备份

在生产环境中，ClickHouse通常以集群模式部署（Shard × Replica）。原生BACKUP命令支持ON CLUSTER子句，可以一次性对整个集群的所有节点执行一致的备份：

BACKUPDATABASEanalyticsONCLUSTER'default_cluster'TODisk('backup_disk','cluster_backup_20260519')SETTINGS async=true-- 异步执行，避免超时

执行ON CLUSTER备份时，ClickHouse会在每个分片上独立执行备份操作，并在协调节点（coordinator）记录全局的备份元数据。恢复时，同样可以使用ON CLUSTER将数据恢复到集群中：

RESTOREDATABASEanalyticsONCLUSTER'default_cluster'FROMDisk('backup_disk','cluster_backup_20260519')

3. FREEZE PARTITION（冻结快照备份）

3.1 FREEZE命令原理

ALTER TABLE ... FREEZE PARTITION是ClickHouse早期版本中提供的快照备份机制。虽然22.4+版本的原生BACKUP命令更为强大，但FREEZE方案在某些场景下仍有不可替代的价值——它直接操作底层存储文件，不需要额外的备份磁盘配置，可以与传统的文件系统快照工具（如LVM或ZFS快照）配合使用。

FREEZE操作的核心原理是：将指定分区的数据文件的硬链接（hard link）创建到/path/to/clickhouse/data/{database}/{table}/shadow/目录中。硬链接的特性保证了源文件与快照文件共享同一个inode，即使源文件被删除（随着数据合并被淘汰），快照中的文件依然保留。

-- 冻结指定分区ALTERTABLEmydb.events FREEZEPARTITION'2024-01'-- 冻结多个分区（使用通配符）ALTERTABLEmydb.events FREEZEPARTITION'2024*'-- 冻结所有分区ALTERTABLEmydb.events FREEZEPARTITION''-- 使用TTL删除旧数据后立即冻结ALTERTABLEmydb.events FREEZEPARTITION'2023-01'

3.2 shadow目录结构

执行FREEZE后，ClickHouse会在数据目录下创建shadow目录：

/var/lib/clickhouse/data/mydb/events/shadow/ ├── 1/ -- 快照序号，每次FREEZE递增 │ ├── data/ -- 快照数据 │ │ ├── default/ │ │ │ └── events/ │ │ │ ├── 20240101_20240101_100_100_0/ │ │ │ │ ├── checksums.txt │ │ │ │ ├── columns.bin │ │ │ │ ├── primary.idx │ │ │ │ ├── minmax_idx.idx │ │ │ │ └── ... │ │ │ └── ... │ └── metadata/ │ └── default/ │ └── events.sql └── ...

shadow目录中的数据格式与正常数据目录完全一致，这意味着可以直接使用ALTER TABLE ... ATTACH PARTITION将快照中的数据恢复到表中，或者通过简单的文件复制操作将快照迁移到其他服务器。

3.3 基于FREEZE的定期备份脚本

以下是一个生产环境中常用的基于FREEZE的定期备份脚本，它将FREEZE快照复制到备份目录，并自动清理过期快照：

#!/bin/bash# clickhouse_freeze_backup.shset-eCLICKHOUSE_HOST="${CLICKHOUSE_HOST:-localhost}"CLICKHOUSE_PORT="${CLICKHOUSE_PORT:-9000}"CLICKHOUSE_USER="${CLICKHOUSE_USER:-default}"CLICKHOUSE_PASSWORD="${CLICKHOUSE_PASSWORD:-}"DATA_PATH="/var/lib/clickhouse/data"BACKUP_BASE="/backup/clickhouse/shadow"RETENTION_DAYS=30TIMESTAMP=$(date+%Y%m%d_%H%M%S)# 创建当日备份目录BACKUP_DIR="${BACKUP_BASE}/${TIMESTAMP}"mkdir-p"${BACKUP_DIR}"# 数据库和表列表DATABASES_TABLES=("default.events""analytics.metrics""logs.access_log")fordb_tablein"${DATABASES_TABLES[@]}";dodb="${db_table%.*}"table="${db_table#*.}"echo"[$(date)] Freezing${db}.${table}..."# 执行FREEZE命令clickhouse-client\--host"${CLICKHOUSE_HOST}"\--port"${CLICKHOUSE_PORT}"\--user"${CLICKHOUSE_USER}"