We recently had a need to restore a SharePoint library from the backup, which was a great opportunity to try out the granular restore features of SharePoint 2010 for real.
The first challenge concerned the nature of our backup. We run a daily backup of the full farm but this didn't meet our current need - there was no way I was restoring the whole farm just to fix a developer's minor mishap and the farm backup does not provide an option to drill-down all the way to list and library level.
To the rescue comes "Unattached Content Database Data Recovery" which you'll find in Central Admin under Backup and Restore. Using this, we can drill-down into the SharePoint content to the library that we want to restore.
All we need is an unattached content database from which to recover our data, and the best source for this is the database backup that we ran overnight as part of the full farm backup.
The SharePoint farm backup creates a ton of files and folders through which we can search to find the backup file for our database. Fortunately it also creates a couple of handy xml files which tell us where to look. First we have spbrtoc.xml in the root backup folder and this tells us which subfolder the latest backup files are in. Looking in this folder, we find spbackup.xml and this tells us which .bak file is our SharePoint content database backup (it's a pretty big file so judicious use of Ctrl+F is an idea here). We could also have fairly easily found the right file just by checking the creation date and file size but let's be precise about things.
Now we've got our backup file we can restore it to the server, right?
Actually, best hold on a moment. We don't want to restore this to the SharePoint database server as this would overwrite our existing content db (very bad news). We could do the restore to this server and make sure we use a different database name and file location, but it just doesn't seem like a very good idea. So we'll restore the backup to a different server.
With the restore completed we headed back to Central Admin to complete the "Unattached Content Database Data Recovery" wizard and immediately we hit a problem - our farm service account can't log on to the database. Fantastic. The service accounts are shown in SQL Server Management Studio as users for the database but they don't have logins on the server.
So I create logins for them (temporarily). Does it work? No.
Apparently SQL Server is not about to let me get away with this. So I delete the newly restored database and, leaving the new login for the farm account in place, restore it all over again. Now we're in business. The "Unattached Content Database Data Recovery" wizard runs fine, connects to the database and allows me to select the site collection, site and library that we need. I choose the option to export the library and save it to C:\export.cmp.
So now I've got the library out of the backup and into export.cmp - just need to find the GUI to import a library. That's somewhere in Central Admin maybe? Actually it's not, this is powershell time. Once again SharePoint has a GUI for half the process and powershell for the rest. Sigh.
Fire up powershell and type:
Import-SPWeb http://quanta/path/to/site/for/restore C:\export.cmp
Cannot find an SPWeb object with Id or Url : http://quanta/....
Try again, this time running powershell as the farm account, and finally we're in business. The library appears in the chosen site and at last we're done.
Final clear up operations include removing the restored database, and the extra logins created on the server, then taking a stout stick to the developer who triggered all this.
Part of the wonder and fun of SharePoint is that it always seems to make you work just that little bit harder than you thought you were going to.