Until now, this book has focused on disaster recovery and backup from the point of view of the business stakeholders and the infrastructure owners. A full farm backup will recover content databases, farm settings, solutions, and service applications. These solutions are only useful if the entire farm is lost; they don’t address recovery from a user’s perspective. Users sometimes only need to recover smaller parts of the farm, as their focus is just on their content. SharePoint provides options for recovering the following elements of interest to users:

• List items
• Documents
• Lists
• Libraries
• Sites
• Site collections

The following low-level configuration and structuring elements can also be preserved:

• Lists of who has access to one library or site
• Site columns and content types
• Web Part pages

SharePoint puts more and more of the options for preserving content into the hands of the users themselves. This makes sense: they can preserve a site or list immediately without having to ask the IT department to do it for them. The focus of this book so far has been what the architects, farm owners, and SharePoint strategists can do to deliver a high availability and disaster recovery strategy. This chapter shows that the means to back up and restore content are increasingly becoming available to the user community. Knowing the information contained in this chapter means you can plan for training and processes to ensure that users can Do It Themselves. Specifically, with Service Pack 1 for SharePoint 2010, users can now restore deleted sites from the Recycle Bin. This is a sure sign that the trend is toward users owning recovery of data, not IT.

Even an enterprise architect occasionally needs a few small tools in their box for backing up and recovering these small parts of the farm. Knowing how to use the big tools to back up the entire farm is only part of the range of options you should have in the event an individual content owner requests a solution to maintain their own disaster recovery strategy. If some of the smaller parts of the farm are lost, you can recommend the options covered in this chapter to restore them. It shouldn’t be necessary to restore a copy of a whole farm to get one list back.

Again, the purpose of this chapter is to show these Do It Yourself (DIY) options to put some of the tasks of maintaining backups of valuable content and settings in the hands of the users. I am using DIY in the sense that these are tools the users themselves can use without requiring farm administrator rights. Some require Site Collection Administrator rights, like saving a site as a template, but others, like recovering a file from a Recycle Bin, only require site membership. If you have focused most of your energy on looking at SharePoint from the 10,000-foot architecture level, you may have missed some of the small, handy options available to your users, so I have focused this chapter on detailing them for you.

One of the reasons SharePoint, and indeed Microsoft in general, is successful is that it puts the control in the hands of the users. Technology is complicated, but tools can use simple metaphors to make them more accessible. SharePoint allows users to back up and recover some of their own content; in this way, it not only saves resources on the infrastructure side, but it also saves the users’ time because they can restore what they need more quickly.

Screenshots here are from SharePoint 2010, but they are for illustrative purposes only; later versions have the same functionality.

This chapter will focus on the following recovery options:

• The Recycle Bin
• Versioning in SharePoint
• Recovery of sites and site collections
• Office as a DR tool
• Templates

Let’s start with the simplest scenario: accidental deletion of a document.

The Recycle Bin

Despite appearances, every SharePoint site doesn’t fully delete a document or list item if you select that option. It actually hides the item from the List view and displays it instead in the Recycle Bin. It is not moved until it is really deleted. Until then, if you restore it from the Recycle Bin, it appears again in the list with all the same permissions, version history, and list item ID because it was not actually deleted at all. That happens later depending on the settings for the site.

Versioning As a Recovery Tool

Versioning is the functionality that keeps each previous iteration of a document as a separate file; you can open a copy of the file as it looked in the past without losing the current iteration. In the context of DIY DR, it means that if a user overwrites or deletes part of a document, she can recover it from the previous version of the document. This is often overlooked as a means of recovering lost content. But it must be configured by the site administrator, and the user must diligently create versions of the document—not just keep pressing Save. Setting the versioning for an individual library is done via the Library Settings page (Figure 8-7).

Figure 8-8 shows the settings page.

It is wise to set a limit on the number of versions kept because each version takes up the same amount of space as the main file in SharePoint 2010. SharePoint 2013 introduces shredded storage, and while this greatly improves the I/O characteristics when saving incremental changes to SharePoint, it has a net negative impact on upload and download speeds. This can really add up. I once had a situation where 400 versions of a 3MB Excel spreadsheet were using up all of a site collection’s quota: 1,200MB is about 1.2GB.

Requiring checkout ensures users create a “hard” version of the document each time they want to edit it. If a user opens a file and starts to edit it, this is called a “soft” version. This is because a new version is not created until he explicitly checks it back in. It is checked out to him behind the scenes and locked, but there is no new version yet even though changes are saved. This option can slow down access to files, however, so it should only be enabled if the documents must have this level of control. User training should explain the value of versioning as a DIY DR option.

If you wanted to set this all across your sites, you would have to create a site template with these options set. What constitutes the best settings here will require consultation with your users. Best practices would be to ensure versioning is turned off if it’s not needed. A good threshold is 10 versions. This is reasonable when there are 3 to 5 people collaborating on a document, as each of them will have around 2 to 3 versions of the document. When an 11th version is added, it becomes number 10 and the first is removed. There is no hard and fast rule, however. Training users to know about and adjust these settings themselves is the ideal solution here. They are not meant to be controlled centrally, which is why they are available at the Library level.

Recovering Sites and Site Collections

The philosophy behind SharePoint has always been to delegate decisions to users, like with versioning. Deleting a whole site collection and all its content is quite easy for the owner of that site collection to do. From a user point of view, after clicking the option to delete a site collection, the owner is presented with the message shown in Figure 8-9, which warns them of the ramifications. Even after they click Delete, another prompt appears to ensure they want to do this (see Figure 8-10). But occasionally mistakes are made.

Previous to Service Pack 1 of SharePoint 2010, the only way to restore the site collection was for the site collection administrator to ask the farm administrator to take the backup of the content database and restore it to the night before, thus restoring the site collection—and many other site collections in the same content database. This was not a satisfactory solution as in most cases it lost more content than was deleted. Deleting subsites also gave similar dialogs, but if the site had to be restored, again the only option was to bring it back from a backup of the whole content database.

However, Service Pack 1 for SharePoint Server 2010 added the facility to place subsites in the second-stage Recycle Bin (Figure 8-11). This is the clearest indication that backup and restoring have become more user-centric.

(Get-SPDeletedSite).Count

Get-SPDeletedSite | where{$_.SiteId -eq "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"} | Restore-SPDeletedSite

Office As DIY DR Tool

It is worth mentioning, even though it’s not strictly SharePoint, that Word also helps preserve your users’ content by auto-saving and using something called the Backstage view. This is the default view when you click the File tab in Office. Documenting, training, and presenting this to users is the likeliest route for this information to get to them. I am presenting it here as another method for recovering lost content in the interest of completeness. It’s part of your organization’s disaster recovery processes in the sense that it’s a way to recover data. In prior versions of Office, Word would periodically save your document in the background when you were editing it. This file was retained so the user could use it to recover their work if the application crashed. For Word, Excel, and PowerPoint, Office 2010 (and Office 365) improves on this idea. In the Backstage view, Microsoft exposes the periodic auto-saved files from your current editing session and allows you to compare or restore them as the newest document (see Figure 8-12). Even if you don’t save a file, these are kept for five days.

These unsaved versions are purged when you save and close your editing session. The settings for how documents are saved are found in File Word Options Save (Figure 8-13).

Even if you close an editing session without saving the file, Office will now keep the last auto-saved version. When you open the document again, the unsaved version will appear in the Versions section of the Backstage view’s Info window (see Figure 8-14). Office also lets you access it directly from the Backstage view by clicking Manage Versions in the Info window and selecting Recover Unsaved Documents (see Figure 8-15). The Recover Unsaved Documents link also is available at the bottom of the Backstage view’s Recent window.

Content Backup Using Templates

Another way in which SharePoint is putting content retention in the hands of users, albeit as an indirect benefit, is in the use of the SharePoint template process. Templates in SharePoint Server are intended to allow you to reuse content by making a copy of a list or site, including its content if required, and allowing you to make a new list or site in a new location with that same content. This functionality can also be used to make a quick backup of a list or site at any time by any user who has only site owner rights, even though this is not its stated purpose. So if a site owner desires an extra level of security, this can be achieved without the intervention of the farm-level administration staff. This can be useful if an instant snapshot is required.

It should be noted this method will not preserve the Created By and Created time, nor will it preserve the access rights on the site or list. It will, however, preserve the content and views, which would likely take more time to recreate. Another caveat: Microsoft has restricted the maximum size of list and site templates to 10MB (10,485,760 bytes). If you try to save site/list templates that are larger than 10MB in size, you will get a “The list is too large to save as a template. The size of a template cannot exceed 10485760 bytes.” error. To resolve this issue, I have seen it suggested you can run this command in the command prompt:

stsadm -o setproperty -propertyname max-template-document-size -propertyvalue 524288000

However, I don’t recommend you do this. It can lead to errors in the restore process of the site; sometimes the command completes successfully, but the limit stays in place. With these warnings in mind, templates are still a useful way to make a quick backup of content, so I will show you how to do it. If your site is too large to be preserved this way, using Central Administration is your only fallback—and one that is not available to the average user.

Summary

This chapter shows that the task of maintaining backups of valuable content need not be the exclusive domain of the IT staff. Giving users the responsibility for and means to back up their own content is an excellent idea from an organizational point of view, as it is likely to save resources in both backup space and IT person-hours. IT usually has to back up everything that users produce because IT has no idea what’s important and what isn’t. If something goes wrong, the pressure is on IT to have preserved the right content and to be able to recover it. If users own these processes themselves, they will have a greater sense of control and ownership of the platform and a sense that they can create reassurances for themselves. This has the added benefit of freeing up resources in the IT department for other tasks. It not only saves resources in the form of people; a quick backup of a site or list using these methods means that large amounts of unnecessary data doesn’t need to be duplicated in multiple locations. This way, there is a duplicate but it’s for a good reason. Users can think of it as their own personal lifeboat in case of disaster.