What is the first rule for administrators of a SharePoint environment?

Always backup your implementation. With no backup and recovery plan, you are setting yourself up for failure.

You might be asking yourself, “Do I really need to back up my entire SharePoint environment when the server admin next to me does it every day as part of his regular backup routine? And what if I am only responsible for the information in my department? Do I want to deal with IT every time I need to backup or recover a file or site?” I didn’t think so...

Truth is, backing up SharePoint is no longer about application servers, configuration databases and IIS, it’s about the content and ensuring you can get access to it fast.

Backup & Recovery of SharePoint -- Yesterday’s Requirements

I could spend this entire article talking about the backup and recovery tools available for a SharePoint environment out of the box. I could also spend a lot of time discussing the various third-party vendor products that do the same thing, sometimes more. But here’s the don’t really need most of these tools anymore.

How many of you have Server Administrators who do daily snapshots of your servers and databases, and regular full backups weekly or monthly using software? How many of you have your environment on a virtual server? Have high availability systems standing by ready to take over if something happens to the database or app server? How many are using cloud storage to store backups?

The truth is, if something did happen to one of your SharePoint servers or to the entire SharePoint environment, it’s going to be pretty easy to recover that entire server (or servers) from your regular backups. Do you really need a separate, SharePoint specific, backup and recovery plan? Probably not.

Side Note: Backup and Recovery with SharePoint in Office 365

Backup and restore of SharePoint in the cloud is another story altogether. Take SharePoint via Office 365 as an example. Microsoft does offer some recovery options through support. It does offer disaster recovery (with up to a 12 hour time difference) and it will allow recovery of a deleted site within 7 days of the deletion (up to date within 24 hours of the deletion).

But keep in mind that you can’t take advantage of the processes and third party tools mentioned above because you don’t have access to the server (only Microsoft does). The same goes for most other hosted SharePoint environments -- your options for backup and restore are limited. Part of the reason for this is that you need to install an agent on the front-end servers to interface with the backup software -- something you can’t do in a hosted environment.

So if this is really true, and we don’t need to worry about having specific SharePoint-based tools to do backup and restore, then is backup for SharePoint a dead issue? Not really. Instead, the backup and restore discussion becomes even more relevant for SharePoint content itself.

Backup and Restore from the Department Perspective

If your department or division (or maybe you are an SMB) uses SharePoint as a primary document collaboration and information storage tool, then it’s really important to you to have some control over that environment from a backup and restore perspective, as well as an information architecture perspective.

It’s unlikely you will go out and spend money on software that needs to be installed on the SharePoint servers to help with backing up data, restoring content or moving things around because you aren’t typically the sole owner of that environment. Those decisions are made higher up and generally with IT in the lead. And typically, requests into IT to have work performed (like partial backups, site or item restores, or archiving of unused sites) will sit in line with a lot of other work IT is doing.

You need a solution that you can use within your department that’s simple, doesn’t require a server install (i.e. agents) and allows you to manage your own content without concern for what other departments are doing.

Accidentally Delete A Document? There’s a Backup for That

Here’s the big issue for SharePoint content today -- recovering accidentally deleted files. It’s done daily. You delete something you think you no longer need or you accidentally delete a document or list item without realizing it. It happens.

Yes, you have your recycle bin, but you probably aren’t keeping the content in those for very long and the recycle bin’s capabilities vary based on the version of SharePoint you are running e.g. SharePoint 2010 SP1 versus SharePoint 2007.

So how do you get access to deleted files or old files, sites or site collections? Out of the box, Microsoft doesn’t provide too much (unless you are an expert in T-SQL). There are some third party SharePoint backup providers who do offer the ability to backup and restore individual documents, sites or collections. Some of this functionality includes:

Learning Opportunities

  • Item Level Restore: The biggest restore request heard by SharePoint Administrators is for a specific document or list item.
  • Full Fidelity Restore: Restoring a document, site or site collection is good, but you also want all the additional information restored with that item, including permissions, versions, workflow, metadata, etc.
  • Backup Individual Sites: Sometimes all you want is to backup a specific site, or set of sites, and to go along with that, you may want to restore only a single site or set of sites.
  • Backup/Restore Locations: Depending on the size of your site, or the importance of the information located in a site, you may want to backup different sites to different locations. Conversely, you may also want to restore sites to different locations.

It’s important to note that almost all of the vendors that can provide this level of backup and restore also require you to place an agent (small piece of software) on your front-end web servers to communicate with a central backup manager. All requests for backup or restore go through these agents. Some question if it’s a good idea to place third-party software in the SharePoint environment, and while it can provide some security concerns if not implemented correctly, it’s also a non-starter for smaller groups within an organization who need this functionality.

Here again, we run into the problems that departments may face getting this type of work done in a timely manner. In most organizations, software that needs to installed at the server must remain under the control of the IT department. And this dependence on IT (who has many departments to support) has the potential to cause delays that could be costly for the department.

In the case of the Office 365/SharePoint Online user, your Service Administrator (this is the person in your company who is responsible for managing the online SharePoint site) does have some ability to recover content. However, they cannot recover a site that was deleted by mistake and they have no disaster recovery capability.

They can, however, recover from both a first stage and second stage recovery bin, items accidentally deleted (and in some cases the user himself can recover), and if a site is corrupted, the Admin can use SharePoint Designer to revert to the site definition. But if you are looking for more than these basics, the agent-server model solutions aren’t going to work for you, because you don’t have access to the actual server to install anything.

The Best Backup Option for Your Organization...

The backup and restore capabilities most organizations want and need for SharePoint today are fairly simple (or so they would seem). Organizations want the ability to manage content on a site or individual basis. That includes storage and retrieval of individual items or sites so that when something does happen, it’s easy to get the content back and it’s easy to archive selected sites/content that are no longer needed daily, but must be retained. This is certainly the case in individual departments.

Take some time to really think about what you need. Check into what is currently offered for backup and restore capabilities for your servers and decide if that’s sufficient to meet your needs. Learn what your most frequent backup and restore requests are for SharePoint. Then decide on the approach that works for you.

We are curious to hear your SharePoint backup story. Are you implementing a highly available environment that doesn’t require a separate SharePoint backup solution? Are you looking for more basic backup and restore functionality that can be supported at a department level? Tell us your story.

Title image courtesy of pzAxe (Shutterstock).

Editor's Note: You may also be interested in reading: