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

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
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
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
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
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
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
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
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: