我们正在考虑build立一个维基或CMS供IT部门内部使用。 我们想要使用它的一件大事就是灾难恢复程序。
鉴于诸如电力或networking中断等灾难可能导致维基百科无法访问，将维基托pipe在两个地方似乎是明智的，因此如果一个人无法访问，我们可以倒回另一个。
是否有任何维基或CMS的同步（或另一种方式来实现类似的目的）？
假设您的Wiki中没有每分钟大量的条目，您也可以使用NoSql db CouchDB或Tokyo作为后端来实现同步。 还有redis 。 他们是复制友好的。
一个实验性的解决scheme也可以在Dropbox上的TiddlyWiki ，真正分散！ （或者可能太疯狂，但你可以testing:)）
关于Wiki和CMS，您可以使用这些后端Github是search的地方。 真的很简单，但可扩展 简单sinatra couchdb wiki Instiki（Rails）可以适应欧姆
你也可以考虑sqlite3作为一个可同步的后端，因为数据库它只是一个文件。 像Rails和Django这样的框架支持开箱即用。
更多 ：经过一番思考当我想到当然你也可以使用git ，因为它本质上是一个分散的东西。 如果你在git的基础上构build你的wiki，你可以添加钩子到每一个推动与你的wiki的其他克隆库的同步，或者每隔几分钟就拉一次。 这里有一个wiki-over-git的例子。
我也发现，你可以结合，再次与GIT ZIM。
我使用dokuwiki文件存储。 工作得很好，rsync作为同步方法也有一些小技巧。
我相信rsync与我的所有备份，为什么我不信任与维基复制？
这个wiki存储页面的纯文本文件是完全可读的，可以直接从shell / mcsearch，这是另一个灾难恢复优势。
像MoinMoin一样的维基不使用数据库服务器，只有本地文件，可以很容易地与rsync同步。
如果你喜欢简约的基于文件的框架，你可以尝试werc 。 它遵循计划9的理念，所以期待一切成为一个文件。 这样，同步很容易。
我认为你可以使用化石 ，即使这不是CMS的主要目标。 它具有维基和门票，它可以通过networking同步，它是一个单一的可执行文件，它可以在离线模式下运行，它有变化的历史（因为它是一个分布式版本控制工具）。
ScrewTurn Wiki也支持基于文件的存储，但是我build议您不要依赖自制复制策略（如rsync）。 我只是select支持复制和故障转移群集（如SQL Server）的数据库服务器。