A while back I posted about the backup and restore process and recommended using the SharePoint utility in Central Administration. That is still my preference and I recently used this to rebuild my server farm including 3 servers, 2 shared service providers and a dozen PWA instances covering about 10 different languages. I must admit it did take several attempts and my one big take-away is – try, try, try again until it all works in one go. The process isn’t very forgiving if one piece fails, so best to remedy the problem and run the whole restore again. The problems I ran into were services that needed starting (Office search in my case, and the Project application) or databases I’d forgotten to delete. Top tip number two is that if you have a complex restore to do and you are changing machine names, URLs, paths to db files, service accounts etc. it can be very tedious to edit these in the UI each time – particularly for all 12 PWA sites! So a short cut is first to take a backup of the spbackup.xml file, and then edit the original and change the various things that need changing in the XML file. It should be easy to work out what needs editing – especially if you have already been through the restore process a couple of times.
So this restore gets everything back how it was, on either the same server or a different configuration.
What if you only have database backups? What can you do and what do you lose? This is a reasonably common scenario – particularly for people with a 2003 background who are used to working with just the WSS content db and the ProjectServer db. But things have changed – and the main challenge is that the PWA site is now held within the content database. This causes some issues as if you want to move the databases to another server you will need to re-provision this PWA site – and you can’t do this against the same content db if it already exists. And if you delete it then everything under /PWA is gone! Which may well include any workspaces for your projects as this is the default location for them. So you have a few options, and we will assume here that you are restoring and re-attaching your main content database to the default web site, and restoring your 4 project server databases.
- Re-provision your /PWA site to a different location – such as /PWA2, and all your old content will still be under /PWA and you will still be able to get to it. This is a good way to work going forward as you now have two independent locations for your PWA site and your other WSS content.
- Don’t attach the original content db and provision your PWA site to /PWA, then attach your content db to another web application (different port). You can then re-link your projects to point to the different location for the content.
- An extension of option 2 – you could use stsadm export and import functions to copy the individual workspaces from their new location back under /PWA – and all is back how it was – well almost.
So what do you still lose by going this route? Fidelity. If you have customized your PWA site through site settings you will lose these changes using any method other than the SharePoint backup/restore. As an example the following site was replicated using option 1 and the highlighted changes (and the colour from the theme) are lost in the restored site pictured below. You do however keep any changes made through Server Settings such as menu edits (My Timecard in place of My Timesheets in the screen shots).
I hope this helps understand what is stored where – and the challenges of moving data between servers, either for migration or disaster recovery.
Technorati Tags: Project Server 2007