Last week, I explained the basics of granular restore in SharePoint 2010. I left you hanging with the question, “Is it enough?”
The answer is, sometimes, yes. If all you need is to recover a list or library or site, then it does the trick with caveats, explained below.
However, the process by which you mount a database, export the content, then import it is awkward and time consuming, and gives you no way to actually open or explore or browse the content before you import it. So unless you’re really sure about which backup has the version of the content you need to restore, you may be in for some trial-and-error restores.
Furthermore, there are many situations in which rolling back an entire list or library in order to recover one corrupted item or document is overkill. For many of us, granular restore means granular restore—down to the item or document. SharePoint 2010 does not offer that, out of box.
Perhaps most importantly, even if you do restore an entire list or library, you don’t restore everything else associated with it: workflows and workflow history, for example. There are several other site and site-collection level components that you might need to restore when you restore a list or library, and SharePoint 2010 out-of-box does not support that.
Finally, you have to be aware of the dangers of granular restore. If you restore a list and you have workflows or event receivers, they could easily cause problems. For example, let’s assume you have an event receiver that adds an item to LIST B when you add an item to LIST A. If you restore LIST A, you will trigger that event receiver, which will then create duplicate items in LIST B.
The Import-SPWeb cmdlet has a number of switches that can begin to address some of these potential challenges with SharePoint 2010 granular restore. Type
Get-Help Import-SPWeb -full
for information. But it does not expose everything that the API exposes. My friend and colleague, Gary Lapointe (http://stsadm.blogspot.com) promised that soon he will create an extended cmdlet that exposes more of what the API supports. Pressure’s on him now that I’ve mentioned this… oops :-)
The bottom line of all of this is that you should not assume that SharePoint 2010’s granular restore is going to be a silver bullet supporting all of your restore needs. It is useful, to be sure, in some scenarios, but you will want to test a restore before performing it in a production environment. And you’ll definitely want to look at the documentation for the Import-SPWeb cmdlet to align the cmdlet’s parameters with your specific scenario.
Finally, you’ll probably continue to want to keep a good third-party backup and restore utility in place in your 2010 environment. They still have a lot of value to add in the granular restore scenario, not to mention a broad range of other backup and restore scenarios.
