Backup and Recovery for Microsoft SQL Server Using EMC Data Domain Deduplication Storage Systems

Transcription

1 White Paper Abstract Users are faced with many options and tradeoffs when choosing a backup strategy for Microsoft SQL Server databases. This white paper maps out those choices and examines how EMC Data Domain deduplication storage systems preserves data integrity, meets stringent RTO/RPO objectives, and integrates easily into a multitude of active SQL or third-party backup environments. February 2012

2 Copyright 2012 EMC Corporation. All Rights Reserved. EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice. The information in this publication is provided as is. EMC Corporation makes no representations or warranties of any kind with respect to the information in this publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license. For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com. Microsoft and Microsoft SQL Server, Microsoft Exchange, Microsoft SharePoint, and Microsoft Hyper-V are registered trademarks or trademarks of Microsoft, Inc. in the United States and/or other jurisdictions. All other trademarks used herein are the property of their respective owners. Part Number h Page 2

3 Table of Contents Executive summary... 5 Audience... 6 Introduction... 6 Data Domain Product Background... 8 Advantages of Data Domain in a SQL Server Environment... 8 EMC Data Domain Boost... 9 SQL Server Basics Terminology Types of Backups Recovery Models Recovery Techniques Data Domain Integration Best Practices Compression Multiplexing Encryption Backup Application Based Data Deduplication Blocksize Stripes Backup Command Data Transfer Rates Integration Solution Planning Additional Considerations Backup Types IP Network Considerations Data Domain and Third-Party Backup Applications Conclusion Appendix A: Index Fragmentation Addressing the Challenge Appendix B: Additional resources Microsoft Resource Links EMC Data Domain links Page 3

4 List of Figures Figure 1: Native MS-SQL Database Backup Tool... 6 Figure 2: NetWorker MS SQL Client Properties VSS Snapshot Configuration... 7 Figure 3: Dual MS SQL Database Backups NetWorker and Native SQL Server Back Up... 8 Figure 4: EMC Data Domain Boost... 9 Figure 5: Microsoft SQL Server Management Studio Databases Figure 6: Selection Recovery Model Figure 7: Restore Database Dialog Box Figure 8: Restore Database Options Figure 9: Restore the Initial Full Backup then the First Transaction Log Backup Figure 10: NetWorker MS SQL Client Restore GUI Example Figure 11: Native SQL Backup - Disable Compression Figure 12: Multi-striped Database Backup Eight Stripes Figure 13: Database Backup to a Null Device Figure 14: Multiple Null Disk Devices Figure 15: Nominal Database Backup Performance Figure 16: NetWorker Management Console Figure 17: DBCC showcontig Command Output Page 4

5 Executive summary Many database administrators prefer native Microsoft SQL Server backups directly to disk compared to using third-party backup applications. When utilizing native SQL Server backup, there is no reliance on the backup administrative team to perform backups or play a role in database recovery. Additionally, there is no longer a need for the database administrator to become proficient in deploying, configuring, administering, or maintaining third-party backup applications. Historically, native SQL backups have had some drawbacks for a couple of reasons: Native SQL backup facilities do not provide automated media management capabilities and therefore must write to disk devices. While backups performed to disk media eliminated the challenge of manually managing tape cartridges, this method also introduced the need for a considerable amount additional disk. Conventional wisdom has traditionally been that the cost of disk versus removable tape media was significantly higher. Backup to disk did not meet the requirement of retaining an offsite copy of database backups as part of a disaster recovery strategy. Native backup to disk fell short of providing a viable solution for this requirement. Deployed as database backup media, EMC Data Domain deduplication storage systems address the legacy shortcomings of performing native database backups to disk for the following reasons: Data Domain deduplication storage systems optimize storage capacity, making retention and replication of backup data exceptionally cost and network-efficient by providing 10-30x data reduction Data Domain systems are simple to integrate utilizing traditional backup software, but also offer an alternative with high-speed, cost-effective backup directly to a CIFS network share, utilizing native SQL Server backup. Users have the choice to eliminate the need for third-party SQL Server backup application agents and their associated operational costs and maintenance fees. Data Domain Replicator provides up to 99% reduction in bandwidth required, which enables users to send data offsite for faster time-to-dr EMC NetWorker integration with EMC Data Domain Boost (DD Boost) significantly increases performance by distributing parts of the deduplication process to NetWorker storage nodes or applications hosts, and serves as a solid foundation for additional integration between NetWorker and Data Domain systems Data Domain systems benefit from the EMC Data Domain Data Invulnerability Architecture continuous recovery verification, fault detection and self healing, and other resiliency features transparent to the backup application. This white paper provides information about the use of Data Domain deduplication storage as backup media for Microsoft SQL Server backups. Page 5

6 Audience This white paper is intended as a guide for data protection architects, SQL Server database administrative staff, backup administrators and EMC partners seeking information about integrating Data Domain deduplication storage systems as a key component in a comprehensive backup and recovery strategy. Introduction Microsoft SQL Server backup methodology falls into one of two generic categories. The first consists of native SQL Server database backups. This backup technique creates SQL database backups using tools and utilities native to Microsoft SQL Server and does not rely on third-party backup application software (see figure 1). The native database backup tool performs a full database backup to disk through a CIFS network share. The tool is easy to use and provides a feature set that addresses business requirements. Benefits include the use of backup Figure 1: Native MS-SQL Database Backup Tool and recovery interfaces familiar to the database administrative staff. This ability is included with Microsoft SQL Server, and there are no additional third-party software license fees. The second backup methodology uses backup application software that integrates with Microsoft SQL Server to perform SQL database backups based on the Virtual Device Interface (VDI). This solution is typically packaged as a database agent specifically for Microsoft SQL Server and a particular backup application. When VDI is used, the backup application allows setting customized backup and recovery parameters similar to those that can be employed when using native Microsoft SQL tools and utilities. EMC NetWorker backup software has the capability to utilize available snapshot technologies designed to provide application consistency for the backup and recovery processes. The EMC NetWorker Module for Microsoft Applications (NMM) delivers unified, online backup and recovery utilizing Microsoft Virtual Shadow Copy Services (VSS) for Microsoft applications including SQL Server, Exchange, SharePoint, and Hyper-V. Page 6

7 The NetWorker graphical user interface (Figure 2) is an example of a backup application that utilizes Microsoft VSS protection for SQL. Figure 2: NetWorker MS SQL Client Properties VSS Snapshot Configuration When the snapshot type is based on Microsoft VSS, the backup application is the VSS requestor, the SQL Server is the VSS writer, and backup is coordinated with a VSS provider. Advanced backup and recovery features such as disk staging and instant recovery may be available with these implementations depending on the backup application and agent being used. Additional Concepts Sometimes customers utilizing the native Microsoft SQL Server database backup methodology, augment their solution with third-party backup client agents that effectively protect the native backup data as a flat file. This two-phased methodology is effectively backing up a backup. Among the perceived benefits of the augmented solution is that it allows segregation of the SQL database administrative staff from the data protection staff while providing means to retain database backups in conformance with sound business practices and standardized corporate retention policies. There is another variant of the same methodology of an augmented backup solution that utilizes two backup solutions in combination to satisfy business objectives. Native SQL database backups are performed to a Data Domain system and subsequently backup is performed by a third-party backup application and written to the same Data Domain system (Figure 3). Page 7

8 Figure 3: Dual MS SQL Database Backups NetWorker and Native SQL Server Back Up Data Domain Product Background Data Domain deduplication storage systems minimize backup and recovery times, storage and network bandwidth, and risk of data loss. EMC offers a range of Data Domain systems to meet the backup and archive requirements for companies of all sizes as they seek to reduce costs and simplify data management. Data Domain systems also offer replication that is extremely easy to deploy. The primary advantage of Data Domain system replication is that the data is deduplicated and compressed prior to being sent over the network. Advantages of Data Domain in a SQL Server Environment Data Domain systems can be directly integrated into Microsoft SQL Server environments as disk backup media. In addition, Data Domain systems support all leading enterprise backup and archive applications for seamless integration into existing IT infrastructures. The use of different backup methodologies with Microsoft SQL Server and Data Domain systems typically has a negligible effect on overall data deduplication ratios. Page 8

9 This enables users to perform native database backups in conjunction with database backups controlled by a third-party backup application without affecting deduplication efficiency. This includes third-party backup applications that use a SQL agent, with or without VSS snapshots. Additionally, the use of different numbers of stripes or different blocksize values also has a negligible impact on deduplication ratios. Data Domain network-efficient replication can be used to create offsite copies of SQL backups faster and more economically than legacy tape-based strategies. Data Domain replication makes advanced disaster recovery preparedness for SQL Server a reality. EMC Data Domain Boost EMC Data Domain Boost (DD Boost) distributes parts of the deduplication process from the Data Domain system to the backup server or application client. In addition to storage node support, NetWorker 7.6 SP2 or later supports DD Boost-based backup from application hosts for Microsoft applications and databases. This is driving new efficiency for users with NetWorker and Data Domain. By sending only unique data from the NetWorker server or application client to the Data Domain system, less LAN bandwidth is required, backups are 50 percent faster and the whole aggregate system more manageable. NetWorker provides operational capabilities for configuring, monitoring, and reporting of backup and restores for Data Domain devices. This functionality is provided through the NetWorker Management Console (NMC) portal. The NMC portal is accessible from any supported remote Internet browser. The NMC Device Configuration Wizard simplifies the configuration of storage devices, backup clients, storage (target) pools, volume labeling, and save set cloning. DD Boost dramatically increases the aggregate throughput, up to 50% faster than NFS, and reduces the amount of data transferred over the network by 80 to 99 percent. These efficiencies can help eliminate future costs by leveraging existing backup servers and Ethernet networks. Increases backup speed up to 50% faster Reduces network traffic Clone-controlled replication - Schedules replication - Catalog awareness Ease of use - Wizard automated configuration - Monitoring and reporting Figure 4: EMC Data Domain Boost Page 9

10 With DD Boost, backup applications can control replication between multiple Data Domain systems and provide backup administrators with a single point of management for tracking all backups and duplicate copies. This paradigm allows backup administrators to efficiently create DR copies of their backups over the WAN using DD Replicator software and keep catalog consistency for easy disaster recovery. This also provides the flexibility for administrators to manage different retention periods for each copy of data. With NetWorker, the Data Domain replication process is managed by standard NetWorker cloning, ensuring that NetWorker can recognize and manage a replicated (remote) copy of data and assign unique retention policies to it. The administrator has the ability to schedule the cloning process to run at a time that is most appropriate for the business. SQL Server Basics A Microsoft SQL server instance includes system and user databases. As depicted in Figure 5, system databases are created at installation and include: The master database, which records all system-level information for a Microsoft SQL server. It contains records for all login accounts and all system configuration settings. The master database records the existence and location of all other databases. The model database, which is used as a template that contains the default settings for all databases created within the Microsoft SQL Server instance The msdb database, which is used for scheduling, alerts, and jobs The tempdb database, which serves as a global resource that contains all temporary tables and temporary stored procedures. It is Figure 5: Microsoft SQL Server Management Studio Databases re-created every time the Microsoft SQL Server instance is started. Data protection strategies for the system databases are dependent on the database being protected. For instance, transaction log backups are not supported for the master database. The master database cannot be recovered if a functional version of it does not already exist. Recovery procedures for the master database may include re-installing Microsoft SQL Server such that a backup of the pre-disaster master database can then be restored. Page 10

11 The model and msdb databases can contain customized data such as user-specific templates, scheduling information, as well as backup and restore history information. Without a data protection strategy, these items will need to be manually reconstructed in the event of a disaster. The tempdb database is empty when the SQL instance is shut down, and does not require protection as it is re-created at startup. Terminology Entire databases, specific database files, file groups, and transaction log backups are among the supported backup types with Microsoft SQL Server. This section defines the terminology associated with a given backup type. Types of Backups Database backups Database Backup This is a full backup of an entire database and represents the state of the database at the point when the backup is completed Differential Database Backup This is a backup of all the files within a database, and contains only the extents modified since the most recent full backup of each file. Restoring a database protected with full and differential backups to the most recent point in time includes recovering the most recent full and differential backup. Partial backups Partial Backup Partial backups provide flexibility for backing up databases that contain some number of read-only file groups. This is a partial backup of all data in the primary filegroup, each read/write filegroup, and any optionally specified read-only files or filegroups. Differential Partial Backup This backup contains only the extents modified since the prior partial backup of the same set of filegroups File backups File Backup This consists of a full backup of all data in one or more files or filegroups Differential File Backup This is a backup of one or more files containing data extents changed since the prior full backup of each file Transaction log backups Regular transaction log backups are required when using the full or bulk-logged recovery models. This backup contains all log records that have not been backed up previously. Page 11

12 Copy-Only backups Database backups usually change the database in some way, such as truncating a transaction log in the case of a full database backup. Copy-Only backups can be used in cases where a backup of a database is required without changing the database. Recovery Models Microsoft SQL Server includes three recovery models: simple, bulk logged, and full (see Figure 6). The desired recovery model can be deployed based on requirements. Functionally, each recovery model differs with regard to how backup and recovery strategies are executed. The full recovery model includes log backups. This model typically has no exposure to data loss. Point-intime recovery is possible, up to including the last committed transaction. The bulk logged recovery model requires log backups. This model permits highperformance bulk copy operations. Recovery to the end of any backup is possible; point-in-time recovery is not supported. Figure 6: Selection Recovery Model The simple recovery model consists of performing full backups only. Logs are not backed up. In the event database recovery is required, the most recent full backup can be restored. Any changes that occurred subsequent to the last full backup must be redone. From a transactional perspective, the database can only be recovered to the point of the prior full backup. Recovery Techniques The technique used to restore a database will vary based on the recovery model being used as well as the backup types being performed. Figures 7-10 provide a brief look at restoring a database that was protected using the full recovery model with full and transaction log backups. A single full backup was performed, followed by five transaction log backups. Figure 7 depicts the restore database dialog box and general database restore attributes. By default the full backup and subsequent transaction log backups are all selected. Clicking the OK button would initiate recovery to the most recent possible point in time. Alternately, recovery to a specific point in time is also possible. Page 12

13 Figure 7: Restore Database Dialog Box Figure 8 depicts restore database options and available database recovery options. By default an existing database will not be overwritten. Also note that by default the recovery state is RESTORE WITH RECOVERY, which leaves the recovered database in an online and unstable state after the restore process completes. Figure 8: Restore Database Options Page 13

14 Figure 9 is an example of a recovery transaction that restores the initial full backup, followed by the first transaction log backup. The remaining transaction logs were not included in this query for brevity. Figure 9: Restore the Initial Full Backup then the First Transaction Log Backup EMC NetWorker and third party backup applications will each have a unique recovery interface for databases. Many automate and coordinate the recovery of full and transaction log backups similar to the way native Microsoft SQL Server tools and utilities do. Figure 10 is an example of the NetWorker MS SQL client restore GUI Figure 10: NetWorker MS SQL Client Restore GUI Example Data Domain Integration Best Practices Table 1 presents a summary of the suggested best practices settings for Microsoft SQL Server backup to Data Domain deduplication storage systems. Table 1: Recommended Backup Software Settings PARAMETERS AFFECTING DEDUPLICATION PERFORMANCE SQL Server 2008 native compression Third-party backup application SQL Server local compression Third-party backup application multiplexing Third-party backup application encryption Third-party backup application deduplication SETTING NO_COMPRESSION Disabled Disabled Disabled Disabled Page 14

15 Compression Specific to SQL Server 2008 Enterprise and later versions, backup compression can be enabled or disabled. The default product installation does not compress backups. A server-level compression setting can be applied that alters default behavior. The use of the COMPRESSION keyword within a backup SQL transaction explicitly enables backup compression. The use of the NO_COMPRESSION keyword within a backup SQL transaction explicitly disables backup compression. Figure 11 illustrates SQL Server 2008 properties for native compression; the Compress backup Figure 11: Native SQL Backup - Disable Compression service level property is used for backup jobs that do not explicitly enable or disable compression. Backup application software compression should be disabled because the Data Domain system can fingerprint unique data segments more efficiently for deduplication if the data segments sampled are not already compressed. Backup windows can be extended and CPU performance can be impacted on the backup client if the backup software is tasked with performing compression. Local compression is provided for on the Data Domain storage system. Multiplexing When the Data Domain system is integrated as a backup device with a backup application that supports multiplexed backups, EMC recommends disabling multiplexed backups. Multiplexing limits the ability of the Data Domain system to deduplicate incoming data. Historically used as a speed matching solution where multiple slower data streams were multiplexed into a single stream to take advantage of a somewhat faster tape drives, backups to disk drives obtain no advantage from multiplexing. Whether deployed as a CIFS share, NFS mount, VTL, or OpenStorage / DD Boost disk pool, Data Domain systems accommodate writing multiple backup streams in parallel without multiplexing. Encryption Encrypted files are by definition, unique. The encryption software that is part of the backup application will create unique files, on-the-fly for each backup, defeating the deduplication capabilities of the deduplication storage system. Data Domain Encryption software provides encryption of data at rest and is persistent in flight during replication with Data Domain Replicator software. Page 15

16 Backup Application Based Data Deduplication Disabling deduplication from the backup application software will provide better performance and allow the Data Domain system to offload this work. Data Domain systems are optimized to provide the very best ingest performance and deduplication ratios. Table 2: Recommended Backup Software Parameter Settings PARAMETERS AFFECTING BACKUP AND SETTING RECOVERY PERFORMANCE BLOCKSIZE Default 512 byte or higher based on performance improvements Stripes Consider the use of multiple stripes to improve backup and restore data transfer rates Blocksize The, BLOCKSIZE keyword can be used to alter physical block size used when writing to backup media. By default the backup process will automatically select a block size appropriate for the backup device. Supported sizes are 512, 1K, 2K, 4K, 8K, 16K, 32K and 64K bytes. The default value used for disk backup is 512 bytes. The default 512-byte size yields excellent performance with Data Domain systems. Third-party backup applications may substitute their own default value. The fact that this parameter can be adjusted is included as reference. The use of larger sizes may improve or degrade performance. Users are encouraged to investigate further to determine what value may provide optimal results in their environment. Stripes While not a keyword within the context of Microsoft SQL Server, the term stripes correlates to the number of simultaneous backup streams to be created for a given backup operation. In the case of disk backups with SQL Server, multi-streamed backups are performed by specifying a number of backup disk targets with the BACKUP command. Table 3: Mount Options MOUNT OPTIONS When performing native database backups When using a third-party backup server UNC path SETTING Dependent on backup application and server OS type Page 16

17 When the Data Domain system is used as a disk backup media for native Microsoft SQL Server backups, configuration is performed utilizing a CIFS share. As a general rule, the UNC path to the share should be used instead of a mapped drive because: a) Scheduled backups may execute when no user is logged in to the server b) When Sqlservr.exe is executed as a service, it has no relation to a login session Table 4: Miscellaneous Options MISCELLANEOUS OPTIONS Comingling native and third-party backup application database backups to the same Data Domain system Replication CONFIGURATION Yes Yes Comingling native and third-party backups to a Data Domain system should have only a negligible impact on deduplication ratios because of the variable segment processing and Stream Informed Segment Layout (SISL) architected into Data Domain systems. Since Data Domain Replicator software only sends unique, compressed data segments to the remote system it is ideal for network-efficient disaster recovery. Table 5: Infrastructure Configuration INFRASTRUCTURE Server Disk Subsystem IP Network EMC Data Domain System CONFIGURATION Database and log files should be placed on disk storage with performance attributes facilitating required transaction and backup performance metrics Dedicated backup network that meets or exceeds bandwidth requirements for the desired data transfer rate Sized to meet or exceed ingest rate and backup retention capacity requirements Page 17

18 Backup Command The recommended use of SQL stripes is as a speed matching technology. Multiple backup streams from a given database can be simultaneously written to a target Data Domain system in an effort to achieve an aggregate data transfer rate that aligns with business requirements. Figure 12 illustrates a multi-striped database backup that uses eight stripes in an effort to improve backup data transfer rate performance. Multiple stripes can be used to better match data transfer rate capabilities between source and destination media. Figure 12: Multi-striped Database Backup Eight Stripes Data Transfer Rates Multiple business objectives are considered when determining required backup and recovery data transfer rates. Decision criteria include backup window duration, log growth, and recovery time. By definition, slow backups are those that fail to meet or exceed business objectives. Understanding factors that can affect performance is critical to removing them from the environment. Figure 13: Database Backup to a Null Device A reasonable place to start any backup performance investigation is to understand the theoretical maximum speed at which SQL Server can process a given database backup. Performing a database backup to a null disk device provides an estimate of that maximum achievable speed in a given environment. Figure 13 depicts a database backup to a null device. The results of the query indicate that the theoretical maximum rate at which the SQL Server backup function can extract data from this database using a single stripe is approximately 80 MB/sec. Regardless of the data transfer rate at which the backup media can accept data, backing up this database as it currently stands will be limited to 80 MB/sec when using a single stripe. Page 18

19 Figure 14 depicts a database backup to multiple null disk devices. Figure 14: Multiple Null Disk Devices Figure 15 depicts nominal database backup performance improvement with a moderately tuned eight-stripe SQL database backup with an aggregate data transfer rate of approximately 172 MB/sec, indicating that the network-attached backup devices are not limiting throughput. Figure 15: Nominal Database Backup Performance Integration EMC NetWorker and third-party backup applications used to protect Microsoft SQL Server can also take advantage of Data Domain systems employed as backup media. Data Domain systems are easily configured as varied backup media types and protocols including VTL, CIFS share, NFS mount, or Data Domain Boost (DD Boost) for backup applications such as EMC NetWorker. Additionally, DD Boost enables managed replication capabilities known as, clone controlled replication with EMC NetWorker. In this scenario, backup images are replicated from one Data Domain system to another under the direct control of NetWorker or other supported backup applications. DD Boost monitoring, reporting, and cataloging of replicated backup images and savesets can be used to architect a comprehensive disaster recovery plan. Page 19

20 Solution Planning Capacity and performance planning play a critical role in both successful deployment and ongoing production usage of a Data Domain system. Detailed capacity analysis should be performed by a knowledgeable EMC Velocity partner or an EMC technical consultant. The analysis considers database sizes, growth rates, change rates, and retention periods as input criteria. Performance analysis considers data points such as the required aggregate data transfer rate for backups, connection topology requirements to support the data transfer rate, and the Data Domain system required to meet or exceed the required data transfer rate. Beyond capacity and performance planning are additional considerations for Data Domain system replication. Additional Considerations Replication Scope Replicating all database backups is certainly possible. However, many users will want to implement replication at a more granular level. Production database backups are usually excellent replication candidates, whereas development and test database backups are less critical. An analysis of network bandwidth and destination disk space requirements should be performed by a knowledgeable EMC Velocity partner or an EMC technical consultant. Replication Topology Backups are typically replicated to serve as a second backup copy for recovery in the event of a disaster. When backups from a primary site are being replicated to a secondary site, planning is relatively straightforward. Users with multiple primary sites may decide to implement a bidirectional replication solution where database backups from either site are replicated to the alternate site. Proper planning should render an outline detailing which database backups are being replicated to each location. Tape Consolidation Some users replicate backup images to a central location for disaster recovery purposes while also using the solution as a vehicle that enables centralized tape creation. The third-party backup application used to create tape-based backup copies will dictate any additional considerations or restrictions that this solution involves. A knowledgeable EMC Velocity partner or an EMC technical consultant will be able to assist with this planning task. Page 20