Simplifying SharePoint Backup and Recovery

Simplifying SharePoint Backup and Recovery Written by Juan Morris, Professional Services Consultant, & Ilia Sotnikov, Product Manager Quest Software White Paper

Copyright Quest Software, Inc. 2008. All rights reserved. This guide contains proprietary information, which is protected by copyright. The software described in this guide is furnished under a software license or nondisclosure agreement. This software may be used or copied only in accordance with the terms of the applicable agreement. part of this guide may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording for any purpose other than the purchaser's personal use without the written permission of Quest Software, Inc. WARRANTY The information contained in this document is subject to change without notice. Quest Software makes no warranty of any kind with respect to this information. QUEST SOFTWARE SPECIFICALLY DISCLAIMS THE IMPLIED WARRANTY OF THE MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Quest Software shall not be liable for any direct, indirect, incidental, consequential, or other damage alleged in connection with the furnishing or use of this information. TRADEMARKS All trademarks and registered trademarks used in this guide are property of their respective owners. World Headquarters 5 Polaris Way Aliso Viejo, CA 92656 www.quest.com e-mail: info@quest.com U.S. and Canada: 949.754.8000 Please refer to our Web site for regional and international office information. Updated Oct 14, 2008

CONTENTS OVERVIEW... 1 INTRODUCTION... 2 LEVELS OF DATA RECOVERY... 2 DISASTER RECOVERY SCENARIOS... 2 CREATING YOUR BACKUP STRATEGY AND RECOVERY PLAN... 6 NATIVE BACKUP AND RECOVERY TOOLS AND TECHNIQUES... 7 BACKGROUND... 7 TOOLS AND TECHNIQUES... 7 GRANULAR RECOVERY IN SHAREPOINT... 13 LIMITATIONS OF NATIVE TOOLS... 13 GRANULAR RECOVERY USING EXISTING BACKUPS: QUEST RECOVERY MANAGER FOR SHAREPOINT... 13 SAMPLE SCENARIO... 14 TOOL SUMMARY... 15 CONCLUSION... 16 ABOUT THE AUTHORS... 17 ABOUT QUEST SOFTWARE, INC.... 18 CONTACTING QUEST SOFTWARE... 18 CONTACTING QUEST SUPPORT... 18

OVERVIEW For many organizations, SharePoint is a platform of choice for data storage and collaboration. Therefore, keeping SharePoint data safe and available is critical. Microsoft provides a number of utilities to help SharePoint administrators back up and recover lost SharePoint data. This paper describes those tools and explains the backup and recovery scenarios in which they are useful. It also identifies a key limitation of those tools: they do not provide quick granular recovery of a particular lost SharePoint item the most common recovery scenario. The paper concludes by introducing Quest Recovery Manager for SharePoint, which provides easy and fast granular recovery of SharePoint items (including individual documents, lists, document libraries, sites, and workspaces) from your existing backups. 1

INTRODUCTION Before we begin discussing backup and recovery tools, we need to examine exactly when backup and recovery plans take center stage. What are the common scenarios when data recovery is needed? Levels of Data Recovery Data recovery can be broken down into three primary levels: document recovery, site recovery, and full disaster recovery. Document-level (Content-level) Recovery Most data recovery needs are at the document or content level: a user inadvertently deleted or updates a document or other item, such as a task, discussion thread, folder, list, or document library. This scenario is far more likely to occur than one that requires a full disaster recovery. Site-level Recovery The loss of a site is usually caused by data corruption, but inadvertent deletion by a user is also common. Provided the administrator has performed backups on a regular basis, site-level recovery is possible, but it is not a trivial task. Full Disaster Recovery Most computer hardware fails at some point. If a server that contains vital information crashes, full recovery could take days. In fact, if necessary precautions and contingency plans have not been implemented, full recovery may be impossible. Disaster Recovery Scenarios Let s see how each level of data recovery is associated with the three main disaster recovery scenarios: database loss, server loss, and farm loss. Database Loss A database loss event is when the data hosted in a site collection becomes unavailable from the content database due to an event such as the accidental deletion of files, data corruption, or administrative error. Database loss should not to be confused with data unavailability, which can be defined as the temporary loss of data due to a network outage or similar event. Database loss is not necessarily related to hardware failure; in large deployments, the remaining equipment in a farm is usually fully functional. 2

In determining the cost of a data loss event, one must place value on the data as it relates to the continuation of operation without it, its recreation and notification of its loss. A database loss event is one of the simplest recovery scenarios; a simple native SQL restore may suffice for full recovery. Server Loss Recommendations: Create and use meaningful database naming conventions; never use the default names (such as WSS_Content_<GUID>). Consider maintaining a list of correspondence between content databases, web applications, and site collections, or deploy a reporting tool that provides this information. This list can significantly simplify troubleshooting when a site collection becomes unavailable due to database issues, and will also help you prioritize the business importance of databases during recovery. The level of recovery required by server loss depends on the type of server affected: Front end Application Index/Search Database The loss of a front-end server is fairly easy to remedy: simply set up a new server with a configuration similar to the compromised one and allow SharePoint to propagate all settings from the configuration database, including the Internet Information Server (IIS) settings, load balancing configurations, and DNS redirections. Recovery from application server loss can be more complex, depending on the severity of the loss. In the worst case scenario, you may need to reinstall an OS and SharePoint Server with the correct application server roles, create or extend the Web Applications to the new application server, restore any available backups, and finally start the search service and restart the timer jobs. Index server loss directly impacts users, especially if you have large amounts of data. Out of date index can quickly make search results so inaccurate that SharePoint is virtually unusable. You can use SharePoint administrative tools to re-index your data on the replacement server. 3

Loss of a database server can usually be considered a farm loss. SharePoint natively stores all data and 95% of its configuration in a SQL.config database, so losing a database server equates to losing all data. Recovering from a farm loss is discussed in the next section. Farm Loss Recommendations: As a best practice, utilize SharePoint solution packages for any customization. Solutions are registered in the config database and will be automatically propagated to new front end servers if you have to replace them. Plan server topology with redundancy in mind to mitigate the impact of server loss. SharePoint allows use of multiple front end and search servers and can benefit from SQL clustering. Redundancy does not mean there is no need to have a proper backup plan, but it allows recovery from server failures with minimal or no downtime for the users. Farm loss is the most costly to any organization. If database servers and front end servers are lost, it is recommended that a new farm be installed: create a new configuration database, restore all web applications from backups, and the re-deploy any customization. Following a successful recovery, new front end servers can be added. Other configurations that have to be re-done may include IIS settings, such as host headers, etc. It should be noted that Microsoft System Center Data Protection Manager 2007 (DPM) can restore the configuration database, content databases, and customizations to a new SQL server; however, this utility requires that the following prerequisites be met: Web servers are configured the same way (from the last recovery point). Instances of SQL Server are configured with the same names (from the last recovery point). Instances of SQL Server are configured with the same drive configuration (from the last recovery point). Recommendations: Keep a written record of all configuration changes and customizations deployed in a farm. Create a step-by-step recovery plan for complete farm loss and test the procedure periodically. Keep copies of both documents outside the SharePoint farm. 4

The SharePoint Configuration Analyzer utility can help in the strategic planning of a recovery strategy. It must be downloaded and installed separately. SQL Clustering provides fail-over capability. Having two or more physical servers (nodes) functioning in unison makes automated fail-over possible: if one server fails, the other(s) can assume its responsibilities (based on configuration) without affecting service to the front end. This can prevent farm loss. 5

CREATING YOUR BACKUP STRATEGY AND RECOVERY PLAN To be able to execute your recovery plan, you must have accurate and accessible backups. Despite this dependency, creating a sound backup strategy should be considered a separate issue from creating a recovery plan because backup and recovery have different characteristics: Backup Ongoing task Usually part of a more holistic approach to overall backup Needs to fit into enterprise framework Data center driven Happens off hours Recovery Event-driven Application-specific Help-desk focused Happens on hours Time-sensitive Capacity-sensitive What needs to be backed up for a SharePoint deployment? The answer is simple: everything! A sound backup strategy may includes (but is definitely not limited to) metabases, system states, home directories, install path information, assemblies, binaries and code, customizations, definitions, and logs. Recommendation: Consider whether the backup technology you already have in place can handle your SharePoint backup needs. The core of SharePoint is SQL Server, so if you are already using native or third-party tools to back up SQL, you can apply them in your SharePoint backup strategy while choosing a SharePoint-centric recovery tool. 6

NATIVE BACKUP AND RECOVERY TOOLS AND TECHNIQUES Background In the first deployments of the Microsoft SharePoint Products and Technologies, different storage methods were used for each component: SharePoint Team Services used the Microsoft SQL Server 2000 Desktop Engine (MSDE), while the SharePoint Portal Server 2001 used the Microsoft Exchange Server Jet database engine with some slight customization. Therefore, SharePoint administrators had to maintain (and possibly execute) two unique recovery strategies. In later releases, all components were consolidated to a single storage technology and integrated with SQL Server, so now a recovery plan can be focused around one strategy and one technology. Along with unifying the content storage mediums, Microsoft Office SharePoint Server 2007 (MOSS), SharePoint Portal Server (SPS) and Windows SharePoint Services (WSS) v2.0 and v3.0 introduced some enhancements that made backup and recovery simpler and easier: the SharePoint 2007 Recycle Bin, SPS Data Backup and Restore (spsbackup.exe), STSAdmin.exe, SMigrate.exe, SharePoint Designer, NTBackup, SQL Enterprise Manager, SharePoint Backup and Restore (Central Admin), log-shipping with a secondary database, and IISBack.vbs (IIS 6.0). Tools and Techniques The sections below describe the basics of most of these tools and techniques, as well as the types of recovery each is best suited to achieve. SharePoint 2007 Recycle Bin While the Recycle Bin is not customarily thought of as a backup tool, it is the first line of defense for a recovery strategy. Deleted items can quickly be restored from the Recycle Bin without any secondary applications. The Recycle Bin operates as a dual-stage data storage container: prior to the expiration of the withholding period, end-users can recover data from the first stage; after that, an administrator must retrieve the data from the second stage. Recommendation: The Recycle Bin provides content-level recovery: a user or site owner can restore accidentally deleted documents or lists. Its capabilities are somewhat limited for help desk or IT 7

administrators if users cannot find their data and need to call for help. SPS Data Backup and Restore SPS Data Backup and Restore (spsbackup.exe) is a SharePoint 2003 command-line utility with an optional GUI front end that is intended for backing up portal databases. SQL Server Client Tools must be installed for the utility to leverage native SQL database backups while keeping SPS indexing intact. This utility is STSADM catastrophic backup in SharePoint 2007. An important drawback to this utility is its inability to perform loss-less restore; in fact, potentially serious data loss can result. Moreover, this utility only supports the complete overwriting of existing data. In order to achieve a more granular restore (such as just one particular document), you must perform the restoration at a separate location and then copy back just the items you need. This method could add substantial cost because it is time consuming and requires a separate piece of hardware. Recommendation: SPSBackup.exe protects in case of database loss and covers most of the disaster recovery from a complete farm loss for WSS version 2.0 and SPS 2003. STSAdm.exe STSAdm.exe is a command-line-only utility with more than 180 operations, some of which address backup and recovery. Running backups and restores requires Administrative privileges both in SharePoint Central Administration and on the server itself. Since STSAdm.exe is a console utility, scripts can be written easily for automation. Although the granularity of this utility is again low, you can use it to back up site collections, sub-sites, pages within the sites, files in document libraries or lists, security and permission settings, feature settings, and indexes. This utility must be run locally on the server that is being backed up or restored. It can be very processor intensive if it is run on the SQL Server back-end infrastructure. A best practice recommendation from Microsoft is not to run this utility during heavy access of the SPS. STSAdmn.exe should be used for small to medium SharePoint environments. STSADM has three major backup-related operations which differ in the level of granularity of backup and restore: 8

STSADM Catastrophic Backup and Restore The catastrophic backup option allows you to back up and restore entire farms, web applications, or content databases. Essentially, this option performs the same operation as the interactive Central Administration Backup and Restore tool discussed below, but the STSADM command can be saved as a batch file and scheduled to run periodically using the Windows Task Scheduler. STSADM Site Collection Backup and Restore STSADM also allows you to back up individual site collections. The granularity of restore in this case is also an entire site collection, which can be restored to the same location or to a different SharePoint web application. Site collection backup is not a complete disaster recovery solution and can only be considered in addition to full database or farm-level backups. If you decide you need additional granular site collection-level backup, be aware that STSADM runs on the SharePoint front-end servers, which typically don t have lots of attached storage available. Backing up to the network share is possible but can dramatically decrease performance. It is also important to know that STSADM restore will overwrite all changes made to a site collection since the backup was made. STSADM Export and Import Export and import operations in STSADM are not designed for backup, but can be used for more granular backup of individual sites. This provides more granularity than other options, but it is not a full-fidelity backup, so certain metadata can be lost upon import. The export and import operations are used primarily to reorganize the content within a SharePoint server farm. Recommendation: Different functions within STSADM can create backups from which you can restore sites (export and import operations); site collections (backup operation); or web applications, databases, or an entire farm (catastrophic backup operation). te that these three functions create different backups, so using them in combination can result in duplicate backups of the same data. SMigrate.exe SMigrate.exe is typically used for migration purposes in SharePoint 2003; however, it can be used for site backup and recovery. If you use it as a backup and recovery tool, note that it can be used only at the web level: it will not back up at the site collection level, and permissions will NOT be 9

restored. In SharePoint 2007, this utility is replaced with STSADM export and import. Recommendation: SMigrate.exe creates a site export and can be used to back up individual sites in WSS version 2.0 or SPS 2003. SharePoint Designer 2007 Backup The successor to FrontPage 2003, SharePoint Designer 2007 allows a user (with power user permission) to create site backups. This enables authorized users to maintain current and recent backups of the sites they support and can be used to back up individual sites or site collections. Some limitations of this tool include that it is not a full-fidelity backup; backing up sites larger than 25 MB is possible but quite awkward; and it is easy to run out of space while making a backup. Recommendation: SharePoint Designer can create site-level backups similar to the site export in STSADM. NTBackup It is generally assumed that all files reside in a SQL database; however, some important files are written to local folders as well. These file include web.config (\InetPub), Web Part assemblies (%systemroot%\assembly), and templates stored in various directories. SharePoint 2007 configuration database keeps copy of all your customizations if you re using a solutions mechanism to deploy them, including the binary files. Generally speaking, you might not need to make backups of the file system on SharePoint front end servers unless there are specific customizations that require you to do so. Recommendation: NTBackup might be required as a part of full farm recovery plan, depending on how you deploy customizations. SQL Enterprise Manager By using SQL Enterprise Manager as the primary administrative tool for Microsoft SQL Server, a DBA can create and administer all SQL Server databases, objects, logins, and permissions in each registered server, including performing SQL Server backups and restores. 10

Recommendation: SQL Enterprise Manager helps protect against farm loss and database loss. SharePoint Backup and Restore (Central Admin) This tool enables you to configure and execute backup jobs. This feature is new in MOSS 2007 and is found on the SharePoint Central Administration site. From a single GUI interface, you can back up not only individual components but also your entire SharePoint farm. Central Administration Backup and Restore protects all content databases and associated search and index files. You can recover to the same configuration or an alternate one. It is important to understand that the configuration database is not backed up by this feature. In case of a complete SharePoint farm loss, you will need to start recovery by creating a new configuration first. This tool has some limitations. It is an interactive tool, so you cannot run backups on a schedule. It is also imperative to understand its all-or-nothing approach: you can restore only to the level of a content database. This means you cannot use Central Administration Restore if you need to retrieve a subset of the information you backed up. Recommendation: Central Administration Backup and Restore protects against database and farm loss. Log Shipping with a Secondary Database Using the native SQL Server log shipping, a database administrator can continuously back up all the transaction logs from a primary database and restore those logs to a secondary database. Since the transaction logs can be configured to contain only differential data, a full backup is not required an important performance consideration. Recommendation: Log shipping can help in the event of database loss. IISBack.vbs (IIS 6.0) The IIS 6.0 metabase is a hierarchical structure (XML) for storing IIS configuration settings (unlike its predecessors in version 4.0 and 5.0, which are binary files that cannot be restored using IISBack.vbs.) Most of the ISS settings common for all front-end servers in a SharePoint farm (such as host 11

header configuration, SSL enabled, authentication, and ports) are stored in the SharePoint configuration database, so normally there is no need to back up the IIS metabase. However, certain tasks, such as creating IP addresses or assigning SSL certificates, cannot be performed in SharePoint and must be done in IIS directly. If you make such changes, you need to back up the IISS metabase. The IISBack.vbs utility can be used to create backup copies of IIS configurations, restore IIS configurations, and provide listings of available backup copies. If a machine goes down, being able to quickly reproduce the signature of that machine can reduce downtime. Backup procedures require that the user be a member of the Administrators or Domain Administrators group on the local computer. A best practice rule is to use "Run as". Restoring a normal configuration may take several minutes to finalize and brief delays are normal. During the restoration process, all sites, and internet services associated with IIS will be temporarily stopped; they will be automatically restarted when the restoration is complete. Recommendation: IISBack.vbs might be required as a part of front-end server recovery and farm recovery plans, if you make changes directly to IIS. 12

GRANULAR RECOVERY IN SHAREPOINT Limitations of Native Tools The tools discussed above can assist the SharePoint administrator with backup and elementary recovery scenarios, but they do not provide effective granular recovery. How long would it take your SharePoint administrator to locate, verify, and restore a particular critical document using these tools minutes, hours, or even days? Could your organization survive the loss of mission-critical data for prolonged periods of time? Organizations need a tool that allows them to recover individual documents, lists, document libraries, sites, and workspaces with little effort. The tool should also enable the administrator to preview any item prior to restoration, eliminating the downtime incurred if the wrong version was restored. And ideally the tool would leverage your existing backup infrastructure and not require the addition of proprietary utilities or databases. Granular Recovery Using Existing Backups: Quest Recovery Manager for SharePoint Recovery Manager for SharePoint is a unique product that enables an administrator to quickly locate and restore SharePoint 2003 and 2007 data with a high level of granularity individual documents, lists, document libraries, sites, workspaces, or full database backups. With Recovery Manager for SharePoint, you can: Leverage your existing backups from any of the following: o SQL Server o Native SharePoint SPSBackup for SharePoint 2003 Central Admin for SharePoint 2007 STSADM catastrophic backup for SharePoint 2007 o Quest LiteSpeed for SQL Server (backups saved to disk or Tivoli Storage Manager) o Microsoft System Center Data Protection Manager (DPM) 2007 o IBM Tivoli Storage Manager for Databases (TSM) Restore SharePoint data anytime and anywhere Discover all backups created for a specific content database. 13

Search for documents by title or document type, either in a particular backup or across all backups in a given date range Generate lists of modified and deleted content sorted by any column View in the corresponding program (based on file extension) and restore documents found in a backup to either disk or e- mail All of these features are available through a single, intuitive GUI that is easy to learn. Sample Scenario Let s consider a simple scenario: you entire farm has failed and no failover is provided. With Recovery Manager for SharePoint, you can tell your CIO that downtime will be minimal because you can simply restore all business-critical sites and web applications (or just document libraries with critical data in them) to any test or secondary SharePoint farm restoring user access to the data long before the original farm is back in working order. You can even apply the restoration as read-only to ensure that no residual side effects occur during synchronization back to the original location later. w imagine the worst case scenario: no secondary environment is available your SharePoint infrastructure has been completely eradicated. With Recovery Manager for SharePoint you can easily extract all critical documents, folders, or even entire libraries to the file system for immediate use even when there is no SharePoint available. 14

TOOL SUMMARY The following table summarizes the tools discussed in this document and the levels of recovery supported by each: Tool Full Disaster Recovery? Site-Level Recovery? Document-Level Recovery? Recycle Bin Yes, in some cases in SharePoint 2007 SPS Data Backup and Restore Yes, in SharePoint 2003 SharePoint Backup and Restore (Central Admin) Yes, in some cases (database or farm loss) in SharePoint 2007 STSAdmin.exe Yes Yes SMigrate.exe Yes, in SharePoint 2003 SharePoint Designer Yes, in SharePoint 2007 NTBackup Might be required in farm loss SQL Enterprise Manager Yes, in some cases (database or farm loss) Log shipping with a secondary database Yes, in some cases (database or farm loss) Recovery Manager for SharePoint Yes Yes 15

CONCLUSION SharePoint administrators need to ensure the smooth recovery of lost SharePoint data in order to minimize downtime and maximize user productivity. Microsoft provides several utilities to assist administrators with backup and recovery, but they are usually limited to disaster-level and sitelevel recovery; using them to recover single documents, lists, and sites takes too long and is too complex. Because the native utilities lack the granularity required for simple day-to-day SharePoint management, Quest offers Recovery Manager for SharePoint, which streamlines the recovery process with an intuitive user interface and granular recovery options. 16

ABOUT THE AUTHORS Ilia Sotnikov is a Product Manager for Microsoft SharePoint management and recovery products at Quest Software. He joined Quest as a part of the Aelita Software acquisition in 2004, and has held various positions from Support Escalation Engineer to Development Program Manager. Ilia has worked on various migration and management products for enterprise deployments of Microsoft Exchange Server and Microsoft SharePoint products and technologies. In his current position, Ilia works with Quest customers and partners, as well as various groups inside Quest, to determine best practices and product directions for Site Administrator for SharePoint and Recovery Manager for SharePoint. He has a blog at http://blog.sharepointrecovery.com/. Juan Morris is a Professional Services Consultant at Quest Software. Prior to joining the Quest team, he served for more than a decade as a principal software engineer and project manager in several organizations, designing and developing enterprise-level and middle-tier integration applications in the areas of regional, national and international security projects. These systems were designed to meet the strict demands of both U.S. Homeland Security initiatives as well as foreign security policies in the areas of access control, energy management, remote monitoring and network video surveillance. Some of these applications included the direct integration of Microsoft SharePoint Products and Technologies for data interpretation and presentation. 17

ABOUT QUEST SOFTWARE, INC. Quest Software, Inc. delivers innovative products that help organizations get more performance and productivity from their applications, databases and Windows infrastructure. Through a deep expertise in IT operations and a continued focus on what works best, Quest helps more than 50,000 customers worldwide meet higher expectations for enterprise IT. Quest Software can be found in offices around the globe and at www.quest.com. Contacting Quest Software Phone: 949.754.8000 (United States and Canada) Email: info@quest.com Mail: Quest Software, Inc. World Headquarters 5 Polaris Way Aliso Viejo, CA 92656 USA Web site www.quest.com Please refer to our Web site for regional and international office information. Contacting Quest Support Quest Support is available to customers who have a trial version of a Quest product or who have purchased a commercial version and have a valid maintenance contract. Quest Support provides around the clock coverage with SupportLink, our web self-service. Visit SupportLink at http://support.quest.com From SupportLink, you can do the following: Quickly find thousands of solutions (Knowledgebase articles/documents). Download patches and upgrades. Seek help from a Support engineer. Log and update your case, and check its status. View the Global Support Guide for a detailed explanation of support programs, online services, contact information, and policy and procedures. The guide is available at: http://support.quest.com/pdfs/global Support Guide.pdf 18