Thanks to everyone who watched A Simple Game Plan to Master SharePoint Recovery presented by Doug Davis and I at Quest Software's Virtual Expo 2009 for SharePoint. If you didn't get to see the webcast, you can access it at anytime by registering at the link above. We received a lot of great questions on backup/restore/HA/DR but didn't get a chance to answer them all until now.
Q: Do you have some SLA guide line or SLA template:
A: I scoured the web looking for something definitive on the subject and have yet to find anything. This is likely because SLA's are so unique to a business (and private) that people haven't been willing to share. That said, I plan to post some examples of SLA's relevant to SharePoint recovery on my blog in the near future.
Q: Can you summarize the good, bad, ugly for using DPM for MOSS SharePoint Recovery:
A:
Good: Its fast, gives you full fidelity of environment protection, minimizes storage requirements.
Bad. To restore the smallest items, docs, etc requires a full database restore to the recovery farm. Depending on the size of the containing db this might take a while.
Ugly: hard to track down the location of specific items. Use Recovery Manager for SharePoint to augment item-level recovery on DPM.
Q: I run MOSS 2007 on VM Ware. How safe is using a snapshot of SharePoint and the database vs a backup? Should I be backing up and doing a snap shot:
A: If your SharePoint farm consists of a single server then a snapshot is a valid way to protect your farm. This means that all roles need to be deployed to the same server. However, if your farm consists of 2 or more servers then snapshots are not a supported way to protect a SharePoint environment due to state management issues.
Q: Are you aware of a backup solution from Mimosa for SharePoint backup? What is your take on it:
A: I wasn't aware of the Mimosa solution until this question nor am I aware of anyone using it. I would need some hands on time with the product before I could make any comments.
Q: We have 3 locations and we would like to synchronize between SP portals - content only if need be. It is not a large implementation with only about 100 users in total. We have fiber VLAN between the locations. We don't have a large budget but we are in an area where the connection between sites can drop due to weather conditions so the ability for each location to work autonomously is important. Any thoughts would be appreciated:
A: This is a difficult scenario in that it's hard for any technology to keep 3 locales in sync and especially hard when those locales aren't always connected. There's certainly no way to do this out of the box properly and supported. I would look at a third party replication product. There are some good ones, though I can't make any recommendations for obvious reasons.
Q: Can the search and recovery interface to be accessible by the end user as well? So the users can search something they have removed before:
A: This question is referring to the Quest Recovery Manager for SharePoint which allows users the ability to search for any content that existed in SharePoint at any time and locate and recover that content very quickly. Delegation of the recovery UI isn't available in this version, but that feature is certainly on the roadmap.
Q: What should be the strategy for testing restore process:
A: First, if you must test the restore process as part of compliance, make sure to follow those compliance guidelines and work with your compliance consultant to ensure those requirements are being met. Second, always test your backup/restore process. Nothing sucks worst than telling executives you lost data. Been there. Done that. You don't want to be that guy. When I was at MSFT, we tested once a quarter to satisfy SAS 70 requirements. This involved proving that a basically skilled individual could follow instructions to restore randomly chosen data. This, to me, seems a bit simplistic. I would recommend actually performing a full DR scenario once a quarter. This of course means you should have a DR/testing environment where you can drop loads of data quickly. Some metrics you should be concerned with while testing:
Is your top SharePoint expert performing the restore? Why? We know she can do it and can work miracles to find that missing data. Better to have your newbie in there trying to figure it out. That's a much better test.
How long did it take for the end user to request a restore? The longer the wait the worse it is for you as your window of opportunity starts closing.
How long did it take to find the missing data? Recover it from media? Bring it online? Return it to the end user?
Use these as benchmarks for your SLA's and for continual improvement.
Q: Where can we get more information about Disaster Recovery strategy or templates or best practices:
A: I'm going to write an extensive blog post to put together everything you need to know about disaster recovery in SharePoint (from a high level) and can drill in as interest (yours) and time (mine) allow.
Q: If we backup the content database (SQL) and also do live imaging of the web/app servers. When restoring content data and restoring an image, will this get us back up and running or do I have to do more to make sure the config matches the data:
A: Imaging the web/app servers is a good idea in that it gives you full protection of any assets that might be located on those servers that can't be restored from a database. That said, restoring the entire image and databases to a point in time is not a good way to guarantee consistency. It would be much better to: Create a new farm, reconfigure settings and webapps, recover the SSP/Search from STSADM backup, recover the remaining DB's and attach to the web app(s), reinstall/reconfigure any customizations. (using images to obtain bits if necessary) Best practice is to roll customizations into solution package(s) to ensure a speedy full fidelity recovery.