数据备份是IT运营中不可或缺的重要部分。在“大数据”部署（例如分析数据库）中，它们最具挑战性。本文将探讨备份ClickHouse所涉及的管道，并介绍用于自动化过程的Clickhouse备份工具。
ClickHouse内置的本机复制支持可提供高可用性和针对单个节点故障的弹性。但是，极少数的灾难情况可能需要从备份中恢复数据。其中包括数据损坏以及分片或群集中所有副本的故障。
任何ClickHouse备份方案的关键组成部分都是“冻结”表。与所有数据库一样，一致的备份取决于ClickHouse处于“静默”状态。ClickHouse不必完全停止数据库，而对“冻结”表进行备份或迁移提供了本机支持。这是无停机时间的操作。
四个简单步骤中的手动备份
ClickHouse通过其 ALTER TABLE…FREEZE 功能提供了对即时时间点备份的本地支持。
- 确认您的影子目录为空：
ls /var/lib/clickhouse/shadow/ - 冻结ClickHouse 数据表：
echo -n 'alter table events freeze' | clickhouse-client 如果发生灾难，请保存备份：
cd /var/lib/clickhouse/ sudo mkdir backup sudo cp -r shadow/ backup/my-backup-name- 最后，为下次清理备份源：
sudo rm -rf /var/lib/clickhouse/shadow/*
ClickHouse使用文件系统硬链接来实现即时备份，而不会导致ClickHouse服务停机（或锁定）。这些硬链接可以进一步用于有效的备份存储。在支持硬链接的文件系统（例如本地文件系统或NFS）上，将cp与-l标志一起使用（或将rsync与–hard-links和–numeric-ids标志一起使用）以避免复制数据。
当使用硬链接时，磁盘上的存储效率更高。因为它们依赖于硬链接，所以即使避免了重复使用磁盘空间，每个备份实际上都是“完整”备份。
测试您的备份
正确地说，如果未测试还原过程，则备份毫无价值。执行常规的测试还原，以确保您的数据在需要时就在那里。
以下是手动恢复的步骤：
- 删除测试表，或找到其他服务器进行测试。
- 创建测试表以进行恢复：
cat events.sql | clickhouse-client 将您的备份复制到表的“ detached”目录中：
cd /var/lib/clickhouse sudo cp -rl backup/my-backup-name/* data/default/events/detached/- 附上分离的零件：
echo 'alter table events attach partition 202006' | clickhouse-client - 确认您的数据已还原：
echo 'select count() from events' | clickhouse-client
使用以下方式自动化备份过程 clickhouse-backup
由Alex Akulov创建的clickhouse-backup工具有助于自动化上述手动步骤：https : //github.com/AlexAkulov/clickhouse-backup。我们喜欢clickhouse-backup，并实现了一些新功能，在此首次进行介绍。
要开始使用，您需要安装clickhouse-backup。完整说明位于ReadMe.md文件中。这是从tarball安装的示例。还提供了RPM，Debian软件包和Docker映像。
wget https://github.com/AlexAkulov/clickhouse-backup/releases/download/v0.6.3/clickhouse-backup.tar.gz
tar -xf clickhouse-backup.tar.gz
cd clickhouse-backup/
sudo cp clickhouse-backup /usr/local/bin
clickhouse-backup -v此博客文章中介绍的API功能和新的存储选项（例如'remote_storage'）尚未在正式版本中提供。您需要从源代码构建或运行最新的docker映像。这是后者的一个例子。
docker run --rm -it --network host
-v "/var/lib/clickhouse:/var/lib/clickhouse"
-e CLICKHOUSE_PASSWORD="password"
-e S3_BUCKET="clickhouse-backup"
-e S3_ACCESS_KEY="access_key"
-e S3_SECRET_KEY="secret"
alexakulov/clickhouse-backup:master --help对于本文的其余部分，我们假定您具有一个具有新功能的内部版本。在命令行上使用Clickhouse-backup时，需要配置文件。这是一个最小的示例。
$ cat /etc/clickhouse-backup/config.yml
general:
remote_storage: none您将需要为非默认的ClickHouse安装或身份验证添加其他配置选项。可以通过运行来创建完整的配置示例clickhouse-backup default-config。这是您使用的一个很好的起点，它显示了所有可用的设置。
配置完成后，clickhouse-backup将提供各种用于管理备份的子命令。
$ clickhouse-backup help
NAME:
clickhouse-backup - Tool for easy backup of ClickHouse with cloud support
...
COMMANDS:
tables Print list of tables
create Create new backup
upload Upload backup to remote storage
list Print list of backups
download Download backup from remote storage
restore Create schema and restore data from backup
delete Delete specific backup
default-config Print default config
freeze Freeze tables
clean Remove data in 'shadow' folder
server Run API server
help, h Shows a list of commands or help for one command就像上面的手动备份示例一样，您将需要以Clickhouse用户身份使用sudo或运行clickhouse-backup。
该配置文件允许忽略某些数据库或表。该tables子命令将向您显示要备份的表：
$ clickhouse-backup tables
default.events
system.metric_log (ignored)
system.query_log (ignored)
system.query_thread_log (ignored)
system.trace_log (ignored)创建备份非常简单：
$ sudo clickhouse-backup create
2020/07/06 20:13:02 Create backup '2020-07-06T20-13-02'
2020/07/06 20:13:02 Freeze `default`.`events`
2020/07/06 20:13:02 Skip `system`.`metric_log`
2020/07/06 20:13:02 Skip `system`.`query_log`
2020/07/06 20:13:02 Skip `system`.`query_thread_log`
2020/07/06 20:13:02 Skip `system`.`trace_log`
2020/07/06 20:13:02 Copy metadata
2020/07/06 20:13:02 Done.
2020/07/06 20:13:02 Move shadow
2020/07/06 20:13:02 Done.如您在上面的示例中看到的，备份在同一秒内完成。
您可以查看现有的本地备份：
$ sudo clickhouse-backup list
Local backups:
- '2020-07-06T20-13-02' (created at 06-07-2020 20:13:02)注意，出于性能原因，本地备份不计算“大小”。
clickhouse-backup如上所述，在内部尽可能使用硬链接。备份存储在中/var/lib/clickhouse/backup/BACKUPNAME。备份名称默认为时间戳，但是您可以选择使用–name标志指定备份名称。备份包含两个目录：一个“元数据”目录，其中包含重新创建架构所需的DDL SQL语句；以及一个“影子”目录，其中包含作为ALTER TABLE ... FREEZE操作结果的数据。
从备份还原也很容易。例如：
$ echo 'drop table events' | clickhouse-client
$ sudo clickhouse-backup restore 2020-07-06T20-13-02
2020/07/06 20:14:46 Create table `default`.`events`
2020/07/06 20:14:46 Prepare data for restoring `default`.`events`
2020/07/06 20:14:46 ALTER TABLE `default`.`events` ATTACH PART '202006_1_1_4'
2020/07/06 20:14:46 ALTER TABLE `default`.`events` ATTACH PART '202006_2_2_2'
2020/07/06 20:14:46 ALTER TABLE `default`.`events` ATTACH PART '202006_3_3_3'
2020/07/06 20:14:46 ALTER TABLE `default`.`events` ATTACH PART '202006_4_4_3'
2020/07/06 20:14:46 ALTER TABLE `default`.`events` ATTACH PART '202006_5_5_2'
2020/07/06 20:14:46 ALTER TABLE `default`.`events` ATTACH PART '202006_6_6_1'该restore 子命令自动模式和数据恢复。如果只想还原架构，请使用可选--schema标志。或者，如果只想还原数据（假设架构已存在），则可以使用该--data标志。后一种情况在还原到已经具有现有数据的服务器时特别有用。
另一个有用的功能是支持使用大多数命令（例如创建和还原）指定表模式。该--table参数允许您备份（或还原）特定表。你也可以使用一个正则表达式，例如，针对特定的数据库：--table=dbname.*。
远程备份目标
当然，您可以将备份同步到远程目标，将其保存到S3之类的对象存储中，或使用现有的备份解决方案对其进行存档。本地存储通常不足以满足数据持久性要求。
clickhouse-backup工具支持从远程对象存储（例如S3，GCS或IBM COS）上载和下载备份。最小的AWS S3配置如下所示：
s3:
access_key:
secret_key:
bucket:
region: us-east-1
path: "/some/path/in/bucket" 配置clickhouse-backup完凭据和目标存储段后，即可完成其余工作：
$ clickhouse-backup upload 2020-07-06T20-13-02
2020/07/07 15:22:32 Upload backup '2020-07-06T20-13-02'
2020/07/07 15:22:49 Done.
The remote backup can be downloaded to local storage before restoration:
$ sudo clickhouse-backup download 2020-07-06T20-13-02
2020/07/07 15:27:16 Done.该clickhouse-backup配置文件支持backups_to_keep_local 和backups_to_keep_remote 设置-调整它们以满足数据保留要求。例如，set backups_to_keep_local: 7并且backups_to_keep_remote: 31保留了一周的夜间备份的本地和一个月的远程控制。将两者都设置为0可禁用备份修剪。
--diff-fromupload子命令也有一个选项。此功能将文件与以前的本地备份进行比较，仅上载新的/更改的文件。必须保留先前的备份，以便从新备份中进行还原。
数据传输时间和成本是远程存储的关键方面。将大表还原到新服务器需要多长时间？这将在很大程度上取决于网络和存储带宽。测试各种恢复方案以充分了解故障中可以实现的恢复时间至关重要。如果您使用公共云，则成本管理将非常重要。
使用Clickhouse-backup API
最后，clickhouse-backup可以作为提供REST API的服务运行。这是一个新功能。该API反映了命令行命令和选项，并且可能是与现有调度或CI / CD系统集成的更方便的方法。
$ sudo clickhouse-backup server &
$ curl localhost:7171/backup/list
{"Type":"local","Name":"2020-07-06T20-13-02","Size":0,"Date": "2020-07-06T20:13:02.328066165Z"}可以在以下位置找到API端点的文档：https : //github.com/AlexAkulov/clickhouse-backup#api
clickhouse-backup在生产中使用
重要的是要注意的已知限制clickhouse-backup，在此处记录了这些限制：https : //github.com/AlexAkulov/clickhouse-backup#limitations
此外，文档还包含以下重要警告：
切勿在中更改文件权限/var/lib/clickhouse/backup。此路径包含硬链接。磁盘上相同数据的所有硬链接上的权限始终相同。这意味着，如果您更改备份路径中硬链接上的权限/所有者/属性，与ClickHouse一起使用的文件的权限也将更改。这可能会导致数据损坏。
恢复方案
复制失败
到目前为止，单个服务器或节点的故障是生产中最常见的灾难情况。在几乎所有情况下，都应替换发生故障的副本并重新创建架构。ClickHouse的本机复制将接管并确保替换服务器是一致的。此故障场景值得进行事先测试，以了解网络并计算重建新副本的影响。
碎片失败
在群集环境中，每个分片至少应备份一个副本。该clickhouse-backupAPI是在集群编排备份命名和执行一种方法。
如果一个分片中的所有副本都失败了，或更常见的是，数据已损坏，则必须如上所述从备份中还原整个分片。理想情况下，将备份还原到一个副本，将架构还原到其他副本，并允许ClickHouse的本机复制接管。
集群失败
完全故障的群集，无论是由于基础架构故障还是数据损坏，都可以通过与故障的碎片相同的方式进行恢复。必须通过上述过程恢复每个单独分片中的一个副本。
备用备份策略
具有文件系统快照的脱机副本
一种常见的替代方法是使用“脱机副本”进行备份。配置了副本（通常在另一个区域），该副本不作为任何分布式表的一部分用于查询。“离线副本”不打算进行任何合并，可以使用“ always_fetch_merged_part”和“ replica_can_become_leader” ClickHouse MergeTree设置来指定。虽然生产副本最好由ext4文件系统提供服务，但是备份副本使用ZFS（或支持快照的另一个文件系统）。这种方法提供了快速的恢复过程。请注意，在这种情况下，备份仍在服务器/节点本地，并且不一定提供足够的数据持久性。ZFS提供了对单个快照的基于目录的文件系统访问，因此可以将这些快照的存储自动化到远程系统或对象存储中。
带快照的存储即服务
云部署通常使用基于网络的块存储（例如AWS EBS或GCP永久磁盘）。为此，某些本地部署使用Ceph或OpenEBS。这些“存储即服务”技术均支持透明的卷快照。通过首先冻结表以进行备份，然后创建快照，您可以实现近乎即时的备份。
在内部，快照仅在磁盘上存储自上次快照以来已更改的块。这些系统虽然不是真正的“增量”备份，但可以高效利用磁盘空间。注意基于网络的块存储很少具有与本地磁盘一样的性能，并确保监视快照的保留和成本。
使用Kafka改善备份
到目前为止，我们已经讨论了按小时或每小时创建的特定时间点备份（例如）。一些组织要求能够恢复到任意时间点。由于ClickHouse没有本地二进制日志（例如Postgres WAL），因此自上次特定时间点备份以来，还需要某种其他机制来“重播”数据。
许多组织使用Kafka来满足此要求。通过Kafka将数据流传输到ClickHouse具有可用性和容错能力方面的许多优势。另一个优点是能够将摄取重置为Kafka分区中的任何偏移量。执行时间点备份时，必须存储Kafka偏移量。在恢复期间，ClickHouse Kafka Engine配置会在创建备份时设置为Kafka偏移量，并且将提取该时间点之后的数据。
存储Kafka偏移量的一种简单方法是将它们插入到备份中包含的ClickHouse中的表中。这可以在包装脚本中完成，该脚本暂停从Kafka的摄取，写入当前主题分区偏移量，开始备份，然后再次启用摄取。还原数据时，可以重置使用者组的偏移量，然后重新启用摄取。有关重置偏移量的示例，请参见此博客上的ClickHouse Kafka引擎教程。
下一步
在深入研究并实施备份解决方案之前，请花点时间思考一下您的业务和最终用户的需求。充分了解环境的恢复时间目标（RTO）和恢复点目标（RPO）。然后，考虑上面概述的方法以确定最合适的方法。
ClickHouse的最大优势之一就是多元化和投资社区的支持和贡献。Clickhouse备份提供的自动化也不例外：非常感谢Alex Akulov！