SQL Server Backups vs. Replays: A Comparison. Tech Tip

Transcription

1 SQL Server Backups vs. Replays: A Comparison Tech Tip

2 Document revision Date Revision Comments 08/30/2010 A Initial Draft 01/12/2012 B Revision Replay THIS BEST PRACTICES GUIDE IS FOR INFORMATIONAL PURPOSES ONLY, AND MAY CONTAIN TYPOGRAPHICAL ERRORS AND TECHNICAL INACCURACIES. THE CONTENT IS PROVIDED AS IS, WITHOUT EXPRESS OR IMPLIED WARRANTIES OF ANY KIND Dell Inc. All rights reserved. Reproduction of this material in any manner whatsoever without the express written permission of Dell Inc. is strictly forbidden. For more information, contact Dell. Dell, the DELL logo, the DELL badge, and Compellent are trademarks of Dell Inc. Other trademarks and trade names may be used in this document to refer to either the entities claiming the marks and names or their products. Dell Inc. disclaims any proprietary interest in trademarks and trade names other than its own. Page 2

3 Contents Document revision... 2 Contents... 3 General syntax... 4 Conventions... 4 Preface... 5 Audience... 5 Purposes... 5 Customer support... 5 Native MS SQL Server Backups... 6 Dell Compellent Data Instant Replays... 6 Native SQL Server backups v/s Replays... 7 Conclusion and Recommendations... 9 Tables Table 1. Document syntax... 4 Table 2. Comparison of Backup V/S Replays... 9 Page 3

4 General syntax Table 1. Document syntax Item Menu items, dialog box titles, field names, keys Mouse click required User Input User typing required Website addresses addresses Convention Bold Click: Monospace Font Type: Conventions Notes are used to convey special information or instructions. Timesavers are tips specifically designed to save time or reduce the number of steps. Caution indicates the potential for risk including system or data damage. Warning indicates that failure to follow directions could result in bodily harm. Page 4

5 Preface Audience The audience for this document is System Administrators who are responsible for the setup and maintenance of SQL servers and associated storage. Readers should have a working knowledge of Windows, SQL Server, Dell Compellent Replay Manager and Dell Compellent Storage Center. Purposes This document provides an overview of Dell Compellent Data Instant Replays and how it can be used in conjunction with Native SQL Server Backups to provide an extremely fast and space efficient point in time recovery for very large SQL Server Databases. It also provides a comparison chart of Native SQL Server backups vs. Dell Compellent Replays. Customer support Dell Compellent provides live support EZSTORE ( ), 24 hours a day, 7 days a week, and 365 days a year. For additional support, Dell Compellent at support@compellent.com. Dell Compellent responds to s during normal business hours. Page 5

6 Native MS SQL Server Backups SQL Server offers 3 main types of backups: Full database backups: A full backup contains all the data in a specific database or set of filegroups or files, and also enough logs to allow for recovering that data. For large databases, this is a resource intensive operation requiring a significant amount of time, disk space and I/O bandwidth, even when using compression. On their own, full database backups provide single point in time recovery. When combined with transaction log backups, a database can be recovered to any point in time. Differential database backups: A differential backup is based on the latest full backup of the data. This is known as the base of the differential, or the differential base. A differential base is a full backup of read/write data. Differential database backup will copy all data pages that have changed since the last full backup to an external file on the file system. Transaction log backups: A transaction log backup will take every page written to the transaction log since the last transaction log backup and copy it to an external file on the file system. A transaction log backup cannot be taken if the database is in simple recovery mode, or if a full database backup has not been completed. Transaction log backups allow a database to be recovered to any point in time. This provides the capability to restore a database to a point in time prior to a failure with minimal data loss. If the database is damaged, but the transaction log is intact, you can still run a final backup of the transaction log. This will allow a full recovery with no data loss. Transaction log backups are also a key component of log shipping. There are additional backup types (partial database, differential partial database and file) designed to work with very large databases (VLDB). A typical SQL Server backup strategy would consist of a full database backup in combination with differential database backups and/or transaction log backups. Strategies using these backup types are complex and are not discussed further in this document. Additional information about these backup types can be found in SQL Server Books Online. All backup types use the same general approach. They read pages out of the database or transaction log, and write them to an external file on the file system. This generates additional I/O and requires additional disk space. For large databases, this additional I/O load can be significant. Dell Compellent Data Instant Replays Taking a Replay generates very little overhead. This makes database backups very fast, even for large databases. Replays are also space efficient, since each Replay contains only the blocks that have changed since the last Replay. When using Replays to backup a database, a snapshot is taken of each volume that contains database files while I/O within SQL Server is frozen. This preserves the state of each database file at the point in time the Replay is created. It is strongly recommended to use Replay Manager when taking Replays of SQL Server database volumes. This method guarantees application consistent snapshots of the database and transaction logs while the database is still online. Page 6

7 Replay Manager makes it easy to setup and schedule Replays of all of your database volumes. Replay Manager provides the ability to schedule Replays as often as every 15 minutes. In order to understand more on how Storage Center Replays store data, please refer to the document How the Storage Center Replays Store Data : ( Replays can be set up using either of the following 2 applications: a. Replay Manager for SQL Server: Replay manager is used to take application consistent replays of all the databases on a SQL Server. This is the recommended way of taking database volume replays as it guarantees consistency of the database. In order to learn how to use Replay manager to take SQL Database replays, please refer to the Replay Manager User guide : ( b. Storage Center: Storage Center can also be used to take replays, however it is strongly recommended to use Replay Manager to take replays of the SQL Server databases. If it is decided to use Storage Center to take a replay, it is highly recommended to group all the SQL volumes (Data and Logs) into a consistency groups and take a replay. In order to learn how to use Storage Center to take replays and create consistency groups, please refer to the Storage Center User guide ( Remember that Replays initiated from Storage Center or within a consistency group without the use of Replay Manager produce a crash-consistent replay which may or may not be recoverable by the application in every case. Native SQL Server backups v/s Replays FACTOR Replay Manager Replays Native Backups Backup Speed Space Utilization I/O Operations Backups using Dell Compellent Replay Manager are done within seconds (depending on the number of databases in the backup set). Replays are independent of the Database/Volume size. Replays contain only the blocks of data that have changed since the last replay. When a Replay takes place, the blocks associated have their metadata updated. Since Replays do not actually create a copy of the data, they are extremely space efficient and smart. Initiating Replays is not an I/O intensive operation as it does not The time Native Backups take to backup a database depends on size of the database being backed up. The bigger the database, the more time to back it up. In some cases, a backup could even take hours depending on the server speed and I/O capabilities of the system. Native backups create a copy of actual database. Hence they consume a lot more space as compared to replays, especially for very large databases (VLDB). With recent versions, the backup size can be reduced by compressing the database backups. However the compressed backups can still be pretty large compared to replays. Native backup is an extremely I/O intensive operation as it involves Page 7

8 Recovery Speed Recoverability in multiple environments Data Progression Backup Automation Disadvantages / Challenges involve creating a huge backup file or writing a lot of data. Hence the I/O operations are restricted to minimal. Recovering from a Replay is a very easy and an extremely fast operation. An extremely large database (> 1 TB) can easily be recovered within minutes. This is a great feature especially for highly available databases that have a short RTO (Recovery Time Objective) and cannot tolerate high down-time. A single Replay can be used to recover a database in multiple environments. A copy of the VLDB can easily be created in non-production environments within minutes using Replay Manager. Replays help in Data Progression within Dell Compellent Storage Center. Relative access of blocks within the volume help to determine what data moves to a lower tier (lower performing/higher density) ensuring that regularly accessed data is always available on the fastest disk. Taking a replay/recovering can easily be automated using a PowerShell Script. Dell Compellent Replay Manager provides an extremely useful Powershell command set that can be used to script most activities that can be done using the interface. 1. Challenge: Replays are dependent on the availability of SAN. In a case where the data center becomes unavailable, the replays (and data volumes) could also be unavailable. Solution: In order to ensure the backup availability in such a situation, leveraging Storage Center Remote Instant Replay (storage replication) can be used as a recovery mechanism in the event of a disaster. Remote Instantly Replay replications volumes and their associated replays to another Storage Center and a disaster creating a copy of all the data and writing a lot of data to disk. Recovering from a Native backup can be an extremely long operation since it depends on a lot of factors such as database size, backup size, and I/O capabilities of the system. A VLDB database (>1 TB) can sometimes take hours to restore and recover. A single Native backup can also be used to create copies in multiple environments. However as mentioned above, it can take a large amount of time for recovery. Native Backups do not have any impact on the Data Progression within Dell Compellent SAN. Native Backups can easily be automated by using T-SQL or Powershell scripts. 1. Challenge: Native backups can potentially take large amount of time depending on size of the databases being backed up. Solution: This problem can be partially reduced by compressing backup either using Native tools or third party backup tools. 2. Challenge: The time it takes to recover from a Native backup can be extremely high depending on various factors especially the database size. Solution: This problem can be partially Page 8

9 recovery plan can be configured in Enterprise Manager. 2. Challenge: Replay Manager cannot take Replays more often than 15 minutes. Solution: This above issue can be resolved by combining Transaction Log backups with Replays as a part of backup strategy. This will ensure a granular availability for systems that need it. reduced by use of third party backup tools that can improve recoverability time. However it can still take a long time to recovery if the database is bigger in size. Besides the above 2 major challenges, there are other challenges in using Native backups as mentioned in the comparison above. 3. Challenge: An exact Point-In-Time recovery is not possible using Replays. Solution: Replays provide a way to restore the database in a NORECOVERY mode, which allows further applying transaction log backups. In order to achieve an exact Point-In-Time recovery, Replays should be used in conjunction with Native Transaction Log backups. Including Transaction Log backups in addition to Replays as a part of backup strategy is a good idea. One thing to note is Recovering a database from a Replay in a NORECOVERY mode would force the use of Restore method in Replay Manager. This method greatly increases the recovery time from a replay and is dependent on size of the database. Table 2. Comparison of Backup V/S Replays Conclusion and Recommendations Replays provide a method for backup and recovery that cannot be matched by native SQL Server backups for speed and space efficiency. Since Replays also help Data Progression work better, all environments can greatly benefit from using Replays. If the recovery point objective (RPO) of the application demands an exact point-in-time recovery, it is recommended to use a combination of Dell Compellent Replays in conjunction with Native SQL Server Transaction Log backups to comply with recovery requirements. Page 9