An Ounce of Prevention – Why Backups are important

In the past few blog posts, I have gone over the What, When, and Where of SharePoint Disaster Recovery planning.  So, why? Why do you need any type of Disaster Recovery plan? You have a farm that has ten web front ends that are all load balanced and set for automatic failover.  You have two app servers with mirroring set between them, as well as two separate servers dedicated solely to Search with mirroring as well. You have a clustered database server set for automatic failover. Your high security/high availability set up is second only to the one at Microsoft HQ.  The reason that you need a Disaster Recovery strategy is that disasters will strike even the most robust of environments. Besides, it is always better to have it and not need it, than to need it and not have it. Murphy’s Laws being what they are, simply having a good disaster recovery strategy will probably prevent you from needing it. 

So what kind of disasters could befall such a glorious and robust SharePoint farm that would bring it to its knees and make Administrators, Architects, and Developers weep? Two words; “End Users.” End users are notorious for finding new and creative ways to make things not work correctly. End users are famous for accidentally obliterating months old objects that they discover were needed mere seconds after they were irreparably removed or damaged.  So much so that I have come up with a name for the kinds of chaos and havoc that End Users inflict on SharePoint environments; “Tiny Disasters.”  Just like a toddler sticking a PB&J in your Blu-Ray player, End Users are the worst enemy of healthy SharePoint environments. They are also the reason it exists, so we can’t realistically say “Out of the pool!” (Wouldn’t that be nice though?)   There are ways that you can try to minimize the damage that End Users will inflict, but there are always exceptions.  To minimize the damage that users can unleash upon your SharePoint farm, a good set of governance is a brilliant place to start. Limit who can do what. If you have not yet created a custom permission that is CRUD (Create, Read, Update, Delete) what are you waiting for? Not every contributing user needs to be able to delete. You also need to make sure that only the stuff that is supposed to go in SharePoint does. You don’t really need 1,300 copies of Bruno Mars mp3s stored in your farm. Ultimately, be ready for the end user that manages to upload something that causes damage. If you aren’t prepared for it, it will happen.

One of the most powerful tools that your end users have is the Content Query Web Part.  Unfortunately, it is powerful enough to really mess things up.  Bad code, whether it was developed in house or from a third party, can also exist in your farm. Yes, even ISVs will write code that may not play nice with your farm. Maybe not directly, but ISVs are not known for testing compatibility with their competitor’s products. I know that last bit from personal experience, as I worked at an ISV, and when trying to test compatibility with another ISVs product, there was some friction.   

How do you mitigate this unending flow of terror that is constantly unleashed upon your precious environment? Have backups. Have a Disaster Recovery strategy in place. Test it. Test it often. Just because it worked once doesn’t mean it works now. And the easier it is to recover from a Tiny Disaster, the stress of having them will fade from major paranoia to merely mild inconvenience.  Practice with Tiny Disasters also makes it much easier to manage the catastrophes.  You will already know your recovery plan and know how to be the most effective with it. Knowing you can recover from anything your End Users throw at your environment will help you sleep easier at night. 

Ultimately the best reason to get backups of your SharePoint farm, is so you won’t need them.