由于我们发现使用 stsadm 恢复网站/网站集存在问题（我们从工作流生成的任务未恢复），我们采用了不同的备份/恢复方法。我们计划对我们的 SP 网站进行重大定制，并希望进行备份，以便在安装失败时可以回滚。在我们的系统测试（非生产）环境中，我们备份了 12 个配置单元、IIS 指向 SharePoint 的虚拟目录以及 SQL 中的 SharePoint 数据库（使用 SQL 服务器进行数据库备份）。
我们有使用 Visual Studio 构建的自定义事件处理程序和工作流，并将 dll 作为版本 2（在 Visual Studio 中签名和版本控制）部署到 GAC。因此，当我们部署时，GAC 将包含 2 个版本的工作流 - 版本 1 和版本 2。在部署期间，我们使用 SP stsadm 功能来安装/激活 WF。我们还转到每个库并添加新的版本 2 WF。这会自动将版本 1 WF 设置为“不允许”新实例（这正是我们想要的），并将版本 2 设置为活动状态 - 到目前为止完美。
完成安装后，我们假设出现故障并尝试恢复到相同的计算机（一台服务器上的 SharePoint，另一台服务器上的 SQL）。我们首先从 GAC 卸载版本 2 WF，重置 IIS（以清除这些版本 2 WF dll 的缓存），恢复 12-hive 和虚拟目录文件夹，然后恢复 SQL dbs。这一切都和您读到的一样手动 - 这里没有 stsadm。恢复后一切似乎都正常，似乎恢复成功了 - 我们在安装过程中对列名、数据更改等所做的修改都恢复到了原始的安装前状态。只有一个例外。当我们运行工作流时，它总是会失败，并且 12 个配置单元中的日志表明 WF 仍在尝试使用 dll 的版本 2（找不到 System.IO 文件错误）我们认为我们已经备份并恢复了 Sharepoint 的所有移动部分，但是我们在这里遗漏了一些东西，有人知道为什么即使我们恢复了 SharePoint 的所有文件夹和数据库，版本 2 WF dll 仍然被引用吗？
谢谢，凯文
答案1
凯文，
如果我正确理解了您的操作顺序，我有一个大问题：您是否在还原内容数据库，但在还原过程中保持场配置数据库（和其他数据库，如 SSP 数据库）完好无损？如果答案是“是”，那么我怀疑 SharePoint 会发脾气，因为您的配置数据库仍然保留对工作流 v2 的引用。以下是我怀疑可能发生的情况。
当您将功能安装到 SharePoint 场时，SPFarm.FeatureDefinitions集合（在场配置数据库中维护）会更新以反映您添加的内容。这包括您希望 Feature 包含的所有标准信息：名称、范围、ID、版本等。它还维护 FeatureReceiver 程序集信息和根目录价值等。根目录属性指向 12 个配置单元中该功能的功能清单所在的文件夹。
当您将 v2 工作流功能添加到服务器场并激活它时，配置数据库会更新。即使您恢复内容数据库的 v2 之前的工作流版本，由于在配置数据库级别维护的功能关联，服务器场仍将查找工作流的 v2。如果 v2 功能文件夹仍然存在于 12-hive 中，并且其清单指向 GAC 中的 v2 程序集，则很容易看出问题可能出现在哪里。
同时，如果您的工作流功能利用了 FeatureReceiver，则该信息也会存储在（配置数据库中）接收器组件的财产特征定义安装该功能后即可进行收集。
如果我错了，你实际上正在就地恢复整个场（包括配置数据库），那么我写的内容就不适用了。在这种情况下，我也会有点摸不着头脑。:-)
我希望这有帮助！
答案2
完成安装后，您可以尝试从列表中删除工作流绑定，因此首先从列表中删除所有工作流关联，然后从 GAC 中删除 V2 dll，然后重新部署 dll，然后重新关联工作流，以确保对工作流的所有剩余引用都已消失（从内容数据库和配置数据库中），并强制 sharepoint 重新绑定/重新配置工作流关联。
PS 非常奇怪的是，与工作流相关的任务没有恢复，它们只不过是内容，应该在内容数据库中，我认为工作流任务绑定到未正确恢复的工作流（因为工作流关联存储在内容数据库和配置数据库中...）。恢复时，工作流基本上会重新初始化，获得新的 GUID 等。对于 SharePoint，这似乎是一个新的工作流，因此与旧工作流相关的任务不能再绑定）。
我建议您深入研究实际问题，而不是创建自定义解决方案。
答案3
我从未使用过它（甚至不是 Sharepoint 专家），但这可能对你有用。在 CodePlex 上偶然发现它...