MarkLogic—开发第三方备份和恢复解决方案

我们正在开发一种用于备份和恢复Marklogic数据库的解决方案。 以下是要求

• 我们需要以自己支持的格式进行完整和增量备份

• 在粒度级别恢复数据库

• 我们希望避免备份暂存位置，以提高性能并节省存储

我们考虑以下策略

• 文件系统快照-
  我们可以将林设置为闪存备份模式，拍摄FS快照并将数据移动到我们的备份解决方案中。 您认为这种方法存在一致性问题吗？此外，增量备份在这里也是一个挑战。有什么评论吗

• MLCP
  我们正在考虑通过MLCP导出数据库的选项。我们看到mlcp支持快照，所以我们可以在这里导出一致的时间点备份

• 使用MarkLogic的RESTAPI进行备份
  Marklogic有自己的用于备份的API，该API在暂存位置写入。有没有办法避免中转位置

以上哪种解决方案最适合我们的要求？请建议任何其他可用的方法。

您是否可以扩展到“我们自己支持的格式”。 除了“b”之外，其他所有格式都与“我们自己的格式”不兼容（除非您的格式只是容器格式）

我不建议将文件系统备份用于正常的“数据库备份”操作。存在未提交的事务等问题，但这些事务是可恢复的——更大的问题是备份内容的选择性以及打算如何使用它。 如果您想恢复故障系统，那么FS备份就可以了——这是AWS标准配置（EBS卷）所使用的备份方式——尽管最好先关闭服务器。文件系统备份不会让您很容易地实现增量备份，事实上，由于合并的工作方式，它会适得其反

还有几个数据集要考虑——正常的“数据库数据”、配置文件、任何操作系统、环境变量、启动参数等。 非常重要的是，主机名用于多个位置—不要将文件系统备份复制到不同的主机上，并在不更改的情况下运行它们—更糟糕的情况是，如果它位于同一子网中，则当您希望它是独立的时，可能会将这样的“克隆”服务器启动到原始群集中

这就带来了集群——根据您的使用情况，您可能想备份整个集群，也可能不想备份整个集群

推荐的解决方案与其他应用程序备份中的相同问题类似——请查看备份的意图，这通常是某种恢复。。。 A） 恢复整个失败的集群——FS快照是一个良好的开端，但应该伴随数据库级备份。 B） 恢复故障节点--仅恢复该节点的配置，以及所有连接的存储 C） 还原“数据库”——使用内置API运行备份和增量。 D） 还原失败的卷--使用复制 E） 恢复单个文件--使用mlcp或类似工具备份文档

注意：“数据库”不仅仅由文档组成（集合、权限、用户、锁、属性文件等）。
为了获得完全的保真度，我建议对所有用例使用内置备份/恢复，但 A） 您只需要恢复“普通文件”即可-- B）分布式备份——考虑使用外部集群将数据卸载到非生产集群并从那里备份。 我还建议，与其他应用程序一样，将文件系统快照和数据库级备份结合使用。它们可以解决不同的问题--

至于“没有登台”——你是什么意思？登台就是数据去的地方——它必须去某个地方。你可以备份到AWS S3或网络存储——你可以定义目标在哪里，但它必须是某种东西