没有stsadm的SharePoint备份/还原

Question

由于我们在使用stsadm还原站点/站点集合时发现的问题(我们从工作流生成的任务没有被恢复)，我们采用了不同的备份/恢复路线。我们计划主要定制到我们的SP站点，并希望采取备份，以便我们可以回滚，以防安装失败。在我们的系统测试(而不是生产)环境中，我们备份了12个单元、IIS指向SharePoint的虚拟dir和SQL中的SharePoint数据库(使用SQL server进行数据库备份)。

我们有用Visual构建的自定义事件处理程序和工作流，并将dll作为版本2(在Visual中签名和版本)部署到GAC。因此，当我们部署时，GAC将包含两个版本的工作流-- version 1和version 2。在部署过程中，我们使用SP stsadm特性来安装/激活WF。我们还会访问每个库并添加新的版本2 WFs。这会自动将版本1的WF设置为“不允许”新实例(这正是我们想要的)，并将版本2设置为active -完美。

当我们完成安装后，我们就假设失败并尝试恢复到相同的计算机(服务器上的SharePoint，另一台服务器上的SQL )。我们从从GAC卸载版本2 WF开始，重置IIS (以清除这些ver的缓存)。2 WF‘)，还原12单元和虚拟目录文件夹，然后恢复SQL。这一切就像你读过的手册一样-这里没有stsadm。所有的工作似乎在我们的恢复后，似乎恢复是成功的-我们在安装期间对列名、数据更改等进行的mods都恢复到了原来的预安装状态。只有一个例外。当我们运行一个工作流时，它总是失败，12-单元中的日志表明WF仍然试图使用dll的第2版(System.IO文件没有找到错误)--我们认为我们已经备份和恢复了所有移动的共享点，但是我们在这里遗漏了一些东西，有人知道为什么在还原所有文件夹和数据库的SharePoint时仍然引用version 2 WF吗？

谢谢，凯文

Answer 1

凯文，

如果我正确地理解了您的操作顺序，那么我有一个大问题:在还原过程中，您是否恢复内容数据库，但将场配置数据库(以及其他数据库，如SSP数据库)保持不变？如果答案是“是的”，那么我怀疑SharePoint正在抛出一个fit，因为您的配置数据库仍然维护着对工作流的v2的引用。我怀疑可能会发生这样的事。

当您将一个特性安装到您的SharePoint场时，SPFarm.FeatureDefinitions集合(在场配置数据库中维护)将被更新以反映您添加的内容。这包括您期望功能包含的所有标准信息:名称、范围、ID、版本等。它还维护FeatureReceiver程序集信息和RootDirectory值等。RootDirectory属性指向功能清单所在的12-单元中的文件夹。

将v2工作流特性添加到场并激活它时，配置数据库将被更新。即使还原内容数据库的前v2工作流版本，由于在配置数据库级别上维护的功能关联，场仍将寻找工作流的v2。如果v2功能文件夹仍然存在于12单元中，并且它的清单指向GAC中的v2程序集，那么很容易看出问题在哪里出现。

同时，如果您的工作流特性利用了FeatureReceiver，那么在安装了该功能时，该信息也会存储在FeatureDefinitions集合的ReceiverAssembly属性中(在配置数据库中)。

如果我搞错了，而你实际上是在恢复整个农场(包括配置数据库)，那么我所写的就不适用了。如果那样的话，我也会被挠头。:-)

我希望这能帮到你!

Answer 2

您能否尝试在完成安装后从列表中删除工作流绑定，因此首先从列表中删除所有工作流关联，然后从V2中删除dll，然后重新部署dll，然后重新分配工作流，以确保所有对工作流的其余引用(来自content和config db)都已消失，并强制sharepoint重新绑定/重新配置工作流关联。

很奇怪，工作流相关的任务没有恢复，它们只是内容，应该在内容db中，我认为工作流任务绑定到一个不能正确恢复的工作流(因为工作流关联存储在内容db和config db.中)。当还原发生时，工作流基本上被重新初始化，得到一个新的GUID等等。对于sharepoint来说，这似乎是一个新的工作流，因此与旧工作流相关的任务不能再绑定了)。

我建议您深入研究实际问题，而不是创建自定义解决方案。

有关工作流相关的恢复/打包问题以及工作流如何实际保存/创建的更多信息，请查看本站和这篇文章。

Answer 3

我从未使用过它(甚至连Sharepoint的人都没有)，但这可能对你有用。无意中发现了CodePlex..。

http://spbackup.codeplex.com/