恢复方案
复制失败
到目前为止，单个服务器或节点的故障是生产中最常见的灾难情况。在几乎所有情况下，都应替换发生故障的副本并重新创建架构。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！
