我们正在开发一种备份和恢复Marklogic数据库的解决方案。 以下是要求
我们需要以我们自己支持的格式进行完整和增量备份
粒度级别的数据库恢复
我们想避免备份暂存位置，以提高性能并节省存储空间
我们考虑以下策略
文件系统快照-
我们可以将目录林置于闪存备份模式，并进行FS快照并将数据移至我们的备份解决方案。 您是否在这种方法中看到任何一致性问题？同样，增量备份在这里也面临挑战。有任何评论吗？
MLCP
我们正在考虑通过MLCP导出数据库的选项。我们看到mlcp支持快照，因此我们可以在此处导出一致的时间点备份。
使用MarkLogic的REST API备份
Marklogic具有自己的备份API，可在暂存位置写入。有什么方法可以避免暂存位置？
以上哪种解决方案最适合我们的要求？请提出其他可用的方法。
答案 0 :(得分：1)
您能否以“我们自己支持的格式”进行扩展。 除“ b”外，其他所有内容均与“我们自己的格式”不兼容（除非您的格式只是容器格式）
我不建议将文件系统备份用于正常的“数据库备份”操作。存在未提交的事务等问题，但是这些问题是可以恢复的-更大的问题是您要备份的内容以及您打算如何处理的选择性。 如果您想还原故障的系统，则FS备份很好-这是AWS标准配置（EBS卷）所使用的-尽管最好先关闭服务器，但这总是最好的。文件系统备份不会非常轻松地为您提供增量备份，实际上，由于合并的工作方式，备份文件适得其反。
还需要考虑几个数据集-正常的“数据库数据”，配置文件，任何操作系统，环境变量，启动参数等。 非常重要的是，该主机名在多个位置使用-请勿将fileystem备份复制到其他主机并不更改其运行状态-更糟糕的情况是，如果该文件位于同一子网上，则有可能将这样的“克隆”服务器启动到原始服务器中当您希望将其独立时将其群集。
将哪个带入群集-根据您的用例，您可能会或可能不希望整体备份群集。
推荐的解决方案类似于其他应用程序备份的相同问题-查看备份的目的，这通常是某种还原... A）恢复整个失败的群集--- FS快照是一个不错的开始，但应随附数据库级备份。 B）恢复发生故障的节点-只是该节点的配置以及所有附加的存储 C）恢复“数据库”-使用内置的API来运行备份和增量。 D）恢复失败的卷-使用复制 E）恢复单个文件-使用mlcp或类似文件备份文档。
注意：“数据库”不仅包含文档，还包括文档（集合，权限，用户，锁，属性文件等）。
为了完全保真，我建议针对所有用例使用内置的备份/还原
A）您真正只想还原“普通文件”的位置-
B）分布式备份-考虑使用外部群集将数据卸载到非生产群集并从那里进行备份。
与其他应用一样，我还建议将文件系统快照和数据库级备份结合使用。他们解决了不同的问题-
至于“不分阶段”-您是什么意思？分期是数据去向的地方–它必须去某个地方。您可以备份到AWS S3或网络存储-您可以定义目标位置，但目标必须是 something
答案 1 :(得分：0)
首先感谢您的投入。 您可以在下面的声明中详细说明吗？这确实可以为我们提供我们正在考虑的备份解决方案。 您可以备份到AWS S3或网络存储-您可以定义目标位置
如果有任何意见可以更好地备份和恢复解决方案，也请进行更新。
- 阿比舍克