扎兰多最近发表了一篇很好的文章，介绍了如何备份Kafka和zookeeper。Kafka备份一般有两种路径：
维护第二个kafka集群，所有主题都复制到该集群。我还没有验证这个设置，但是如果偏移主题也被复制，那么切换到另一个集群应该不会损害消费者的处理状态。
将主题转储到云存储，例如使用s3连接器（如zalando所述）。在恢复的情况下，您可以重新创建主题，并将云存储中的数据提供给主题。这将允许您进行时间点恢复，但使用者必须从头开始阅读主题。
首选的备份解决方案将取决于您的用例。e、 g.对于流媒体应用程序，第一种解决方案可能会给您带来更少的痛苦，而当使用kafka进行事件源时，第二种解决方案可能更可取。
关于zookeeper，kafka保存了关于主题的信息（持久存储），以及经纪人发现和领导人选举的信息（短暂的）。zalando决定使用burry，它简单地迭代zookeeper树结构，将其转储到文件结构，然后压缩它并推送到云存储。它有一个小问题，但很可能不会影响kafka持久数据的备份（todo verify）。zalando在那里描述，在恢复时，最好先创建zookeeper集群，然后连接一个新的kafka集群（使用新的、唯一的代理id），然后恢复burry的备份。burry不会覆盖现有的节点，也不会把关于旧代理的短暂信息，存储在备份中的内容。
注：虽然他们提到了参展商的使用，但在与burry备份时，其实并不需要备份。

apachekafka已经使您的数据保持分布式，并且还提供了强大的一致性复制功能。
首先，从体系结构设计的Angular 来看，我们需要了解备份对我们意味着什么？
是为了在数据中心故障中幸存下来吗？
正如您在评论中所说的，想象一下当您的整个数据中心都关闭时，意味着该数据中心中运行的所有东西都消失了，而不仅仅是Kafka。为了处理此类故障，您需要设计一种到不同数据中心的实时复制策略&您可以使用kafka mirror maker来实现这一点。您需要在不同的数据中心（不一定具有相同的硬件资源）中设置kafka群集，然后将当前的数据中心kafka配置为在另一个数据中心上镜像。
在数据中心范围内发生故障的情况下，您的所有服务都将从此回退数据中心运行，并且它们将使用镜像的kafka作为主kafka。
然后，一旦另一个数据中心回来了，您就可以用相反的方式设置镜像，然后您就可以来到您的旧（已销毁）数据中心。
它只是备份Kafka/Zookeeper的数据吗？
kafka connect有两个现成的连接器，用于从kafka传输具有一致性保证的数据。因此，也许您可以选择awss3作为备份存储，下面的连接器可以为您做到这一点。
汇合aws s3连接器。
pinterest提供secor服务，将数据传输到aws s3、google和mircosoft云存储。我相信你也可以找到一些专门的连接器为所有的大型云供应商。在将kafka数据备份到高可用云存储时，需要考虑的事项很少。
kafka对每个主题都有一个数据保留策略，因此旧数据将由kafka自己从kafka服务器中删除，但它仍将保留在您的aws s3存储桶中，因此，如果您在发生还原事件时直接将其复制回来，那么您将在kafka代理上看到更多的数据，而且将整个数据还原到现有正在运行的kafka集群中也不是一个好主意，因为这样您将开始处理旧数据。所以在这个过程中要有选择性和谨慎
对于zookeeper，您也可以将数据复制到awss3，但由于节点短暂，因此在恢复时需要小心。我发现了一些可以提供帮助的链接：
https://jobs.zalando.com/tech/blog/backing-up-kafka-zookeeper/https://www.elastic.co/blog/zookeeper-backup-a-treatisehttps：//medium.com/@pinterest\u engineering/zookeeper-resility-at-pinterest-adfd8acf2a6b
最后，“预防胜于治疗”。因此，如果您运行在像aws这样的云提供商设置中，那么您可以通过预先考虑故障来部署集群设置。下面的链接有一些信息。
https://aws.amazon.com/blogs/big-data/best-practices-for-running-apache-kafka-on-aws/