Confi guring SharePoint 2010 for High Availability Backups WHAT’S IN THIS CHAPTER? Methods for backing up content and confi guration Restoring the information you’ve backed up Keeping SharePoint 2010 online in the face of adversity It’s terrifying to think about, but someday, something terrible might happen to your SharePoint 2010 servers. Some mean users might delete content that they want back, right now, of course. A hard drive may decide to take an early retirement, or a stray volcano may take out your data- center. While we all hate to think about it, these things do happen. To fend off that diabolical Murphy, you have to put some plans into place. If you plan accordingly, you can keep your SharePoint 2010 farm safe from any bad luck that might come your way. Attacks come in different forms and not all organizations need protection from all kinds of fail- ures or problems. Determining which of the world’s evils you want to protect your servers from is the fi rst step. In this chapter we cover the different options you have with SharePoint 2010 out of the box and what kinds of situations they will protect you against. DETERMINING YOUR BUSINESS REQUIREMENTS Business continuity management can be summarized as an organization’s processes and proce- dures to create and validate a logistical plan outlining how to recover and restore interrupted critical functions within a predetermined time following a disaster or disruption. The prede- termined time by which the organization will recover and/or restore is guided by several objec- tives, including the following: 12 304 CHAPTER 12 coNfigUriNg sharePoiNt 2010 for high availaBility BackUPs Service-level agreements (SLAs) — The SLA is the cornerstone of keeping the businesses or end users happy. It is a contract, an agreement between the end users and the service pro- vider. In this case that is whoever is in charge of the keeping the SharePoint 2010 farm up. The SLA usually defines acceptable levels of downtime, both planned and unplanned, and other metrics that are defined in the following bullets. Operational-level agreements (OLAs) — The OLA is similar to an SLA, but it is between sup- port groups, not between a support group and the customer. In the SharePoint environment, the SharePoint support team as well as the SQL and Active Directory support team may have responsibilities outlined in a company’s OLA. Recovery point objectives (RPOs) — The RPO helps define the acceptable level of data loss. When this is defined in the SLA it helps keep everyone’s expectations the same. Usually the shorter the RPO, the more expensive the solution. Examples of RPOs are “Anything that existed at midnight when the backups ran” or “Never lose more than two hours’ worth of data.” Recovery time objectives (RTOs) — Your RTO is how long it will take to recover from a disaster. If the RTO is three hours, then the SharePoint 2010 farm should be back on line within three hours of the failure. It’s important to note that your RTO can be longer than your RPO. For instance, an example SLA may state the RPO is one hour, and the RTO is three hours. If a failure happens at 9:59 in the morning, all data that existed at 8:59 or earlier can be restored. However, since the RTO is three hours, that data may not be available until 1:00, as that’s three hours after 9:59. Sounds like a great excuse for an early lunch. These objectives apply both within and across the boundaries of the two primary scenarios in which business continuity management applies: high availability and disaster recovery. This chapter describes these two objectives and explains how the new capabilities offered by SharePoint 2010 can help you achieve them. Keep in mind that, as with many of the new features in SharePoint, the backup and recovery features are merely facilitating the technical implementation of a business plan. You, as the administrator of the farm, will often be the driving force in the creation or updating of this business plan, but remember that your role is to provide technical guidance as to what is capable in SharePoint 2010 and to implement what the business decides. When planning business continuity management, you should adhere to a process that begins with analysis to clarify the various scenarios and threats, and assess their potential impact, that will guide your solution design. You should also realize that there is rarely a “one size fits all” approach to this process. Different types of data require different recovery plans. Usually it is the most strin- gently controlled data in your organization that ends up making the hard decisions (and often the most costly decisions) for the rest of the organization, for instance, if a second failover data center is required because the data is just too valuable to the business. The next stage is the one everyone hates, the documentation stage. Here is where you plan, document, and prepare your solution design, identifying the most cost-effective solution that meets the main requirements from the impact analysis stage. The solution design is based primarily on the objectives or requirements to which you are required to adhere as set forth by any SLAs, RPOs, or RTOs. Content Recovery 305 The next step in the process is the implementation stage, where you carry out the results of your business continuity management planning. At this point you should be prepared to test your solu- tion and gain organizational acceptance as the next stage. Testing and acceptance is critical in order to validate that the solution satisfies the organization’s recovery requirements. Commonly, in this stage of planning you may discover that the solution fails to meet expectations, perhaps as a result of insufficient recovery requirements or inaccurate recovery requirements. Other common failures at this stage in planning result from design flaws and/or implementation errors. Testing and finally acceptance is an important stage. It’s what all this work has been moving us toward. All the plan- ning and documentation is no good if the customer won’t sign off on it. Upon successful completion of the testing and acceptance stage, you can finally begin the last stage of the business continuity management process, which is maintenance. The maintenance stage includes preparation, validation, and handoff of all corresponding documentation, testing, and veri- fication of the solution, including testing and verification of the processes and procedures required to properly execute the solution. Because each organization has unique requirements and objectives, there is no definitive manual or set of guidelines that can ensure you find the most effective solution. Therefore, you need a thorough understanding of not only what capabilities are provided by the service you are protecting, but also what aspects of that service are critical to your operations. Remember that this is not a one-time activity, as business rules and processes can change within an organization, and adding or removing sets of data can drastically change your company’s data availability requirements. In this chapter, at a high level, we break down the three most common areas of planning associated with SharePoint 2010: content recovery, disaster recovery, and high availability. After ensuring that your business continuity management plan includes these areas, you can take advantage of the fea- tures and capabilities of SharePoint 2010 to meet your defined objectives. CONTENT RECOVERY Content recovery is the most frequently leveraged aspect of data restoration with SharePoint 2010. Depending on both the scope and nature of recovery, several options are available for recovering data lost through deletion or corruption, including the following: Versioning Recycle Bin SharePoint Administration Tool Windows PowerShell Central Administration These rich capabilities used both independently and in conjunction provide a framework for your disaster recovery processes and procedures. In addition to these new and improved capabilities, SharePoint 2010 also supports the use of SQL Server snapshots as part of its content recovery scenarios. 306 CHAPTER 12 coNfigUriNg sharePoiNt 2010 for high availaBility BackUPs About SQL Server Snapshots SQL Server snapshots are a SQL Server Enterprise and Developer Edition feature that enables you to specify a point in time from which you wish to preserve the contents of a database. Snapshots do not actually make a copy of the data, but instead create a new database that is prepared to receive content from the source database as the content is replaced, changed, or overwritten. When you restore the snapshot to the live site, those previous values are reapplied to the live database, which brings the database back to the state it was in at the point in time when the snapshot was taken. It is important to understand that adding more SQL Server snapshots for a database slows the per- formance of that database. This is because each time a write operation takes place on the source database, the previous value has to be registered on each snapshot. Content Storage Overview Understanding how content is stored and organized in SharePoint 2010 is important for under- standing the technologies used to protect it. In most scenarios, binary large objects, or BLOBs, comprise the deployment. These are the individual files commonly introduced by end users, such as PowerPoint presentations, Word documents, and so on. The binary large objects are stored in data tables within one or more content databases. In SharePoint 2010, content databases are the small- est unit of content representation on the file system and are hosted by individual web applications. It might not be obvious, but it is worth noting that if you have good backups of your content data- bases, you can always recover individual documents. You may have to jump through some hoops, but the content database contains all of the content for the site collections it contains. Take care of the databases; they may get you out of a jam some time. The binary large objects are assigned to the specific document library or folder to which they were placed within a site hosted within a site collection, which is the principal point of initial interaction that end users have with SharePoint. A site collection is a set of sites that have the same owner and share administrative settings. It contains a top-level site and can contain one or more subsites. A site is the primary means of organizing related content in SharePoint 2010 and is host to document libraries and folders. Document libraries are a location in a site containing files of one or more large binary objects or content types. Document libraries are designed to manage and store related documents, and to enable users to create new documents of the appropriate types. A folder is a named subdivision of the content in a document library, similar to the concept of folders in a file system. The primary pur- pose of folders is to organize content to match the expected functionality of the library. Figure 12-1 shows the farm hierarchy. The Recycle Bin The Recycle Bin, initially introduced in Windows SharePoint Services 3.0, provides self-service recovery of simple content — for example, lists and list items — to users of SharePoint 2010. The Recycle Bin is enabled by default and is configured on a per-web-application basis. Content Recovery 307 Web Application Web Application Content Database Site Collection Top Level Site Content Database Content Database Site Collection Site Collection Site Collection Top Level Site Site Site Site Site Site Site Top Level Site Top Level Site Farm FIGURE 121 The Recycle Bin in SharePoint 2010 is unchanged from Windows SharePoint Services 3.0 and sup- ports two Recycle Bin stages: Stage 1 — The first-stage Recycle Bin is located at the site level and is available to users with Contribute, Design, or Full Control permissions. When a user deletes an item from a site, it is sent to the first-stage Recycle Bin, where it can be recovered by that user. Items located in this stage affect the overall site quota and are retained until the specified time period has been reached as configured by the administrator in SharePoint 2010 Central Administration (the default setting is 30 days). Stage 2 — The second-stage Recycle Bin is located at the site collection level and is organized in two distinct views: the first-stage Recycle Bin just described and the second-stage Recycle Bin described here. Items deleted from the first-stage Recycle Bin are submitted to the second- stage Recycle Bin, where they can be recovered by the site collection administrator. Items are retained in the second-stage Recycle Bin until the specified time period has been reached, similar to the first-stage Recycle Bin (the default setting is 30 days), or until the sec- ond-stage Recycle Bin has reached its allocated size limit, established by the administrator in SharePoint 2010 Central Administration, at which time the oldest items are permanently deleted. The time limit for the Recycle Bins reflects the total time after the item was initially deleted, not the time spent in either Recycle Bin stage. When a second-stage Recycle Bin is enabled for a web application, the amount of disk space available to the second-stage Recycle Bin is defined as a percentage of the quota allotted to each individual site collection. Items stored in the second-stage Recycle Bin do not count toward the site quota; however, the size that is specified for the second-stage Recycle Bin increases the total size of the site and the content database that hosts it. If no site quota has been set, there is no limit on the size of the second-stage Recycle Bin. 308 CHAPTER 12 coNfigUriNg sharePoiNt 2010 for high availaBility BackUPs Figure 12-2 provides an overview of two stages of the Recycle Bin and points of interaction. 1st Stage Recycle Bin Live Items 2nd Stage Recycle Bin End user Delete End user Restore Administrator Restore End user Delete 2nd Stage Quota Site Collection Quota Object Model Recycle Bin Administrator Delete [Site Collection Recycle Bin] Administrator Flush w/ storman.aspx Administrator Delete Administrator Restore w/ storman.aspx Recycle Bin Timer Job Definition FIGURE 122 Keep in mind that the total life of a document in your SharePoint farm equals the amount of time the document is live in a site AND the amount of time it spends in the Recycle Bin. This time can have a signifi cant impact on your organization’s Business Records Retention Policy. Make sure that the team that manages Business Records policies for your organization is aware of and has a say in the Recycle Bin’s policies. Each stage of the Recycle Bin can contain multiple copies of a document, even where they share the same fi lename and source. It is important to understand that these documents cannot be restored over an existing copy of a document or to recover previous versions or overwrite documents — that functionality is provided through versioning, discussed later in this chapter. Content Recovery 309 Configuring the Recycle Bin The Recycle Bin is configured at the web application level by the server farm administrator. Each web application can have its own settings depending on the business processes and continuity requirements necessary to support the content hosted within that web application. To configure the Recycle Bin, use the following steps: 1. Open SharePoint 2010 Central Administration. 2. Under Application Management, click Manage web applications. 3. Click the web application whose Recycle Bin settings you want to change; you’ll notice that many buttons light up on the Ribbon. 4. Click the General Settings button in the Ribbon, and then click General Settings again from the dropdown. Scroll to the bottom of the web application’s general settings to find its Recycle Bin settings. Figure 12-3 shows the Recycle Bin settings for a web application. The default retention settings have been left for the first stage, 30 days. In this example, the second stage has been turned off. This means that if a user empties the first stage, the document cannot be recovered through the Recycle Bin. Regardless of whether the second stage is turned on or not, 31 days after a document has been deleted it will no longer be able to be recovered through the Recycle Bin. Another caveat to keep in mind is that disabling the Recycle Bin entirely will immediately flush it. This means if you disable it and immediately regret doing so, there is good news and bad news. The bad news is that all of the documents that were in the Recycle Bin are gone. The good news is that your content databases have a lot of good white space in them. There’s a silver lining to almost anything if you look hard enough. FIGURE 123 310 CHAPTER 12 coNfigUriNg sharePoiNt 2010 for high availaBility BackUPs Keep in mind that while the first stage of the Recycle Bin counts against your site collection quota, the second stage does not. For example, if you specify a default Quota Template of 1GB per site col- lection on a web application, allotting a 50 percent quota for the second-stage Recycle Bin allocates 500 MB for the second-stage Recycle Bin and up to 1.5GB per site collection on the web application. This is important when sizing your content databases or trying to answer the age old question; “Why is my database so big!?” You can allocate up to 100 percent for the second-stage Recycle Bin quota. Versioning Versioning can be loosely compared to the Recycle Bin in that it provides self-service recovery of content for users — for example, if data loss occurs as the result of overwriting a document. Through versioning, SharePoint 2010 users can keep multiple versions of the same document in a document library; and in the event of an undesired change, such as an overwritten document or cor- ruption, users can easily restore the previous version. Versioning is configured by the site collection administrator on a per-site basis and is not enabled by default. Versioning accepts the following configurations: No Versioning — The No versioning setting means prior versions of documents and their subsequent history, including comments, are not recoverable. No versioning is the default setting. Create Major Versions — This setting means that each iteration of a document becomes a full version of the document, using sequentially numbered versions (e.g., 1.0, 2.0, 3.0, etc). Users with permissions to the document library may view each updated version of a docu- ment. Note that this setting does not differentiate between draft versions and published versions. Create Major and Minor Versions — This setting means that documents can exist in one of two possible states, as denoted by their extension: Versions with a .0 extension represent a major version, whereas versions with a .1 through .9 extension represent a minor version of a document. This versioning setting provides the greatest degree of security granularity because in most scenarios, only users who can edit major versions can edit the minor versions associ- ated with that item, whereas read-only users can only view the major versions. Site collection administrators should manage versioning proactively due to the manner in which versions are maintained. Versions of files and documents are not represented as the differential between two or more documents, but as complete, new copies of those documents. For example, if a user opens a document and makes a minor grammatical modification and saves the document as a new version, it becomes a completely new document, with those changes and the previous version intact. You should proactively manage versioning by educating site collection administrators, estab- lishing quotas on site collections in a web application, and monitoring storage utilization as needed. Figure 12-4 shows an example version history. Lack of attention to proper versioning implementa- tion is one of the more common causes of Content Database growth due to overuse of versions, as well as causing restores of files from backups because of lack of use of versions. . improved capabilities, SharePoint 2010 also supports the use of SQL Server snapshots as part of its content recovery scenarios. 306 CHAPTER 12 coNfigUriNg sharePoiNt 2010 for high availaBility. capabilities of SharePoint 2010 to meet your defined objectives. CONTENT RECOVERY Content recovery is the most frequently leveraged aspect of data restoration with SharePoint 2010. Depending. guring SharePoint 2010 for High Availability Backups WHAT’S IN THIS CHAPTER? Methods for backing up content and confi guration Restoring the information you’ve backed up Keeping SharePoint 2010