Backup/Restore SharePoint without stsadm RRS feed

  • Question

  • Due to problems we found with the restore of sites/site collections using stsadm we've taken a different route for backup/restore. (Sidebar - the problem we had with stsadm is that it seemed to backup and restore individual sites ok, but when I took a closer look, all the tasks in my Task list were missing.  These tasks were created by my custom Workflow which creates a task to help notify the user of an item that needs their attention.  Anyway, none of these tasks made it over in the stsadm restore).

    We are planning a major release of event handlers and workflows to our SP site and want to take a backup of our production SP so we can rollback in case the install fails. In our System Testing (not production) environment, we've backed up the 12 hive, the virtual dir's that the IIS points to SharePoint, and the all the SharePoint databases in SQL using SQL server to do the db backups (content db, config db, everything).  We made sure to shut down the web front end server first before we made the backups on the SQL backend server to avoid any synchronization issues with the config db.

    As part of our impending upgrades, we have custom event handlers and workflows built with Visual Studio, that get deployed to the GAC as version 2 (signed and versioned in Visual Studio). So when we deploy, the GAC will contain 2 versions of the workflows - version 1 (the original) and version 2. During the deploy we use SP stsadm features to install/activate the ver. 2 WF's. We also go to each library and add the new, version 2 WFs. This automatically sets the version 1 WF's to "Not Allow" new instances (which is what we want) and the version 2 as active - perfect so far.

    In our backup/restore testing, when we've completed our release install on System Test (new event handlers, workflows), we then assume a failure and attempt to restore back to pre-install configuration to the same machines (SharePoint on one server, SQL on another).  We start by uninstalling the version 2 WF's from the GAC, reset IIS (to clear cache of these ver. 2 WF dlls'), restore the 12-hive and virtual directory folders.  Then we shut down the front end server and restore the SQL dbs. This is all just as manual as you read it - no stsadm here.  We restart the front end server, all seems to work after our restore, it appears the restore was successful - the mods we made to column names, data changes, etc during the install are all reverted back to the original pre-install state. With one exception. When we run a workflow, it always fails and the Logs in the 12-hive indicates the WF is still trying to use the version 2 of the dll (System.IO file not found error) We think we've backed up and restored all the moving pieces of Sharepoint but we're missing something here, does anybody have any ideas why the version 2 WF dlls are still being referenced even though we restored all the folders and db's of SharePoint?


    Friday, August 28, 2009 9:47 PM