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.
The good news is that although this is the most common disaster you’ll encounter, it’s also the easiest to deal with. Like SharePoint 2007 before it, SharePoint 2010 has a built-in Recycle Bin. This Recycle Bin captures deleted list items, documents, folders, lists, and document libraries. Although this seems pretty comprehensive, keep in mind that the Recycle Bin doesn’t catch Web or site collection deletions (which I cover later). The Recycle Bin has two parts: the end user Recycle Bin and the administrator Recycle Bin.
The first stage of the Recycle Bin shows a user all the documents he or she has deleted in the current Web and gives the user the option of restoring those documents. Figure 1 shows how a site member sees the Recycle Bin. The Recycle Bin lists the items the user has deleted in a site, including the items’ original locations and when they were deleted. From here a user can restore a document to its original location and get back to work on that important document. Although the documents are in the first-stage Recycle Bin, they count against the site collection’s quota. Therefore, end users can also delete items from the first-stage Recycle Bin to free up space. At that point, users can no longer restore items and must call the Help desk—which is where the second stage of the Recycle Bin comes in.
Figure 1: SharePoint 2010’s Recycle Bin
Unbeknownst to the end users, there’s a second, secret Recycle Bin that’s exposed only to site collection administrators. This Recycle Bin contains all the documents that every user has deleted in the site collection—and more important, it also contains all the documents that have been deleted from the first-stage Recycle Bin. This is where the SharePoint administrator can save users from themselves. If a user deletes a document and also deletes it from the first-stage Recycle Bin, it can still be restored from the second-stage or administrator Recycle Bin. Items in the administrator Recycle Bin also don’t count against the site collection’s quota. Those Microsoft folks thought of everything.
You need to be a site collection administrator to access the administrator Recycle Bin. To find it, open the first-stage Recycle Bin. Depending on which site template you’re using, there’s typically a link on the left navigation bar. If you’re a site administrator, you’ll see additional text that mentions the Site Collection Recycle Bin, with a link to it. When you click that link you’ll be taken to the /_layouts/AdminRecycleBin.aspx page. This page has two links. One shows the contents of the first-stage, or end user, Recycle Bins. The second link, called Deleted from end user Recycle Bin, shows the second stage. Here you can see all the documents end users have deleted from the Recycle Bin. Restoring a document from here will restore it to its original location.
It’s important to recognize that deleted items don’t age out of the first stage to the second stage. They only show up in the second stage if they were deleted out of the first. If the web application settings are set to delete items from the Recycle Bin after 30 days, then they are gone for good out of both stages of the Recycle Bin. There are no tricks to get them back.
This setting and the rest of the Recycle Bin settings can be accessed by selecting Central Admin, Application Management, Managed Web Applications. Choose a web application and click General Settings in the ribbon. If you want to flex your PowerShell muscle, you can also modify these settings with the RecycleBinCleanupEnabled, RecycleBinEnabled, RecycleBinRetentionPeriod, and SecondStageRecycleBinQuota properties of your web application.
Other Tools for Recovering Content
How do you recover content after it leaves your Recycle Bin? That’s a little trickier. To accomplish this task, you need some sort of backups. If you’re not doing any type of backups right now, first, shame on you. Second, you’re lucky you’re reading this article. The very least you can do is back up all your SharePoint databases in SQL Server. Armed with those backups, you have several options for restoring content. If you’re not familiar with how to do database backups in SQL Server, you can get a quick primer from my blog article “Scheduling SQL backups for SharePoint”.
You have a few options if you’re recovering content from databases. Which option you choose depends on your environment and what you’re trying to recover. If you need to recover a deleted site collection or Web, it doesn’t get any easier than the Central Administration unattached content database recovery option. You can see in Figure 2 that Central Administration has an entire tab dedicated to backup and restore. One of the options lets us access data in a SharePoint database that isn’t mounted in SharePoint. You can use this option to back up data from a recovered database and restore it to your production environment. To do this, restore an old backup of a content database into SQL Server. Use a different name to make sure you don’t overwrite the production version of the database when you’re restoring your backup database. Then click Recover data from an unattached content database in Central Administration. Enter the name of the recovered database, select Browse Content, and click Next.
Figure 2: Using the Central Administration Backup and Restore option
From here we can browse to a site collection that exists in the restored content database. You can also export just a Web or list if you prefer. If you choose a site collection, the site collection is backed up as with Backup-SPSite or stsadm -o backup. If you choose a Web or list, the content is exported as with Export-SPWeb or stsadm -o export. When you click Next, you’ll see a screen asking for a filename to save the backup or export file. It’s important that you use a Universal Naming Convention (UNC), because the backup or export is done as a timer job and can run on any machine in your farm. When you click Start Backup, SharePoint will begin backing up or exporting the content you selected to the appropriate file. A backup job status page then opens to let you know how your backup is going. This page also has a Recovery Step column for recovering content. For site collections, use Restore-SPSite. For Webs and lists, use Import-SPWeb. When your backup finishes, use the correct command to restore your recovered content to either its original location or another location if you want to pull out individual items. The other location can be on the same farm or a separate farm. The only requirement is that the farm you recover to must be the same build number or later than the farm the backup is from.
If you have a second SharePoint 2010 farm, you can skip the unattached database steps and attach your restored content database to your second farm. The recovery farm must be at the same SharePoint build or later than the farm that created the database. If any solutions are needed to render the content, you’ll likely need that solution on the recovery farm as well. Another often overlooked setting is managed paths. The web application you restore the database to must have any managed paths needed to render out the content you’re trying to recover. After the database is attached to the recovery farm, you can use several techniques to obtain the desired content: You can perform backups or exports, you can download individual documents, and you can use Explorer View to obtain several documents at once.
I already touched on this topic briefly, but you can also use PowerShell to perform backups of individual site collections. The cmdlet to back up site collections is Backup-SPSite. Go to the SharePoint Management Shell and enter
Get-Help Backup-SPSite
to obtain usage information. For basic backups, you need to provide only two things: the URL of the site collection being backed up and the name of the file to back it up to. The file that the Backup-SPSite cmdlets writes will be a full fidelity backup of that site collection. This means the backup will contain the content plus its metadata (e.g., alerts, security, workflows). Like the content databases, this backup is completely portable. You can restore it to a different location in your farm or to a different farm altogether.
Although you probably wouldn’t use this method as part of a disaster recovery strategy, it’s a good alternative for performing one-off backups. Thanks to the awesomeness that is PowerShell, you can easily back up all the site collections in your farm with a single line. Again, this isn’t a good enterprise disaster recovery technique, but it might come in handy once in a while.
Get-SPSite | ForEach-Object\\{$FilePath = "d:\backups\" + $_.Url.Replace("http://","").Replace("https://","").Replace("/","-").Replace(":","-") + ".bak" ; Backup-SPSite -Identity $_.Url -Path $FilePath\\}
This command will back up all the site collections in your farm to the D:\Backups folder on the server you run it on. We use the Replace() method to strip out parts of the URL that don’t work in filenames (e.g., colons, slashes). Make sure your drive has enough space for the files before you run this command. You’d use Restore-SPSite to turn those files back into site collections.
Third-Party Options
As we’ve seen, SharePoint has a pretty good set of tools out of the box to help you prepare for content loss disasters and recover from them in the unlikely event that they do occur. However, there are also some good third-party solutions you should take a look at. These aren’t full disaster recovery suites; I’ll cover those in the next article. These are just some tools to augment the out-of-the-box tools I already discussed.
SharePoint Site Recycle Bin. When I covered the SharePoint Recycle Bin earlier, I mentioned that it doesn’t protect against accidental Web or site collection deletion. I then explained how to recover Webs and sites from database backups, but this process can be a lot of work. Also, the restored Web or site collection will only be as current as the last backup. Fortunately there’s a free tool to fill that gap. You can download the SharePoint Site Recycle Bin from the SharePoint Governance and Manageability website at governance.codeplex.com. This is a free download that adds Recycle Bin–type functionality to SharePoint. Before a Web or site collection can be deleted, SharePoint backs it up to a location in the file system. Then when the Help desk calls start rolling in, you can simply restore the Web or site collection from the backup. The only way this process could be easier is if SharePoint answered the phone, chatted up the customer, and restored the customer’s content for you. (I hear that’s coming in the next version.)
The setup for the SharePoint Site Recycle Bin is a little tricky, so make sure you read through the instructions before you start the installation. I also recommend trying it out in your test environment first to get a feel for the setup. Finally, make sure the location you save the backups to has enough space and is getting backed up itself (or not getting backed up—whichever fits your retention policies).
Idera’s SQL virtual database. I covered several ways to use SQL Server database backups to recover deleted content. If you want to take your database recovery game up another notch, consider buying Idera’s SQL virtual database. This software lets you mount a database backup in SQL Server without actually restoring the database, which saves time and drive space. Instead of restoring the database back to SQL Server, SQL virtual database attaches to the backup file and exposes the virtual database to SQL Server, giving you immediate access and not requiring the drive space for the restored MDF and LDF files. After the virtual database is mounted in SQL Server, you can use any of the methods I discussed to recover your content. This approach lets you keep more backups around on disk and lets you get your users’ content back to them more quickly. For more information about SQL virtual database, go to Idera’s SQL toolbox website.
AvePoint’s DocAve Recovery Manager for SharePoint. We’ve discussed a couple of ways to recover documents from database backups. Although the process isn’t bad, it’s awfully manual. Wouldn’t it be nice to have a tool that you could just point at a recovered database and select the document to recover? AvePoint has created just such a utility—and it’s free! Go to AvePoint’s website to download the DocAve Recovery Manager for SharePoint. As with any software, you should try it in a test environment first to work out the kinks before you unleash it on your production servers.
Wrapping It Up
A multitude of disasters could befall your SharePoint farm. To be a top-notch SharePoint administrator, you need to stay a step ahead of these disasters. In this article I discussed several ways to recover deleted content and get it back into your farm. These techniques will help you restore your users’ content, no matter how hard they work to delete it. I’ll take a look at some other types of disasters, such as machine and facility failure, in a follow-up article and discuss how to plan for them.
