Avoiding Five Painful Backup
and Recovery Mistakes with
LiteSpeed for SQL Server
Introduction
Recent research by TechValid...
2
Point Objectives (RPOs) and Recovery
Time Objectives (RTOs).
This white paper examines five of the
most painful SQL Serv...
3
To help DBAs achieve an optimal
balance between database performance
and backup compression, and
better understand the d...
4
to replication and retention procedures
may be needed to prevent such a mistake
from breaking a backup set, as well as
t...
5
separate logical unit number (LUN) on a
different array within the SAN.
Selecting a less aggressive compression
level ca...
6
Ensure your backups
can be restored and
check for database
consistency errors
with LiteSpeed’s
Automated Restore
feature...
7
LiteSpeed
simplifies SQL
Server protection,
delivers significant
cost savings, and
provides DBAs
additional recovery
cap...
8
Whitepaper-LiteSpeed4SQLserver-Mistakes-D-US-KS-2013-08-19
© 2013 Dell, Inc. ALL RIGHTS RESERVED. This document
contains...
Upcoming SlideShare
Loading in …5
×

Avoiding 5 Painful Backup and Recovery Mistakes with Litespeed for SQL Server

2,401 views

Published on

Ensuring top notch SQL Server backup and recovery is easily attainable when you know which common mistakes to avoid. Discover what these common mistakes are in our webcast: http://bit.ly/1bc223F

We’ll be presenting invaluable ideas culled from thousands of discussions with SQL Server administrators about their backup and recovery strategies. Join us and discover how you can avoid these common slip-ups that can make database recovery nearly impossible, and waste significant time, money, and effort, including:

•Generating excessive storage costs
•Running full and/or uncompressed backups that exceed maintenance windows
•Using flawed backup procedures that break SQL Server recovery
•Failing to optimize the actual recovery environment, prolonging restore times
•Neglecting to test key business applications after performing a restore

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,401
On SlideShare
0
From Embeds
0
Number of Embeds
18
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Avoiding 5 Painful Backup and Recovery Mistakes with Litespeed for SQL Server

  1. 1. Avoiding Five Painful Backup and Recovery Mistakes with LiteSpeed for SQL Server Introduction Recent research by TechValidate revealed that 74 percent of database administrators (DBAs) believe SQL Server® backups take too long, and that 55 percent believe backup storage costs are excessive. These are significant concerns given that over half of the respondents (59 percent) operate at least 10 mission-critical SQL Server applications, and about one-fourth (27 percent) operate more than 50 mission-critical SQL Server applications. In order to address these concerns, some DBAs take actions that — despite their good intentions — end up compromising the integrity of backup and recovery efforts. These include waiting longer between backups, using differential backups without always completely protecting the full backup and shortening retention periods by intentionally or inadvertently deleting critical backups too soon. Most DBAs struggle constantly to achieve the optimal tradeoff between backup speed and the storage space savings that result from deduplication and compression. Unfortunately, in performing many of these tasks, and despite best efforts, mistakes can happen. Ensuring an efficient and reliable restore process is only one-half of the recovery story. The other half is protection against SQL mistakes to the underlying data. An incorrect SQL statement (one run accidentally in production instead of development) or malicious code designed to change or delete data can easily take production applications offline. So how can DBAs protect themselves from these types of mistakes? The DBAs in TechValidate’s survey reported that using LiteSpeed™ for SQL Server improved their backup and recovery processes substantially. Eighty percent of respondents achieved significantly faster backup and recovery times, and 75 percent made significant reductions in backup storage space requirements. The DBAs reported additional benefits as well, especially the ability to restore individual objects and roll back transactions, thereby making it easier to satisfy both Recovery
  2. 2. 2 Point Objectives (RPOs) and Recovery Time Objectives (RTOs). This white paper examines five of the most painful SQL Server backup and recovery mistakes. Each section assesses the likely cause and potential effects of the mistake, and describes ways of avoiding it — both in general and by using LiteSpeed for SQL Server. #1 Raw data exceeds available storage space The size of SQL Server databases is exploding in a pattern that is reminiscent of Moore’s Law: a doubling of speed (or in this case, data) roughly every two years. And the amount of disk space required for backing up this data might be four times as much as the size of the database itself. The reason for the additional storage space requirement is the minimum 1:4 ratio between the size of a database and its backup files. There is the initial and full backup, of course, which is the same size as the database (without compression), plus the additional daily full, differential and transaction log backups, along with at least one (and maybe more) copies of these backups replicated off-site to satisfy disaster recovery needs — all of which must be retained on disk for a few weeks to simplify recovery by avoiding the need to restore from tape. So every additional gigabyte of database data might require another 4GB of backup storage. Because running out of backup storage can result in some serious problems, this mistake is the first of the five covered here. There are several options DBAs have to avoid running out of backup storage. The first is to include storage space in all capacity planning and server provisioning efforts. For every new database or server provisioned, or for every additional GB of database storage added, be sure to add an appropriate amount of backup storage space. Another option is to migrate backup files on direct-attached storage (DAS) to either network-attached storage (NAS) or a storage area network (SAN), or to a purpose-built backup appliance. Pooled storage is easier to scale and reclaim, and NAS/SAN environments also typically offer more robust data protection — all of which make it ideally suited for backups. There are also two options for reducing the amount of (expensive) storage space needed. The first of these data reduction options is data deduplication. Very little of the data in a typical database changes from day to day, which means every full backup contains a substantial amount of data that has already been safely backed up. Data deduplication is a proven technique for eliminating this redundant data, resulting in considerable space savings. The second data reduction option is to compress data whenever possible. Most data compresses quite well, resulting in a substantial reduction in backup storage space. SQL Server’s built-in compression algorithm, for example, is able to reduce the backup size of a “typical” database by up to a factor of four. LiteSpeed for SQL Server offers eight levels of compression that are capable of outperforming SQL Server’s built- in compression algorithm. In TPC-E benchmark testing of a 300GB database, backup sizes were reduced down to 19GB (nearly 16:1 compression). LiteSpeed’s compression can be run in adaptive mode, enabling it to change dynamically as needed to make the appropriate balance between performance and size. Backups fully leverage available CPU to maximize compression and maintain maximum backup speed, while yielding CPU to SQL Server when needed to maintain performance levels (see Mistake #3). Reduce backup storage using LiteSpeed’s advanced data compression technology. Share:
  3. 3. 3 To help DBAs achieve an optimal balance between database performance and backup compression, and better understand the disk and CPU limits on the server, LiteSpeed has a Backup Analyzer that assesses I/O and the performance of the available compression levels. Figure 1 shows the results of one such analysis. Note the inverse relationship between the backup speed and size in the Estimated Duration and Estimated Backup Size columns. Note also that the compression process becomes CPU-bound around compression level 7, as revealed by the Throughput column. One final option for reducing backup storage space is the use of differential backups, which can be thought of as a form of built-in SQL Server deduplication. Although the space savings can be considerable over nightly, full backups, mistakes may occur that result in compromised recovery capabilities. Avoiding these mistakes is, therefore, the next subject. #2 Improper use and management of differential backups Differential backups help achieve two worthy objectives: completing backups faster and consuming less storage space. But unlike full backups, which can be restored without the need for any other backup file, every differential backup file has a dependency on its related full backup, and this additional complexity in backup file management is a common cause of mistakes. Differential backups only back up the data that has changed since the last full backup. This approach enables a full restore from two files: the most recent differential and its related full backup files. Transaction log backups would then be applied as needed. But what happens if the “most recent” full backup file is missing or corrupt, and all that exists is the full backup from last week? All of the differential backups that rely on a full backup that is no longer available are totally useless. The worst part is that SQL Server will continue to run differential backups as it is completely unaware there is a problem. To avoid such a catastrophic mistake, the use of differential backups requires more rigorous backup file management and retention procedures. The procedures must recognize the file dependencies involved, and anticipate how any current file management practices (especially routine deletions) might cause problems. For example, there should be some means of detecting the deletion or corruption of a current full backup in order to avoid having to make another full backup immediately. Enhancements Figure 1 – LiteSpeed’s Backup Analyzer assesses the effect of different compression levels on both storage space and performance. Eliminate differential backup mishaps with LiteSpeed’s patented Fast Compression. Share:
  4. 4. 4 to replication and retention procedures may be needed to prevent such a mistake from breaking a backup set, as well as to recover quickly from such an event if it occurs. Retention procedures should also be enhanced to ensure that no full backup is ever removed accidentally from a disk whenever there exists any differential backup that requires it. Another issue involves index maintenance, bulk data loads and/or other processes that cause significant changes to be made to a database. These changes are often substantial enough to make the differential backup comparable in size to a full backup. For this reason, the best practice is to “reset the cycle” by creating a new full backup in order to avoid longer restore times and risk to RTOs. An alternative best practice is to schedule any massive data changes or database maintenance tasks to occur just before the next scheduled full backup. In anticipation of the robust file management practices required, LiteSpeed offers Fast Compression, which is designed specifically to improve the differential backup process. When combined with LiteSpeed’s data compression, differential backups greatly reduce the amount of storage space required and also handle the management of backup file sets. For example, LiteSpeed checks for the existence of a full backup before permitting a differential. It also validates backup log sequence numbers (LSNs) to ensure the backups are related, and even checks the extent of data change in the database before the backup runs in order to minimize differential backup size. In these and other cases, if performing a differential backup could cause harm to restores or RTOs, Fast Compression runs a full backup to start a new backup set. Fast Compression even handles the inevitable need to delete backup files with its SmartCleanup process. As the name implies, SmartCleanup is intelligent about file retention and understands the relationship between full and differential backups to ensure recoverability. Additional TPC-E benchmark testing on the same 300GB database cited in the previous section revealed the benefit of using LiteSpeed for differential backups. SQL Server’s native backup system required a total of some 605GB to store 14 days of full backups, while LiteSpeed with Fast Compression required as little as 104GB for 14 days. #3 Backups impacting database applications The TechValidate survey revealed that nearly 75 percent of DBAs believe SQL Server backups take too long. There is an inherent tradeoff between backup performance and database application performance, and certain mistakes made with the former can adversely impact the latter. The reason for the backup-database performance relationship is the significant amount of disk I/O needed by the backup process and, additionally, the CPU resources needed to perform data compression. For these reasons, backups performed during the day often create contention with production applications. The situation is a bit more complicated, however, because backups performed at night often conflict with database maintenance or ETL jobs, and some databases operate 24x7, leaving no time for an aggressively compressed backup. A strict Recovery Point Objective (RPO) might also make it necessary to back up transaction logs fairly regularly throughout the day. There are, fortunately, ways to minimize or mitigate the effects of this relationship between database and backup performance. An obvious one is to use differential backups to minimize the amount of data that requires backing up. Another is to spread out I/O by backing up to different physical disks from where the data resides or, if using a SAN, to a Automatically leverage available server resources for the fastest backups with LiteSpeed’s Adaptive Compression. Share:
  5. 5. 5 separate logical unit number (LUN) on a different array within the SAN. Selecting a less aggressive compression level can also improve overall performance in situations where the server is CPU-bound. The LiteSpeed Backup Analyzer shown in Figure 1 can help eliminate tradeoffs between performance and storage space savings. LiteSpeed addresses this issue for many different databases by offering granular controls over server resources to limit the impact of compression. Every second, Adaptive Compression adjusts the compression level as needed based on available CPU. Some of the more advanced capabilities that help to minimize or eliminate the adverse impact of compression on database performance include a CPU throttle to limit maximum CPU usage, specifying the number of Backup Compression Threads to limit the number of CPU Cores leveraged for backup and compression and utilizing a Processor Affinity Mask to assign the backup to a specific set of CPU Cores. One additional option is to use SQL Server 2012 Always On Availability Groups. AOAGs allow DBAs to use a secondary replica for backup. LiteSpeed fully supports AOAGs, making scheduling these types of jobs a simple matter for the DBA. #4 Too many backup jobs and maintenance plans The three potential mistakes discussed so far apply to the backup and recovery of a single database. But, as noted previously, most organizations have many databases, all of which require backup via a wide variety of backup jobs and maintenance plans. Such diversity, with different combinations and permutations of backup and recovery procedures, becomes fertile ground for mistakes. Historically, backups have been scheduled and managed one server or one database at a time. But most instances have many databases, and every database might require multiple jobs for full, differential and transaction log backups. Multiply that by the total number of instances and the result can be a lot of databases and a lot of jobs to manage. Making changes to a backup job also requires updating each job or maintenance plan — a time-consuming process that is prone to mistakes given the complexity of the task. In addition, because backup statistics are stored locally in the MSDB database, how can a DBA assess backup job performance and integrity across all instances? How can a DBA detect a failed job or poor compression in a simplified way? The standard management tools available with SQL Server offer very little real assistance in environments with a wide variety of backup jobs and maintenance plans. At a minimum, the DBA team should thoroughly document all maintenance plans, job codes and any centralized backup processes that are shared among servers. The DBAs should also create as much standardization as possible among the backup scripts, and create a process to collect and aggregate the data from each server’s MSDB. These steps help simplify and centralize the management of backup jobs and maintenance plans, but DBAs can accomplish much more with the Backup Templates in LiteSpeed. The templates enable DBAs to create common backup procedures and deploy them easily to multiple instances in a single pass. Templates can also be updated and then easily redeployed to the associated instances. Backup Templates support both SQL Server agent jobs and maintenance plans. SQL Server backup changes can now be easily pushed out to thousands of databases in seconds instead of days or weeks. LiteSpeed includes a central repository that consolidates reporting of backup statistics in a single database, including Simplify job creation and scheduling with LiteSpeed’s Backup Templates. Share:
  6. 6. 6 Ensure your backups can be restored and check for database consistency errors with LiteSpeed’s Automated Restore feature. native backups. As shown in Figure 2, such consolidation makes it much easier (and quicker) to find and fix common failures. #5 Not testing all restore scenarios There is perhaps no worse feeling for a DBA than when a database cannot be recovered. Something goes terribly wrong with the production database; it needs to be restored; and the backup files are missing or corrupt. Everything is lost, possibly even the DBA’s job. The unfortunate reality of backup and recovery is that any procedural problem often goes undetected until a production problem occurs. And by then it is too late. An enterprise-class recovery plan begins by considering every restore scenario that might be needed. Database restores are required in many situations, including physical corruption, hardware problems/failure, logical corruption (improper insert/update/delete), user error or malicious attack. The goal with the plan should be to ensure the most foolproof and fastest recovery for all possible restore scenarios. Another reality of backup and recovery is that an average but adequate plan, flawlessly documented, tested and executed, will likely produce better results than an untested “perfect” plan. Best practices mandate proper documentation and testing of all recovery plan procedures for each and every restore scenario. Testing is simply the best way to discover (and correct) procedural problems in advance of actually needing to restore production data. So every step of every restore scenario should be documented and tested, and refined until perfected. And tested not just once under ideal conditions, but tested under a wide variety of possible variables and complications, including a 3:00 a.m. disaster when no DBAs are onsite. These tests are also a good way to determine Figure 2 – LiteSpeed makes it easy to get information on what is working well, and troubleshoot problems. Share:
  7. 7. 7 LiteSpeed simplifies SQL Server protection, delivers significant cost savings, and provides DBAs additional recovery capabilities not found in native tools. the amount of work/time required for each restore scenario, and how the effort changes under different conditions. LiteSpeed can help in plan formulation and testing by simplifying and even automating many of the procedures needed under various restore scenarios, as well as by offering more granular control to complement the basic full/ differential/log restore process. For example, it might be adequate to restore only a single object, such as a table or index, or only a portion of a schema as an alternative to a full restore of the entire database. Such options would not be possible without LiteSpeed’s Object-Level Recovery, which queries backup files to recover data or a schema without the need to perform a full restore of a database. One of the more powerful capabilities of LiteSpeed is its ability to “undo” transactional mistakes. LiteSpeed’s Transaction Log Reader allows DBAs to review, rollback or undo/redo transactions. Finally, LiteSpeed can help DBAs by testing restores. Knowing every database can be restored provides a real sense of security for any DBA. And in release 7.5 (August 2013), LiteSpeed has the ability to run database consistency checks (DBCC CHECKDB) on restored databases to detect any data corruption. Mistakes happen despite the best efforts to prevent them. And when they do, LiteSpeed can turn the most common ones from an “Oh No!” to a mere “Oops.” What DBA would pass on the chance to be able to do that? Conclusion Backing up a growing volume of data to meet increasingly stringent Recovery Point Objectives and Recovery Time Objectives is becoming a real problem for most DBAs. And there seems to be no easy solution. Adding more disk drives increases available storage space, but this is expensive and does little to address shrinking backup windows. Deduplication, compression and differential backups help, but are accompanied by their own set of risks. Now multiply these and some other challenges that exist for every single database by the large and growing number of databases in the typical organization, and backing up data starts to seem like a “Mission Impossible” assignment. Doing it successfully requires detailed planning and rigorous testing. And mistakes anywhere can result in the loss of mission-critical data — and even a DBA’s job. LiteSpeed for SQL Server from Dell can help. LiteSpeed minimizes the chances of making mistakes, and provides the means to mitigate and even correct the most common mistakes when they do (inevitably!) occur. To learn more about how your organization can benefit from using LiteSpeed for SQL Server, please visit Dell on the Web at software.dell. com/products/litespeed-for-sql-server/. Share:
  8. 8. 8 Whitepaper-LiteSpeed4SQLserver-Mistakes-D-US-KS-2013-08-19 © 2013 Dell, Inc. ALL RIGHTS RESERVED. This document contains proprietary information protected by copyright. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording for any purpose without the written permission of Dell, Inc. (“Dell”). Dell, Dell Software, the Dell Software logo and products—as identified in this document—are registered trademarks of Dell, Inc. in the U.S.A. and/or other countries. All other trademarks and registered trademarks are property of their respective owners. The information in this document is provided in connection with Dell products. No license, express or implied, by estoppel or otherwise, to any intellectual property right is granted by this document or in connection with the sale of Dell products. EXCEPT AS SET FORTH IN DELL’S TERMS AND CONDITIONS AS SPECIFIED IN THE LICENSE AGREEMENT FOR THIS PRODUCT, DELL ASSUMES NO LIABILITY WHATSOEVER AND DISCLAIMS ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. IN NO EVENT SHALL DELL BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE, SPECIAL OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS INTERRUPTION OR LOSS OF INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF DELL HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Dell makes no representations or warranties with respect to the accuracy or completeness of the contents of this document and reserves the right to make changes to specifications and product descriptions at any time without notice. Dell does not make any commitment to update the information contained in this document. About Dell Software Dell Software helps customers unlock greater potential through the power of technology—delivering scalable, affordable and simple-to-use solutions that simplify IT and mitigate risk. The Dell Software portfolio addresses five key areas of customer needs: data center and cloud management, information management, mobile workforce management, security and data protection. This software, when combined with Dell hardware and services, drives unmatched efficiency and productivity to accelerate business results. www.dellsoftware.com. If you have any questions regarding your potential use of this material, contact: Dell Software 5 Polaris Way Aliso Viejo, CA 92656 www.dellsoftware.com Refer to our Web site for regional and international office information. For More Information Share:

×