Technical white paper

Using HP StoreOnce D2D systems for Microsoft SQL Server backups

Table of contents

Executive summary 2

Introduction 2

Technology overview 2 HP StoreOnce D2D systems key features and benefits 2

HP StoreOnce D2D systems in small to large data centers 3

Why D2D for SQL Server backup? 3 VTL vs. NAS—advantages of each for SQL Server backup 3

HP StoreOnce D2D systems for Microsoft SQL Server backup 4

SQL Server backup structure 4 Capacity planning 5 Capacity planning usage models 5 Microsoft recommendation for SQL Server database performance 6 SQL Server backup threads 7 Single writer thread SQL Server backups 7 Multiple writer thread SQL Server backups 7 SQL Server VSS backups 8 SQL Server native backups 8 Recommendations 9

Conclusion 10

For more information 10

2

Executive summary In today’s business environment, Microsoft® SQL Server customers rely on the most efficient, high-performing, and reliable backup systems. Customers need to protect increasing levels of data, while keeping costs under control. In particular, businesses today are concerned about the costs of backing up and archiving important data from mission-critical software business applications like SQL Server. HP StoreOnce D2D systems provide a disk-based data protection platform that addresses data growth by applying HP StoreOnce deduplication software for efficient, longer term data retention.

This document describes the benefits of using HP StoreOnce D2D systems to backup Microsoft SQL Server databases, and recommends backup and recovery implementations for various Microsoft SQL Server environments. Key recommendations for SQL Server backup:

• Configure SQL Server backups with a single writer thread for quickly rising deduplication ratios that are maintained over time.

• Configure SQL Server backups with multiple writer threads to improve backup throughput performance. Interleaving backup data to the D2D may cause a decline in deduplication ratios.

• For SQL Server Volume Shadow Copy Service (VSS) based backups, use the D2D to get quickly rising deduplication ratios for single and multi volume databases. Backups are single threaded which may cause a decline in backup throughput.

• Configure D2D NAS targets for SQL Server native backups using SQL scripts without a backup application.

• Configure a weekly full and daily incremental backup schedule to reduce the amount of end-to-end data and decrease the time required to run daily backups. Send the backups to a D2D with data deduplication to further reduce the end-to-end data size.

Introduction The HP StoreOnce D2D system is a disk-based backup system that delivers leading price-performance and deduplicates SQL Server database backup data. The D2D can be used to automate and consolidate the backup of multiple databases onto a single, rack-mountable device, while improving reliability by reducing errors caused by media handling.

For business environments with remote offices or a disaster recovery (DR) site, the D2D can be used to replicate data to a central data center or remote facility.

HP StoreOnce D2D systems are ideal for mission-critical application backup data for small to large data centers running key business applications such as SQL Server. Proper configuration of SQL Server database backups with a data protection application to the D2D provides the best backup throughput performance and data deduplication ratios. D2D systems integrate seamlessly into current IT environments and offer the flexibility of both VTL and NAS targets (common internet file system (CIFS) only on legacy systems; CIFS and Network file system (NFS) on current systems) for SQL Server backups.

Technology overview

HP StoreOnce D2D systems key features and benefits • HP StoreOnce deduplication: store more data on disk

HP StoreOnce deduplication reduces the disk space required to store backup data sets without impacting backup performance. Retaining more backup data on disk longer enables greater data accessibility for rapid restore of lost or corrupt files and reduces downtime.

Deduplication ratios are determined by two factors—data change rate and retention periods of the data on the deduplication appliance. Low data change rates and data retained for longer periods of time yield higher deduplication ratios.

• Deduplication-enabled replication HP StoreOnce deduplication is the technology enabler for HP D2D deduplication-enabled replication, which allows fully automated replication over low bandwidth links to a DR site, giving ROBO and small data centers a cost-effective DR solution for the first time.

3

• Rapid restore of data for dependable, worry-free data protection HP StoreOnce D2D systems offer immediate access to backups for rapid restores. StoreOnce deduplication allows more data to be stored closer to the data center for longer periods of time, which offers immediate access for rapid restores.

• Automate, simplify, and improve the backup process HP StoreOnce D2D systems automate your backup processes, allowing you to reduce the time spent managing your data protection. Implementing hands-free, unattended daily backup is especially valuable for environments with limited IT resources, such as remote or branch offices.

D2D systems can backup multiple servers simultaneously to a disk-based solution via a standard Ethernet or Fibre Channel network at peak speeds of up to 2.4 TB per hour, instead of sequentially to a tape drive or autoloader, so you can substantially reduce your backup window.

D2D systems have an intuitive Web-based browser interface, allowing you to monitor locally or remotely, view results, or change settings. This self-managing device reduces routine maintenance. Replication manager provides management of a number of devices replicated to a central site.

D2D systems are self-managing backup appliances that require little, if any, routine maintenance. Unlike other disk-based storage devices, D2D systems do not require virus protection or LUN provisioning.

HP StoreOnce D2D systems in small to large data centers

Why D2D for SQL Server backup? As customers of small to large data centers prepare to upgrade or migrate data protection environments, an opportunity exists to improve functionality, performance, and total cost of ownership (TCO) with HP StoreOnce D2D systems. Customers with SQL Server as a business-critical application may wish to migrate or consolidate disparate small systems into a scalable D2D system.

Migration of SQL Server backup from traditional physical tape devices to the D2D can be seamless because customers may use existing processes and policies on the new platform. Customers with complex backup schedules will find the D2D is a platform that provides an opportunity to migrate to a disk-to-disk backup environment, maintaining existing processes used with physical tape using VTL.

Customers who use NAS file devices on general purpose shares as backup targets may migrate to a D2D to mitigate contention and performance issues found in I/O-intensive backups, business applications, and others that share the same storage array.

VTL vs. NAS—advantages of each for SQL Server backup HP StoreOnce D2D systems may be configured with VTL and NAS targets for backup of SQL Server databases. This section describes VTL and NAS configuration differences and HP recommended uses.

D2D systems are designed as target storage for backup applications that need rapid restores and reduced backup windows. As such, a D2D configured as VTL or NAS uniquely offers:

• Backup to disk, including embedded applications like SQL Server native backup

• Easier setup and maintenance

• Data deduplication, allowing more backup data to be retained on disk for longer periods

• Data replication for cost-effective off-site storage

VTL and NAS configurations benefit from the same deduplication and replication features; however, note the comparisons and recommendations in table 1.

4

Table 1: Comparison of VTL targets and NAS targets

VTL targets NAS targets

Recommended for customers looking to leverage their current investment in tape hardware and software; easing migration using the same backup policies and SQL Server backup scripts

Recommended for customers in non-tape environments who are used to the simpler method of backup and recovery. HP recommends not using as general-purpose NAS share

Appears to the backup application as physically connected tape devices, with backup and recovery jobs managed in the same manner

Seen by the operating system, application, and users as an NFS or CIFS disk share

Acts as a staging post to tape because backups are in tape format; supports tape offload using a backup application copy

Enables use of backup application functionality that is only available with file shares, such as disk-to-disk-to-tape implementations

Requires a backup application that supports backup to tape May be used with backup applications that do not support backup to tape. Ideal for SQL Server native backup

Integrates into the current backup routine and requires no special backup jobs

Requires a new backup job, but is simple to set up

May require purchase of a “tape backup” license for the backup application

Licensing is unique per backup application

HP StoreOnce D2D systems for Microsoft SQL Server backup An important part of SQL Server database administration is maintaining a consistent set of data. When data is lost due to user error, system failure, or site catastrophe, there is a need for data recovery. HP StoreOnce D2D systems, integrated with a well planned data protection strategy that includes regular SQL Server database file and log backups, will maintain a consistent set of data for recovery purposes.

SQL Server backup structure To successfully recover a SQL Server database instance from all types of failure, the following is required:

• The last backup of the SQL Server master and msdb system databases

• The last backup of the SQL Server database instance to be restored

• All logs since the last database instance backup was taken (if running in full recovery mode)—this includes a backup of the active log (tail of the log) if possible

It is common practice to do regular backups of the master and msdb system databases, and local database instances. Database logs are backed up throughout each day as necessary.

HP StoreOnce D2D systems do not deduplicate across VTL or NAS shares. Each VTL and NAS share has a unique hash table used for data deduplication. Table 2 outlines the D2D VTL or NAS shares recommended for SQL Server database backup.

Table 2: D2D VTL or NAS shares recommended for SQL Server database backup

SQL Server backup Recommended D2D backup device configuration

Master and msdb system databases, local database Create a unique D2D VTL or NAS share specifically for the master and msdb system databases and the local database instance to realize the best deduplication ratios.

Database logs Create a unique D2D VTL or NAS share specifically for database logs—the logs represent new or changed data in the database which will not deduplicate as well as database files. The logs are not retained long as they are only required between full backups so not a lot of overall D2D space should be required.

5

Capacity planning The amount of required backup storage for SQL Server database backups depends on the following:

• Size of the SQL Server database

• Size of the database logs (if running in full recovery mode)

• Site backup retention policy

• Type (full, incremental, or differential) and frequency of backups

• Rate of change of the SQL Server database

• The deduplication ratio achieved by the D2D

Note: In this document, the rate of change of the SQL Server database refers to the amount of data that would be contained in a differential backup as a percentage of a full database backup.

A SQL Server administrator may desire to have two weeks’ worth of backups stored on the D2D for quick recovery access. Data deduplication provides more backup space without increasing the physical capacity of the backup device; however, a dynamic SQL Server database with changing data affects the backup data deduplication ratio.

Figure 1 shows the data rate of change effect on deduplication ratios when backing up a SQL Server database to a D2D. In performing these tests, HP used TPC-C benchmark standard data. For the chart below, rows and columns in the database were updated between each backup until the desired rate of change was reached.

Figure 1: SQL Server database rate of change effect on D2D deduplication ratios

Capacity planning usage models A SQL Server 1 TB database with a 14-day backup data retention requirement can have several D2D backup usage models. Usage models change based on variables such as the following:

• Single volume vs. multiple volumes database—multiple volume database backups run multistreamed, which typically have better backup throughput but affects D2D deduplication ratios.

• Database daily rate of change—lower change rates result in better deduplication ratios and require less D2D backup storage.

• Backup schedule type—daily full backups deduplicate well but use more server and D2D compute and bandwidth resources during a backup. Weekly full with daily incremental backups do not deduplicate as well, but use less compute and bandwidth resources. The end-to-end data compaction for weekly full with daily incremental backup schedules is comparable to daily full backups and may be slightly better.

6

• SQL Server backup MAXTRANSFERSIZE parameter specifies the largest unit of transfer in bytes to be used between SQL Server and the D2D. Valid values are multiples of 65536 (64 KB), and range from 65536 (64 KB) to 4194304 (4 MB). Larger MAXTRANSFERSIZE values result in better deduplication ratios for multiple volume databases.

Figure 2 compares five usage models for SQL Server database backups with the following common characteristics:

• Database size: 1 TB

• Backup schedule: daily

• Retention period: 14 days

Each usage model shows the overall size of the database backup data without deduplication verses the size of the data on D2D after deduplication.

Figure 2: Capacity planning usage model storage requirement with and without HP D2D data deduplication

Microsoft recommendation for SQL Server database performance Microsoft Developer Network (MSDN) SQL Server 2008 R2 documentation recommends using files and filegroups to spread the database across multiple disks and disk controllers to improve database performance. For example, a database made up of three data files and one log file will perform better with one file each on four different disk volumes. As data is accessed, four read/write heads can access the data in parallel at the same time, which speeds database operations.

If the database is set up to let files grow automatically, it can cause fragmentation of the files if several share the same disk volume. MSDN SQL Server 2008 R2 documentation recommends creating files or filegroups on as many different local physical disk volumes as possible to minimize fragmentation.

Multiple volume databases have better backup throughput performance than single volume databases, but the interleaved backup data may cause a decrease in D2D data deduplication ratios.

7

SQL Server backup threads SQL Server uses reader and writer threads during a database backup as follows:

• A reader thread is assigned to each disk device containing database files.

• A writer thread is assigned to each backup device.

• A reader thread opens an empty buffer, reads data from a database file, and stores the data in the buffer.

• A writer thread opens a filled buffer, reads the data from the buffer, and writes the data to a backup device.

• Parallel read operations can be increased by spreading the database files among multiple logical drives.

• Parallel write operations can be increased by using more backup devices.

Single writer thread SQL Server backups A backup configured to use a single backup device will use a single writer thread to backup the SQL Server database. This will result in a backup with no interleaved data. If backup throughput performance is not a priority, HP recommends using a single backup device for better data deduplication ratios.

Multiple writer thread SQL Server backups A backup configured to use multiple backup devices will use a writer thread for each backup device to backup the SQL Server database. This will result in a backup with better throughput performance and interleaved data. If backup throughput performance is a priority and a possible decrease in data deduplication ratios is acceptable, HP recommends using multiple backup devices for better throughput performance.

Figure 3 illustrates how D2D backup throughput benefits from multistream SQL Server backups.

Figure 3: SQL Server backup throughput performance over time

When using D2D VTL devices the backup application should be setup to use a separate virtual tape device for each SQL Server reader thread to ensure better throughput performance.

When using a D2D CIFS target the backup application should be setup to use multiple CIFS writers to ensure better throughput performance.

8

For instance, a 4 volume SQL Server database backup will perform better if writing to 4 D2D VTL tape devices or a single D2D CIFS share with 4 disk writers.

Note: SQL Server database backup methods that use multiple writer threads will interleave the data sent to the D2D. Interleaving the data may cause a decrease in D2D data deduplication ratios.

SQL Server VSS backups The D2D is an excellent choice for SQL Server VSS-based backups. When a volume shadow copy of the database is used for backup purposes, the backup will use a single writer thread which results in better data deduplication.

Figure 4 illustrates how D2D deduplication ratios rise quickly and are maintained over time for SQL Server VSS backups with single and multiple volume databases.

Figure 4: SQL Server VSS backup deduplication ratio for single and multiple volume databases

When using VSS with SQL Server backup, database activity is momentarily frozen while snapshots of the SQL Server component files are taken. Component file snapshots are used for database backup.

Note: VSS snapshots require additional storage space on the disk volumes where the database data files reside. SQL Server VSS backups use the snapshot data to ensure a consistent database image.

SQL Server VSS snapshot backup features include support of:

• Full database backup and recovery

• Differential database backup and recovery

SQL Server VSS snapshot backup features do not include support of:

• Log backup (log backup is non-VSS)

• File and filegroup backup (individual file or filegroup backup is non-VSS)

Note: Some backup applications may not support all VSS snapshot backup features.

SQL Server native backups D2D CIFS targets are ideal for SQL Server native backups using SQL scripts without a backup application since the SQL BACKUP command is unable to manage tape media. HP recommends using D2D CIFS targets for SQL Server native backups where media management is not required. HP tests revealed deduplication ratios that are comparable to using a backup application to backup the database.

9

The following SQL script example will perform a multiple thread backup of an eight volume SQL Server database instance named SQLDB8V to a D2D with hostname HPD2D, and CIFS targets named D2D_CIFS_SQL for data files and D2D_CIFS_LOG for logs:

USE master;

GO

-- Create DB logical backup devices

EXEC sp_addumpdevice 'disk', 'D2D_CIFS_SQL_1', '\\HPD2D\D2D_CIFS_SQL\SQLDB_1.bak';

EXEC sp_addumpdevice 'disk', 'D2D_CIFS_SQL_2', '\\HPD2D\D2D_CIFS_SQL\SQLDB_2.bak';

EXEC sp_addumpdevice 'disk', 'D2D_CIFS_SQL_3', '\\HPD2D\D2D_CIFS_SQL\SQLDB_3.bak';

EXEC sp_addumpdevice 'disk', 'D2D_CIFS_SQL_4', '\\HPD2D\D2D_CIFS_SQL\SQLDB_4.bak';

EXEC sp_addumpdevice 'disk', 'D2D_CIFS_SQL_5', '\\HPD2D\D2D_CIFS_SQL\SQLDB_5.bak';

EXEC sp_addumpdevice 'disk', 'D2D_CIFS_SQL_6', '\\HPD2D\D2D_CIFS_SQL\SQLDB_6.bak';

EXEC sp_addumpdevice 'disk', 'D2D_CIFS_SQL_7', '\\HPD2D\D2D_CIFS_SQL\SQLDB_7.bak';

EXEC sp_addumpdevice 'disk', 'D2D_CIFS_SQL_8', '\\HPD2D\D2D_CIFS_SQL\SQLDB_8.bak';

EXEC sp_addumpdevice 'disk', 'D2D_CIFS_LOG', '\\HPD2D\D2D_CIFS_LOG\SQLDB_log.bak';

BACKUP

DATABASE [SQLDB8V]

TO

D2D_CIFS_SQL_1, D2D_CIFS_SQL_2, D2D_CIFS_SQL_3, D2D_CIFS_SQL_4,

D2D_CIFS_SQL_5, D2D_CIFS_SQL_6, D2D_CIFS_SQL_7, D2D_CIFS_SQL_8

WITH

NAME = N'SQLDB8V-Full Database Backup',

BUFFERCOUNT=16, MAXTRANSFERSIZE = 4194304,

STATS = 10

GO

BACKUP

LOG [SQLDB8V]

TO D2D_CIFS_LOG

WITH

NAME = N'SQLDB8V-Log Database Backup',

BUFFERCOUNT=16, MAXTRANSFERSIZE = 4194304,

STATS = 10

GO

Important: For best backup/restore throughput and deduplication results, it is necessary to test with different values for the BLOCKSIZE, BUFFERCOUNT, and MAXTRANSFERSIZE parameters of the SQL BACKUP command. For example, during multiple thread backup testing by HP, a BUFFERCOUNT value of 16 resulted in improved throughput to a D2D CIFS device when compared with the default BUFFERCOUNT setting. The effects of changing parameter values may vary according to the environment.

Important: When using the SQL RESTORE command, it is important to match the BUFFERCOUNT, BLOCKSIZE, and MAXTRANSFERSIZE parameter values with those used during SQL BACKUP. Matching the parameter values should significantly improve restore throughput performance from a D2D CIFS device.

Recommendations • SQL Server daily full backups vs. weekly full with daily incremental backups

– Daily full backups deduplicate at a much higher rate than weekly full with daily incremental backups, but require more server and D2D processing resources and bandwidth.

10

– End-to-end data compaction and D2D data storage required is roughly the same for both types of backup schedules over an extended time period.

– Daily full backups deduplicate better, but weekly full with daily incremental backups send much less data to the D2D for deduplication processing.

– If daily full backups are not required, HP recommends a backup schedule that includes incremental backups to reduce the resource load required for SQL Server database backup.

• SQL Server database full recovery mode vs. simple recovery mode

– Database file full backups to the D2D have a relatively high deduplication ratio when compared to log backups, as logs tend to be more “unique” data types by nature.

– A SQL Server database running in full recovery mode generates logs that can be used with the most recent full backup to recover to the point in time of a database failure.

– A SQL Server database running in simple recovery mode does not generate logs, so the overall D2D data deduplication ratio will be much higher; however, a database recovery will only be to the point in time of the most recent full backup.

– If the SQL Server database is running in full recovery mode, HP recommends sending the database logs to a separate D2D VTL or NAS share.

• Multiple thread SQL Server database backups to the D2D

– The D2D obtains higher overall throughput with multiple threads of data writing simultaneously; however, the data will be interleaved on the D2D which may result in a decline in the deduplication ratio.

– Multiple thread example for a database with 8 files on 8 different disk volumes—SQL Server backup reader threads will read and fill 8 buffers simultaneously for backup. This could be sent to 8 D2D VTL tape devices or a NAS share using 8 disk writers simultaneously. The D2D interleaves the backup data to VTL tape devices or a NAS share.

– For the best deduplication results for multiple writer threads, HP recommends setting the SQL BACKUP MAXTRANSFERSIZE parameter to 4 MB.

– If backup throughput is not the highest priority, HP recommends using VSS to improve backup deduplication ratios, as this method will always use a single writer thread.

Conclusion Microsoft SQL Server customers demand an efficient, reliable data growth management backup system environment, while keeping costs under control. HP provides a variety of reliable data protection storage solutions that address such requirements. HP StoreOnce D2D systems are one such solution. D2D systems offer high performance and reliability, while addressing data growth through HP StoreOnce data deduplication technology for small to large customers. D2D systems integrate easily with leading data protection products to protect important data for mission-critical applications. Combining HP StoreOnce D2D systems with leading data protection products provides a comprehensive data protection solution for SQL Server application data.

For more information HP StoreOnce D2D systems: hp.com/go/d2d hp.com/go/storeonce

HP StoreOnce D2D systems HP D2D4312 user guide: http://bizsupport1.austin.hp.com/bc/docs/support/SupportManual/c02295179/c02295179.pdf

HP StoreOnce D2D systems HP D2D4112 user guide: http://bizsupport1.austin.hp.com/bc/docs/support/SupportManual/c02295179/c02295179.pdf

HP StoreOnce D2D systems Linux and UNIX® configuration guide: http://h20000.www2.hp.com/bc/docs/support/SupportManual/c02299831/c02299831.pdf

HP StoreOnce D2D systems Best Practices Guide: http://bizsupport2.austin.hp.com/bc/docs/support/SupportManual/c02511912/c02511912.pdf

11

Address your requirements for an efficient, reliable, data-growth management backup system on your Microsoft SQL Server, while you keep costs under control, by combining HP StoreOnce D2D systems with leading data protection products. Visit: hp.com/go/d2d.

Get connected hp.com/go/getconnected

Current HP driver, support, and security alerts delivered directly to your desktop

© Copyright 2011, 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.

Microsoft is a U.S. registered trademark of Microsoft Corporation. UNIX is a registered trademark of The Open Group.

4AA3-6870ENW, Created October 2011; Updated July 2012, Rev. 1