Recover lost data
I don’t know about you, but I think of my SharePoint servers almost like children. I’ve been known to brag them up before. I love hearing about when they do good things, and when someone says something bad about them I always leap to their defense, whether they deserve it or not. And like my children, I don’t want bad things to happen to them. Fortunately it’s much easier to make SharePoint servers behave than it is children, and SharePoint servers seem to bounce back more easily too. But no matter how we try, disasters do happen.
This is the first of two articles in which I cover the types of disasters that might befall your SharePoint servers and discuss ways to protect them from the cruel world around them. I also cover ways to recover from disasters, whether you’ve prepared for them or not. Although a disaster might strike your SharePoint farm at some point, with the information in these articles you’ll be able to confidently recover your data and restore your farm to its former glory in no time. In this article I discuss disasters related to content deletion. I show different ways to prepare for this disaster, including ways to respond if it happens. In the next article, I’ll cover disasters that revolve around hardware failure, including SharePoint servers, SQL Server machines, and your actual facility.
Before we get too far into our talk about disaster recovery, we need to agree on what a disaster is. Different types of disasters can affect your SharePoint servers. To be prepared for a disaster, you need to know what type of disaster you’re preparing for. Of course in a perfect world you’d protect your SharePoint servers against all disasters. But unless you have one of those geese that lay golden eggs, you probably don’t have the resources to take all the steps we’ll cover. You’ll most likely need to look at your budget and see which disasters you’ll be able to protect your servers against.
Determining which Disasters to Plan For
Before we cover how to deal with the disasters that might be headed your way, we need to discuss how to determine which of them you want to protect against. Of course we all want to protect our SharePoint farms from all attacks, but because of budgetary and time constraints that’s not always possible. If it’s not possible in your environment, you need to give some thought to which disasters you want to protect against, so that you know what steps to take to protect yourself against them. The best way to do this is to discuss it with your IT management. Lay out the types of disasters, the processes for protecting against them, and the rough cost of each option. This will give you an idea where each option sits within your budget. Maybe you have more or less money than you thought you did for this project. Knowing the numbers helps.
Next, you should talk to your customers, the business units. Outline the different options with them and explain the costs. Maybe they’re okay with not being able to do point-in-time recoveries, but maybe every minute of downtime costs them sales, which costs them money. Having the discussion with them makes sure you understand how they use SharePoint and what’s important to them. It also helps them understand the costs and time associated with each disaster. If they must have five 9s of uptime, or point-in-time recoveries, then they’ll know the associated costs and you’ll be able to work together to make sure the money is found to achieve their goal.
After you determine which disasters to protect against, the terms need to be spelled out in a service level agreement. The SLA outlines many operational expectations, and disaster recovery is one of them. This agreement outlines the terms of service. For example, suppose someone demands that a file deleted at 3:30 a.m. must be recovered with all its contents. If the SLA says that the only files that can be recovered are ones that existed at midnight, then you have something to support you when you tell the customer you can’t recover the file. The SLA sets everyone’s expectations the same and can prevent hard feelings if IT can’t do something a customer wants done.
Recovering Lost Content with the Recycle Bin
Probably the most frequent disaster in the SharePoint world is prematurely deleted content. This might not seem like a disaster-level problem, but trust me, it is—especially to the person who erroneously deleted the content. And depending on this person’s location on the company’s organizational chart, a disaster for him or her might also mean a disaster for you.
