Backup of Microsoft SQL Server in EMC Symmetrix Environments ...

Backup of Microsoft SQL Server in
EMC Symmetrix Environments with
EMC NetWorker PowerSnap
Applied Technology

Abstract
This white paper covers how EMC® NetWorker and NetWorker modules can be used effectively in EMC
Symmetrix® environments to complement and enhance backup and recovery capabilities for Microsoft SQL
Server databases using the snapshot technologies of EMC storage arrays and backup/recover capabilities of
NetWorker.
August 2008

Copyright © 2008 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
All other trademarks used herein are the property of their respective owners.
Part Number H5552

Backup of Microsoft SQL Server in EMC Symmetrix Environments with EMC NetWorker PowerSnap
Applied Technology 2

Table of Contents

Executive summary ............................................................................................ 5
Introduction ......................................................................................................... 5
Audience ...................................................................................................................................... 5
Terminology ................................................................................................................................. 5
Snapshot technologies in backups................................................................... 6
Snapshot backups ....................................................................................................................... 7
Instant backup ...................................................................................................................................... 7
Nonpersistent backup ......................................................................................................................... 8
Serverless backups ............................................................................................................................. 8
File-logical image backup (FLIB) ....................................................................................................... 8
Snapshot recoveries .................................................................................................................... 8
Instant restore ...................................................................................................................................... 8
Rollback................................................................................................................................................. 9
File-logical image recovery (FLIR) .................................................................................................... 9
SC Restore (SymmConnect Restore, FLIR that uses a mirror).................................................... 9
Conventional/tape restore .................................................................................................................. 9
EMC Symmetrix storage arrays ......................................................................... 9
TimeFinder/Mirror ........................................................................................................................ 9
TimeFinder/Snap ....................................................................................................................... 10
EMC NetWorker................................................................................................. 11
EMC NetWorker PowerSnap ............................................................................ 11
EMC NetWorker Module for Microsoft SQL Server ........................................ 12
NetWorker Module for SQL Server and PowerSnap ...................................... 12
Backup workflows ...................................................................................................................... 13
Homogenous workflow...................................................................................................................... 13
Snapshot management..................................................................................................................... 13
Heterogeneous workflow .................................................................................................................. 13
PowerSnap snapshot backup of NMSQL........................................................ 13
Configuring a NMSQL database ................................................................................................ 14
Configuring the Symmetrix Groups and Resource file ................................. 14
Configuring a NetWorker client for backups in a homogenous workflow... 17
Traditional backup workflow....................................................................................................... 17
NMSQL recoveries supported in homogenous workflow........................................................... 19
Normal ................................................................................................................................................. 20
Copy..................................................................................................................................................... 20
Verify only ........................................................................................................................................... 20
Piecemeal restore.............................................................................................................................. 20
PowerSnap recoveries supported in homogenous workflow..................................................... 23
Instant restore .................................................................................................................................... 23
Conventional/tape restore ................................................................................................................ 24
Rollback restore ................................................................................................................................. 25
PowerSnap safety check.................................................................................. 25
Configuring a NetWorker client for backups in a heterogeneous workflow 27
SymmConnect workflow backup................................................................................................ 27


Recoveries supported in a heterogeneous workflow ................................................................. 28
FLIR ..................................................................................................................................................... 28
FLIR using a mirror (SymmConnect restore)................................................................................. 28
Conventional/tape restore ................................................................................................................ 29
Selection of a remote storage node ................................................................ 29
Troubleshooting tips ........................................................................................ 31
Conclusion ........................................................................................................ 32
References ........................................................................................................ 32


Executive summary
Microsoft SQL Server database is a leading database management system on Microsoft Windows
operating systems, and is a critical component in many organizations. IT managers regard data corruption,
which is a source of many database server failures, as the most immediate threat to their SQL Server
database environment. Most of the challenges that a backup administrator faces are how to offload the
application server during backups and how to shorten backup windows.
This white paper covers how EMC® NetWorker® and NetWorker modules can be used effectively for
backups and recovery of a SQL Server database using the snapshot technologies of EMC Symmetrix®
arrays.

Introduction
The EMC NetWorker family of products helps to protect data by simplifying and centralizing backup and
recovery operations. With its record-breaking performance, NetWorker is the ideal backup software for
small offices as well as large data centers. With support for leading applications, such as Oracle, Microsoft
SQL Server, and SAP, and advanced backup and recovery technologies such as snapshot management and
data de-duplication, NetWorker customers can realize the highest levels of flexibility, management, and
cost control over their data protection operations, while protecting their overall investments in these
technologies.

The EMC Symmetrix family of products provides industry-proven storage arrays and maintains a high
degree of robustness and availability. EMC Symmetrix can centralize and simplify data protection
management with local continuous data protection or remote replication, protecting an organization from
data loss due to server failures, data corruption, software errors, viruses, end-user errors, and catastrophic
events.

Integration of EMC Symmetrix storage arrays’ snapshot technologies with EMC NetWorker provides use
of these proven snapshot technologies through the NetWorker Management Console interface and creates
point-in-time snapshots for rapid recoveries and long-term backup to disk or tape. Centralized management
from NetWorker allows customers to schedule snapshots, set policies, and browse the index of these
snapshots. When using the NetWorker Module for Oracle, customers can take advantage of reduced
recovery time through higher-frequency snapshots of their Oracle databases.

Audience
This white paper is targeted to corporate management and business decision-makers, including storage,
server, and database administrators, IT managers, and application engineers, as well as storage integrators,
consultants, and distributors.

Terminology
The terminology used in the white paper is only related to PowerSnap™, SQL, and the NetWorker Module
for Microsoft SQL Server.

Backup
Backup provides a copy of original data that is created from a variety of media. Given its low cost, tape
media has been the most common media type for backup. Today, disk-based media provides a more ideal
medium for reliability, speed, and overall recovery associated with backups. Advanced backup capabilities
connect backup with array-based replication and replication management.


File level recovery
The file level recovery process is individual file restoration from a mounted replica. It is also referred to as
instant recovery or file-by-file recovery.

Instant backup
A replica or point-in-time copy of data that is initiated and stored on the array as a snapshot session or
instance is called an instant backup. An instant backup is a block-level snapshot created from the
application server but not written to tape. In the case of NetWorker PowerSnap, the replica is registered
within the NetWorker media database to facilitate tracking for recovery.

Live backup
Live backup is a backup to secondary storage such as tape that occurs from a replica via a proxy host
without impact to the original application or data host.

Recovery management
Recovery management is a strategic approach to data protection that focuses on fast, reliable recovery as
the aggregate goal of all protection activities. Key EMC solutions that comprise the recovery management
portfolio include NetWorker (for backup and recovery), Backup Advisor (for reporting and analytics),
CLARiiON® and Symmetrix (storage array hardware), RecoverPoint (continuous data protection), and
Replication Manager (common management for EMC replication technologies).

Restore from disk/tape backup
Data that has been saved to disk or tape through the live backup process is recoverable in the same manner
as any basic restore. Save sets and individual folders or files can be restored via a recovery interface or
from a command line.

Rollback
A rollback is the process of returning data to an earlier point-in-time copy in response to a recovery
operation, and it is a complete restore from a point-in-time copy to a standard volume without host
involvement.

Roll forward
A roll forward is the process of progressing data from a rollback using one or more instant backups. For
example, if three snapshots were created at 10 A.M., 11 A.M., and 12 P.M., the user can perform a rollback
to the 10 A.M. snapshot and then a roll forward to the 11 A.M. snapshot or even the 12 P.M. snapshot.
Users may perform a rollback from a more recent copy to approximate the same effect.

Conventional
A nonpersistent snapshot backup creates a point-in-time copy of a SQL database, and then immediately
moves it to secondary storage on the NetWorker server or storage node. The original snapshot is
automatically deleted from primary storage. In the NetWorker Module for Microsoft SQL Server, the
nonpersistent backup type is called “Conventional Backups”.

Traditional
Traditional backup is the same as homogenous PowerSnap backups (discussed in later sections).

Snapshot technologies in backups
What is a snapshot?
A snapshot is an image of your data set (a data set can be just a bunch of file systems or specific application
data such as Oracle/SQL Server, and so on). There are different snapshot technologies available to cater to


the needs of snapshots. This white paper will talk in detail about the snapshot technologies of Symmetrix
arrays, which are the baseline of the solution using EMC NetWorker, PowerSnap, and the NetWorker
Module for SQL Server, to back up a SQL Server database.

Snapshot backups
Snapshot backups of SQL Server databases are configured as scheduled backups on the NetWorker server.

The EMC NetWorker Module for Microsoft SQL Server supports:
• Snapshot backups of SQL Server databases.
• Backups of only one database per scheduled backup. Backups are supported at a database level, but
restores are supported at database/filegroup and file levels
• Instant, nonpersistent, and serverless snapshot backups.
• Backup of only one database per client resource. Passing multiple databases in single client resource
will cause backup failures
• Database and logs should be on two different file systems (preferably on two different disks)

The EMC NetWorker Module for Microsoft SQL Server does not support:
• Differential or incremental (transaction log) backups for databases under a snapshot schedule.
• Snapshot backups for individual file groups or files.
• Snapshot backups of the SQL Server system databases (master, model, msdb).

Instant backup
An instant backup creates a point-in-time copy (PiT), or snapshot, of a SQL Server database and retains the
snapshot on the primary storage subsystem (Symmetrix). Depending on how backups are configured, a
snapshot created during an instant backup may or may not be moved to secondary storage on the
NetWorker server or storage node. Whether the snapshot should be retained is dependent on the snapshot
policy.

There are three ways to manage PiT snapshot backups:

• A PiT copy of the data is created and immediately backed up to tape or disk, and the original snapshot
is deleted after the backup is complete. A save set that is created on tape is called a “rollover save set.”
This process enables you to perform a tape restore.
• An existing PiT copy of the data can be copied to a tape or disk, much like a traditional EMC
NetWorker backup, and the original PIT copy is retained on the primary storage subsystem. Thus, two
copies of this backup exist. This process enables you to perform a rollover or PiT restore.
• A PiT copy of the data is created and retained on the primary storage subsystem and no other copy is
maintained. You can use this copy to perform a PiT restore only once. If the PIT restore fails for any
reason, the restore must be performed from another backup (another snapshot or conventional tape
restore).

While the snapshot resides on the primary storage subsystem, it is referred to as a persistent snapshot.
Retaining persistent snapshots on primary storage enables the EMC NetWorker Module for Microsoft SQL
Server to perform an instant restore.


Application host Instant Proxy host

Backup to
Sync

STD BCV
Symmetrix

split

Instant

Figure 1. Instant backup to PIT

Nonpersistent backup
A nonpersistent snapshot backup creates a point-in-time copy of a SQL Server database, and then
immediately moves it to secondary storage on the EMC NetWorker server or storage node. The original
snapshot is automatically deleted from primary storage.

Serverless backups
In a serverless backup, a snapshot is created on the primary storage subsystem and is immediately moved to
secondary storage by a proxy client. There is no need for the SQL Server host to move the data to the
secondary storage medium (typically tape).

File-logical image backup (FLIB)
PowerSnap is optimized to perform nondisruptive backups of large data sets quickly. PowerSnap file-
logical image backups (FLIB) are best suited for backups of large files. A FLIB-type backup first “walks”
through each file in the file system to gather file information and extent list information. Then, the file
system and volume manager are circumvented and the data is read directly from the disk. The file and
extent list information of each file is used to place the data onto tape. NetWorker is used to maintain client
and media management index databases. The resulting backup format on tape is exactly as that of a
traditional NetWorker backup.

Snapshot recoveries
Besides restoring databases from tape media using EMC NetWorker and the NetWorker Module for
Microsoft SQL Server, several advanced restore capabilities exist, including instant recovery and rollback.

Instant restore
A snapshot recovery operation can be performed at the file, file group, or database level from a full
database snapshot. The EMC NetWorker Module for Microsoft SQL Server supports one type of snapshot
restore operation called an instant restore.


An instant restore operation recovers data from a PIT snapshot but does not eradicate the original snapshot.

Rollback
The EMC NetWorker Module for Microsoft SQL Server backups can use NetWorker PowerSnap
functionality to create a PIT copy, or instant backup, of a SQL Server database. Many instant backups can
be performed in a single day, thus reducing the exposure to data loss.

A rollback recovers a specific PIT copy to one or more volumes. You can request a rollback without having
to retrieve data from a secondary storage system, such as tape. Rollback of a managed or nonmanaged
volume prevents the snapshot from being maintained and causes the snapset to become invalid. To
minimize risk to data, first perform a tape backup of the snapshot before performing a rollback operation.
Rollbacks are destructive by nature, which means that the entire contents of the file system are overwritten.
As a default safety check, a rollback can only restore the original volume.

File-logical image recovery (FLIR)
A file-logical image recover (FLIR) is obtained directly from the proxy client host to the production
volume (STD), and consists of only data blocks. This requires that earlier file preallocation, extension, and
truncation is complete on the application host by using native operating system input/output paths before
the recovery. Data movement is bounded by data blocks of files that have requested for recovery. This is a
nondestructive recovery. In a FLIR, a BCV or VDEV may be used to keep a copy of the STD volume as it
was prior to the recovery.
In case of FLIR recovery, STD should be made visible to the data mover.

SC Restore (SymmConnect Restore, FLIR that uses a mirror)
FLIR using a mirror recovers to a BCV rather than to a STD device, and then synchronizes the BCV with
the standard. Such recoveries do not go over the LAN, but instead, the recovered data travels from the
PowerSnap server to the Symmetrix storage array. Also, by performing a BCV recovery/rollback to the
standard, the data is immediately available to the client and does not wait for the BCV recovery/rollback to
complete. PowerSnap also supports performance of granular recoveries from tape to the BCV, and then
initiates a full BCV rollback to the standard. The file system is unmounted by PowerSnap prior to
recoveries.

Conventional/tape restore
Conventional restores are performed from tape attached to the NetWorker storage node directly to the
standard device (STD) on the application host.

EMC Symmetrix storage arrays
The NetWorker PowerSnap Module interacts with the Symmetrix storage system, using its EMC
TimeFinder® functionality to create and maintain snapshots of the data.

Symmetrix TimeFinder is a business continuance solution that allows you to use a business continuance
volume (BCV) or Symmetrix virtual devices (VDEV) to create a point-in-time copy.

TimeFinder/Mirror
The EMC TimeFinder/Mirror features allow you to make copies of data simultaneously on multiple target
devices from a single source device. The data is available to a target’s host instantly. You can copy data
from a single source device to as many as 16 target devices.


For TimeFinder/Mirror the target device can be a standard device or TimeFinder business continuance
volume (BCV).

The BCV is a Symmetrix device with special attributes created when the Symmetrix is configured. It can
function either as an additional mirror to a Symmetrix logical volume or as an independent, host-
addressable volume. Establishing BCV devices as mirror images of active production volumes allows you
to run multiple simultaneous business continuance tasks in parallel. The principal device, known as the
standard device, remains online for regular Symmetrix operation from the original production server. Each
BCV contains a unique host address, making it accessible to a separate backup/recovery server.

Figure 2. Multiple copies of a single source volume using TimeFinder/Mirror (BCV)

Note: PowerSnap supports only a BCV as the target device for TimeFinder/Mirror

TimeFinder/Snap
The TimeFinder/Snap features allow you to make copies of data simultaneously on multiple target devices
from a single source device. The data is available to a target’s host instantly. You can copy data from a
single source device to as many as 16 target devices.

For TimeFinder/Snap the target device is a Symmetrix virtual device that consumes negligible physical
storage through the use of pointers to track data.

The virtual device is a host-addressable Symmetrix device with special attributes created at configuration
time. But unlike the BCV, which contains a full volume of data, the virtual device is a “slim” device that
offers a space-saving way to create instant point-in-time copies of logical volumes. Any updates to a source
device after its activation with a virtual device cause the pre-update image of the changed tracks to be
copied to a save device. The virtual device’s indirect pointer is then updated to point to this original track
data, preserving a point-in-time image of the volume. TimeFinder/Snap uses this copy-on-first-write
technique to conserve disk space, since only changes to tracks on the source cause any incremental storage
to be consumed.


Figure 3. Virtual devices as point-in-time copies

EMC NetWorker
NetWorker software comprises a high-capacity, easy-to-use data storage management solution that protects
and helps manage data across an entire network. NetWorker simplifies the storage management process and
reduces administrative burden by automating and centralizing data storage operations.The NetWorker
software enables a user to:
• Perform automated backups during non-peak hours.
• Administer, configure, monitor, and control NetWorker functions from any computer on a network.
• Centralize and automate data management operations.
• Increase backup performance by simultaneously sending more than one save stream to a single device.
• Optimize performance by using parallel save streams to multiple backup devices or storage nodes.

EMC NetWorker PowerSnap
The PowerSnap Module enhances NetWorker by allowing continuous snapshot-based data protection and
availability during backups for the Symmetrix storage system. The backup is virtually instantaneous,
despite the size of the volume. The PowerSnap Module software enables frequent backups with little
impact to the network or application server to provide nondisruptive backups of large databases or data
stored in file systems.
The PowerSnap Module solution provides high-performance block level (image) as well as traditional file
and operating system-based backup technology. The traditional backups are called conventional backups.
Block level (image) backups are similar to traditional NetWorker backups, but when the file data is saved,
the file system and volume manager are circumvented, and the data is read from the disk directly. The
index format on tape is exactly the same as that of a traditional backup index format. The advantage of
block level or image backups is that they are faster than conventional backups, that is, if the file or raw
volume size is predominately over 2 MB.
PowerSnap has seamlessly integrated snapshot technology into NetWorker software. PowerSnap features
are configured through NetWorker. The application server with the PowerSnap Module communicates with
the NetWorker server to back up a volume or file system belonging to a client. The group of files, volumes,
or file systems from a single client, describing the collection of data for which a point-in-time copy (PiT) is
created on an external disk subsystem, such as a storage array, is referred to as a snapset.
For instant backups, the PowerSnap Module software creates a PiT, or snapshot, of the snapset and stores
the copy on the Symmetrix as a snapshot session. This is known as an instant backup. The instant backup is
a snapshot that is not written to tape but has some metadata that is written to tape.


The PowerSnap Module uses the snap pool file to identify physical volumes for which a PiT copy needs to
be created, performs file system quiescing/flushing, if required, and creates a fully usable snapshot copy.
After quiescing the file systems, PIT creation is of such duration that the user should not notice any delay.
All backups can be done with a second-host proxy client (data mover), which results in better performance
because the load (CPU and memory utilization) is shared with the proxy host. An instant backup, for non-
image backups, of the data is created from the application server, but the proxy client moves the actual data
to the tape or disk medium. The proxy client is specified in the client resource of the NetWorker
Administrator software.

EMC NetWorker Module for Microsoft SQL Server
The EMC NetWorker Module for Microsoft SQL Server (NMSQL) is a NetWorker add-on module that
provides backup and restore of the following database and transaction logs:
• Microsoft SQL Server 2005
• Microsoft SQL Server 2005 Express
• Microsoft SQL Server 7.0

NMSQL integrates data protection procedures for Microsoft SQL Server databases with the NetWorker
software. This provides a comprehensive storage management solution that addresses the need for cross-
platform support of enterprise applications on Microsoft Windows operating systems.

NetWorker Module for SQL Server and PowerSnap
Figure 4 explains the workflow and the interactions of different components of NMSQL, PowerSnap, and
the NetWorker server.

Figure 4. Backup/restore workflow of NetWorker Module for SQL Server and PowerSnap


Backup workflows
Homogenous workflow
For homogenous workflow the proxy client/data mover should be with the same operating system,
hardware architecture, and storage stack as the application host, for which it performs the backup or
recovery.

The backups supported in this workflow are the following:
• PiT backup
• Serverless backup
• PiT + rollover backup
The restores supported in this workflow are the following:
• PiT restore
• Rollback restore
• Conventional restore

Snapshot management
When a PIT copy is created, a unique save set ID is assigned. In addition, when the data from that PIT copy
is backed up to a tape or disk medium, a different save set ID is assigned to that data. By having two unique
save set IDs, the snapshots (PiT copies) can be handled separately from the backed up data. The copy of the
data is removed only when all snapshots and backups of the data have been deleted.

Heterogeneous workflow
For heterogeneous workflow the proxy client/data mover is supported only on the Solaris version (8, 9, 10)
for which it performs the backup and recovery. Under this workflow only file-logical image backup is
supported. User cannot retain point-in-time copies. Once the PiT is created, for the BCV/VDEV based on
the snapshot technology the target devices are split and the data is rolled over to secondary media on the
NetWorker storage node.

The backup supported in this workflow are the following:
• Serverless backup (FLIB)

The restores supported in this workflow are the following:
• FLIR restores
• SC restores

PowerSnap snapshot backup of NMSQL
Both the homogenous and heterogeneous workflows are supported by the NetWorker Module for SQL and
PowerSnap for the SQL database backups.

Snapshot backups of the SQL database can be backed up only at the database levels; however, restore can
be at file group/file/database level

Restores can also be performed at the same granular level at which the backups are performed.


Configuring a NMSQL database
The NMSQL executable binary (that is, nsrsqlsv.exe) will be present in the NetWorker Module for SQL
Install directory (C:Proga~1Legatonsrbin). For PowerSnap Ssnapshot backups of SQL Server, make
sure that the data is present in a separate file system than the file system used for transaction logs

Configuring the Symmetrix Groups and Resource file
The symm.res file should be created by the user. The symm.res file has entries of the Symmetrix ID and the
device ID of the standard device (STD) and the device ID of the BCV or VDEV based on the snapshot
technology chosen by the user.

User should identify all the STDs where the database data is residing. For taking a snapshot backup of
database, each disk should have a mapping to at least one BCV. (Also, ensure that the BCV that is mapped
to the source STD is not paired with any other STD.)

• Ensure that the appropriate version of Solutions Enabler (SymAPI) is installed on both the application
server and on the proxy host. Refer to the EMC Information Protection Software Compatibility Guide
for the most accurate and up-to-date information.
• Ensure that STD devices used by the Microsoft SQL Server database are visible to the application host.
• Ensure that all BCV devices that share the same exact size as the STD are visible to the proxy host
(there could be up to eight BCV devices for each STD).
• On the application server and on the proxy host, run the command symcfg list.
• The symcfg command returns a list of available Symmetrix arrays visible to the host.

C:Documents and SettingsAdministrator>symcfg list
SYMMETRIX
Mcode Cache Num Phys Num Symm
SymmID Attachment Model Version Size (MB) Devices Devices

000187461273 Local 1000P-M2 5671 65536 17 2609
000387940030 Local DMX800 5671 16384 4 2278
000187461276 Remote 1000P-M2 5670 65536 0 2265

Record the SymmID and compare it between the application server and the proxy host.
On the application host run the following syminq command.
The syminq command returns a list of all available Symmetrix drives visible to the host.

C:Documents and SettingsAdministrator>syminq

Device Product Device
-------------------------- --------------------------- ---------------------
Name Type Vendor ID Rev Ser Num Cap (KB)
-------------------------- --------------------------- ---------------------
.PHYSICALDRIVE0 DELL PERC 5/i 1.03 N/A N/A
.PHYSICALDRIVE1 GK EMC SYMMETRIX 5671 730014B291 2880
.PHYSICALDRIVE2 GK EMC SYMMETRIX 5671 730014C291 2880
.PHYSICALDRIVE3 EMC SYMMETRIX 5671 730014D291 5242560
.PHYSICALDRIVE4 EMC SYMMETRIX 5671 730014E291 5242560


.PHYSICALDRIVE5 EMC SYMMETRIX 5671 730014F291 5242560
.PHYSICALDRIVE6 EMC SYMMETRIX 5671 7300150291 5242560
.PHYSICALDRIVE8 BCV EMC SYMMETRIX 5671 7300152291 5242560

• Write down the Symmetrix device number that is used to hold the Microsoft SQL Server data. To
identify the device number, look at the third, fourth, and fifth digits of the Ser Num.
• For Symmetrix DMX™, the Symmetrix device number will be a four-digit number and would be
represented by the fourth, fifth, sixth, and seventh digits of the Ser Num. In the example above, device
.PHYSICALDRIVE5 is Symmetrix device number 014F.
• On the proxy host, run the syminq command and write down the BCV device number that you are
planning to use.
• Ensure that the BCV device size is identical to the source device size. In our example, an option is to
match Symmetrix device 014F with BCV device 015F as their sizes are identical.

C:Documents and SettingsAdministrator>syminq

Device Product Device
-------------------------- --------------------------- ---------------------
Name Type Vendor ID Rev Ser Num Cap (KB)
-------------------------- --------------------------- ---------------------
.PHYSICALDRIVE0 DELL PERC 5/i 1.03 N/A N/A
.PHYSICALDRIVE1 GK EMC SYMMETRIX 5671 730015C291 2880
.PHYSICALDRIVE2 GK EMC SYMMETRIX 5671 730015D291 2880
.PHYSICALDRIVE3 BCV EMC SYMMETRIX 5671 730015E291 5242560
.PHYSICALDRIVE4 BCV EMC SYMMETRIX 5671 730015F291 5242560

• Match standard Symmetrix devices with BCV devices.
1. Create a Symmetrix disk group (symdg).
This group could be created either on the application and would be used by PowerSnap.
To create the device group, execute:
symdg create [group_name]

For example:
symdg create pstest


a. Add the Symmetrix STD devices (the production devices) to the newly created group by
executing:
symld –g [group_name] –sid [SymmId] add dev [dev#]

For example:
symld –g pstest –sid 000387940030 add dev 014F.

Repeat the symld command for all STD devices.

b. Add the BCV devices to the group by executing:
symbcv –g [group_name] –sid [SymmId] associate dev
[bcv_dev_#]

For example:
symbcv –g pstest –sid 000387940030 associate dev 015F
Repeat the symbcv command for every BCV device you need to add.

2. Verify the configuration: C:Documents and SettingsAdministrator>symdg list

DEVICE GROUPS

Number of
Name Type Valid Symmetrix ID Devs GKs BCVs VDEVs TGTs

pstest REGULAR Yes 000387940030 1 0 1 0 0

C:Documents and SettingsAdministrator>symld -g pstest list

Device Group (DG) Name: pstest
DG's Type : REGULAR
DG's Symmetrix ID : 000387940030

Standard Device Name Directors Device
---------------------------------- ------------- ----------------------------
Cap
Logical Physical Sym SA :P DA :IT Config Att Sts (MB)
---------------------------------- ------------- ----------------------------

DEV001 DRIVE20 014F + 15C:1 01A:C0 Unprotected RW
8192

Legend for STD devices:

(+): Paired with a BCV device that is associated with this dg.
(-): Paired with a BCV device that is non-associated with this dg.


BCV Devices associated with this dg:

BCV Device Standard Device Status
------------------------------------ --------------------------- ------------
Inv. Inv.
Logical Sym RDF Att. Tracks Logical Sym Tracks BCV <=> STD
------------------------------------ --------------------------- ------------

BCV001 015F + 0 DEV001 014F 0 Split

Total -------- --------
MB(s) 0.0 0.0

Legend for BCV devices:

(+): BCV is paired with a member STD device.
(-): BCV is paired with a non-member STD device.

C:Documents and SettingsAdministrator>
Example of the symm.res
000387940030: 014F 015F

By default PowerSnap will look for the symm.res file at /nsr/res. The user can store the file in a non-default
location and specify the path of the res file using the parameter SYMM_PROVIDER_DB=<absolute path
of the symm.res file>. The variable should be mentioned in the Application Information of the NetWorker
Client.
The user has to manually create the symdg group and add the standard and the BCV or VDEV devices that
are used for backup.

Configuring a NetWorker client for backups in a
homogenous workflow
The NetWorker Module for Microsoft SQL Server supports snapshot backup operations in homogenous
storage platform environments only. All SQL components (databases and log files) must be located on a
snapshot-capable storage subsystem.

Traditional backup workflow
For traditional backups the production host and proxy client should have the same operating system.
For traditional backups, Microsoft SQL Server supports database level backups. NMSQL provides the
mechanism that integrates the SQL database backup technology with the NetWorker software. Microsoft
SQL Server 2000 and 2005 provide support for backing up and restoring file groups and files. In addition to
creating a level full file or file group backup, SQL Server 2000 and 2005 support the creation of file group
differential and file differential backups. A file group differential backup may actually reduce both media
requirements and restore time. The data can be stored across more than one disk or disk partition, and
restore time may be reduced. A differential can substitute for all log backups performed between the full
and differential backups.


The user has to specify the “Application Information” in the client properties section. The following are
the parameters that need to be mentioned in the Application Information section.

Application Variables:
=================
NSR_PS_DEBUG_LEVEL=9
NSR_DATA_MOVER=<data mover name>
SYMM_SNAP_TECH=BCV
NSR_SNAP_TYPE=symm-dmx
NSR_IMAGE_SAVE=FALSE
SYMM_ON_DELETE=RELEASE_RESOURCE

Figure 5. Syntax for the NMSQL save set is MSSQL:<Database Name>


Figure 6. The Application information and backup command

NMSQL recoveries supported in homogenous workflow
NetWorker Module for SQL Server supports different type of restores such as Normal, Copy, Partial (SQL
2000) or Piecemeal (SQL 2005), and Verify only. All of these are discussed in the following sections.

With the PowerSnap module, a user can perform all these restores either from a snapshot copy or from the
tape copy.

Microsoft SQL Server database recoveries are done via the NMSQL GUI. PowerSnap supports recovery
down to the single database level. There are four ways to perform Microsoft SQL Server recoveries with
the PowerSnap Module:
• Normal
• Copy
• Verify only
• Partial/Piecemeal

Figure 7. NMSQL Restore windows


Normal
The normal restore type restores the entire set of data associated with one or more SQL Server 7.0 or later
backups, including full, incremental, and differential backups. The normal restore type supports recovery of
a file, file group, or a database to the database originally backed up. The normal restore type can restore
level full, level 1 (differential), and level incremental backups in the order required by SQL Server. When
performing a restore, NMSQL uses the normal restore type as the default. Because NMSQL can back up
only specified files and file groups of a SQL Server 7.0 or later database, restoring from a media failure that
affects only a subset of the data in the databases is possible. In addition, a single file group, or multiple file
groups and/or files, can be restored from a full database backup.

Copy
A copy restore is an operation in which data is recovered to a SQL Server host other than the one from
which it was backed up. Note that copy restore from and to the same SQL Server instance also can be done.
Following are the SQL Server versions supported for this restore type:
• Microsoft SQL Server 2005 Express
• Microsoft SQL Server 7.0
The copy restore type creates a copy of a database by restoring a SQL Server 7.0 or later database backup
to a new location, or to a new database name. The copy restore type makes it easy to replicate a database
that was previously backed up. You can only mark a single item for this operation. In addition, you can
copy a system database, but you cannot overwrite it.

NMSQL enables you to restore snapshot backups to a SQL Server host that does not have a snapshot-
capable storage subsystem.

A copy restore of a snapshot backup supports the creation of a new database for the following scenarios:
• Copy restore of an instant backup to a new location
• Copy restore of an instant backup to another database on the same host within the same storage array
• Copy restore of an instant backup to a new database on the same host within a different storage array
• Copy restore from a rollover
• Copy restore to another database on the same host
• Copy restore to another database on a different host

Verify only
The verify-only restore type verifies only the backup media for the selected SQL Server 7.0 or later
backups.

Selecting the verify-only restore type does not restore the SQL Server data. In addition, when verify-only is
specified, item-level properties for file, file group, and database objects are not available.

Piecemeal restore
Partial restore is enabled for SQL Server 2000 releases. If you are restoring SQL Server 2005 databases
(Enterprise Edition only), the option becomes piecemeal restore.

To configure a partial or piecemeal restore:
1. Select the Piecemeal restore type from the Restore Operation dialog box and click Continue.


Figure 8. Selecting Piecemeal as a restore operation

2. Select the primary group in the restore window and right-click and click the properties.
The Restore window as shown in Figure 9 appears.

Figure 9. Restore window


Figure 10. Properties window

3. In the General tab, select the Normal recovery mode (Figure 10). Select the Files tab and mark the
Primary Group to restore, as shown in Figure 11.

Figure 11. Marking the Primary Group


4. After clicking OK, the Restore Options window appears. Select the Restore Type order.

Figure 12. Setting the Restore Type

Specify the data mover name, select the File Level restore order type, and click OK.
Once the Primary Group restore is successful then make the database online and follow this procedure
to recover the other file groups and files.

PowerSnap recoveries supported in homogenous workflow
These three PowerSnap recover types are supported in a homogenous workflow. User should be able to use
the combination of these PowerSnap Restore types with the NMSQL Restore types that are described in the
section “NMSQL recoveries supported in homogenous workflow” on page 19.
• Instant Restore
• Conventional Restore
• Rollback

Instant restore
The restore will be performed from a PIT copy. The parameter RESTORE_TYPE_ORDER should be
provided in the Restore Options configuration window as Persistent Snapshot (Figure 13).


Figure 13. Setting a Persistent Snapshot

standard device (STD) on the Application Host. The parameter RESTORE_TYPE_ORDER should be
provided in the restore configuration window as NetWorker Server.

Figure 14. Conventional restore


Rollback restore
Rollback restore is a destructive restore and a user has to manually configure psrollback.res to avoid the
safety check on the rollback file systems. Apart from that, NMSQL also has its own checks for other
databases that reside on the same volumes.

The parameter RESTORE_TYPE_ORDER should be provided in the Restore Options window. Select the
Volume level rollback option.

Figure 15. Rollback restore

PowerSnap safety check
PowerSnap applies the safety check rules during rollback restore to avoid overwriting the source data
accidentally during a rollback restore. To allow the rollback restore to succeed without the safety check
failure, a user has to manually add the files that are allowed to be overwritten in the powersnap.res file.
This file is located in C:Progra~1Legatonsrres.

In general terms a safety check should complain about any object that would be affected by the rollback
that is not included within the object or object that are supplied for the rollback. For a concrete example
let’s look at a Symmetrix disk with the following layout:

STD1
- /fs1
- datafile1


- datafile2
- dir1
-datafile3

-/fs2
datafile4

Now when a snapshot is taken of any object on the STD, we end up with a snap of everything shown
above. This means that a rollback will result always result in fs1 and fs2 being reverted to their states at the
time of the snap. The purpose of the safety is to inform the PS user that there are objects outside the scope
of what they have requested to have rolled back. This means that the restore objects have a direct effect on
whether or not the safety check will fail or pass.
Now let’s assume we add the following to the file systems and look at how we expect the safety check to
behave in a few rollback scenarios:

/fs1/newdatafile5
/fs1/dir1/newdatafile6
/fs2/newdatefile7

First, let’s look at some cases for a file system rollback.
Case 1: Rollback requested for /fs1
/fs2 would cause the safety check to fail.
None of the new files affect the safety check. This is because the first two files are within the scope of
what we were told to roll back (/fs1) and the third file is within the scope of /fs2.

Case 2: Rollback requested for /fs1/dir1
/fs2 would cause a safety check failure
/fs1/newdatafile5 would cause a safety check failure.
The other two new files don't fail the safety check. This is because /fs1/dir1/newdatafile6 is within the
scope of what we were told to roll back and the last file is within the scope of /fs2.

Now let’s consider the SQL restore. If a rollback is being done and there are any additions to the affected
file systems it will in a safety check failure. The user has to add all other files (on the source disk(s)) that
are not part of rollback restore in the psrollback.res file

NMSQL will prevent rollback if multiple databases reside on the same volume regardless of PowerSnap
safety checking unless “Force rollback” is checked. These “other databases” were not quiesced at the time
of the snapshot and they may be corrupt (aka Suspect) when restored. At a minimum they will lose data for
the time period between the snapshot and the rollback.

Figure 16. Sample psrollback.res file


Configuring a NetWorker client for backups in a
heterogeneous workflow
In a heterogeneous workflow the user cannot retain any snapshots. Snapshots will be taken and rolled over
to the tape connected on the NetWorker storage node, and then the snapshot is deleted.

The Serverless Backup snapshot policy is the only supported snapshot policy for Heterogeneous workflow

SymmConnect workflow backup
PowerSnap is optimized to perform nondisruptive backups of large data sets quickly. PowerSnap file-
logical image backups (FLIB) are best suited for backups of large files. Currently this capability is provided
through a Solaris data mover for Microsoft Windows clients.

SymmConnect backup supports only the Serverless Snapshot policy. The application variables that follow
are used for a SymmConnect workflow.

The user has to specify the Application Information in the client properties section. The following are the
parameters that need to be mentioned in the Application Information section.

Application Variables:
=================
NSR_PS_DEBUG_LEVEL=9
NSR_DATA_MOVER=petunia.blrsql.com
SYMM_SNAP_TECH=BCV
NSR_SNAP_TYPE=symm-dmx
NSR_IMAGE_SAVE=TRUE
SYMM_ON_DELETE=RELEASE_RESOURCE

Figure 17. Syntax for the NMSQL save set is MSSQL:<Database Name>


Figure 18. The backup command is nsrsqlsv

Recoveries supported in a heterogeneous workflow
All SQL recoveries are done from the NMSQL Recovery window. The following are the recoveries
supported by PowerSnap in heterogeneous workflow for NMSQL:
• FLIR
• FLIR to mirror

FLIR
For the FLIR restores, the standard device (STD) should also be visible on the proxy client/data mover.
While doing FLIR restore we need to select the RESTORE_TYPE_ORDER as nsrsqlsv in the Restore
Options window.

FLIR using a mirror (SymmConnect restore)
FLIR using a mirror recovers to a BCV rather than to a STD device, and then synchronizes the BCV with
the standard. Such recoveries do not go over the LAN, but instead, the recovered data travels from the
PowerSnap server to the Symmetrix storage array. Also, by performing a BCV recovery/rollback to the
standard, the data is immediately available to the client and does not wait for the BCV recovery/rollback to
complete. PowerSnap also supports performance of granular recoveries from tape to the BCV, and then
initiate a full BCV rollback to the standard. The file system is unmounted by PowerSnap prior to
recoveries.
While doing FLIR using a mirror restore we need to select the RESTORE_TYPE_ORDER as FLIR to
mirror in the Restore Options window.


Note: SymmConnect restores are destructive in nature. Restores will fail if the standard is paired with any other
BCV or VDEV. User will have to break the relationship with other target devices for restore to be successful.
Also, there shouldn’t be any other volume/file system from the same disk mounted when performing an SC
Restore.
The BCV to be used for the mirror is selected from the symm.res file or the file specified with
SYMM_SNAP_POOL variable.

standard device (STD) on the application host. The parameter RESTORE_TYPE_ORDER should be
provided in the Restore Options configuration window as NetWorker Server.

Figure 19. Conventional restore

Selection of a remote storage node
NetWorker has a feature to specify the storage node to be used for backups. The user can specify the
storage node to be used for the backups, which will help in avoiding the data to be backed up over the
network, thereby shortening the backup window. PowerSnap backups can gain from these features by
installing the storage node on the data mover and directing the backups to the devices attached to this
storage node.


PowerSnap can leverage the remote storage node functionality of NetWorker where the user will be able to
set the affinity of a client to a particular storage node. By default, all the backups are directed to devices
attached to the NetWorker server
The remote storage node gives flexibility to direct the backup data to go to a particular storage node, which
indirectly means to a set of devices belonging to that storage node. Figure 20 illustrates the settings for
specifying the affinity for a storage node.

Specify the
storage node
here

Figure 20. Specifying the storage node

Using this functionality a user can set the affinity for different storage nodes. For instance the remote host
that has the remote storage area can set the storage node affinity to itself (if it has the storage node
installed) or to a different storage node, nearer to itself, in order to avert network traffic. By default the
storage node is set to “nsrserverhost”, which means the data is backed up to devices connected directly to
the NetWorker server.
A remote device is configured using this convention:
rd=storagenode1:.Tape0 or rd=storgaenode1:/networkerdevice
where storagenode1 is the hostname of the remote storage node


Figure 21 shows the NetWorker Management Console with a remote device configured on a NetWorker
server.

Remote Device is configured

Figure 21. Remote device configured

Troubleshooting tips
Not Enough Resources to create the snapshot:
ERROR [BrcBackupOp.cpp 707] Not Enough Resources to Create Snapshot: No Matching Device Found
ERROR [BrcBackupOp.cpp 711] Failed to prepare the snapshot of O: nmsqldb1.mdf.

To solve this issue:
1. Check that the retain snapshots number is the same as the number of BCVs paired for the STD in the
resource file symm.res.
2. Run symcfg discover on the proxy client to check whether the BCVs are still visible to the data mover.
3. Check the BCV status, and make the BCV to ready state.
4. Check the configurations in symm.res, and make sure that the STD > BCV pair is correct.


Conclusion
The innovative technologies of EMC NetWorker PowerSnap and EMC Symmetrix storage arrays combine
to bring out key customer benefits within an EMC NetWorker-protected Microsoft SQL Server
environment. Organizations implementing such a solution are expected to see the following benefits:

• Seamless integration into an existing IT storage infrastructure with no impact to the SQL Server
applications
• Instantaneous access to SQL Server database backups at specific points in time, improving recovery
time objectives over tape-based recovery solutions
• Reduced SQL Server downtime due to the low overhead of creating snapshots with EMC NetWorker
PowerSnap and EMC Symmetrix arrays
• Reduced backup and restore windows by using block-based backups

References
• EMC NetWorker PowerSnap Module for EMC Symmetrix DMX Installation Guide
• EMC NetWorker PowerSnap Module for EMC Symmetrix DMX Administration Guide
• EMC NetWorker PowerSnap Module for EMC Symmetrix DMX Release Notes
• EMC NetWorker Module for Microsoft SQL Server Installation Guide
• EMC NetWorker Module for Microsoft SQL Server Administration Guide
• EMC NetWorker Module for Microsoft SQL Server Release Notes
• EMC NetWorker Multiplatform Version Administration Guide
• EMC NetWorker Multiplatform Version Release Notes
• EMC Information Protection Software Compatibility Guide
• Configuring PowerSnap with Microsoft SQL Databases on EMC Symmetrix and EMC CLARiiON
Systems Technical Note

View EMC’s proven solutions for data replication, data lifecycle management, disaster recovery and
continuous data protection at http://www.EMC.com.

View detailed information on the EMC NetWorker family of products at
http://www.emc.com/products/detail/software/networker.htm.


Backup of Microsoft SQL Server in EMC Symmetrix Environments ...

More Related Content

What's hot (20)

Viewers also liked (6)

Similar to Backup of Microsoft SQL Server in EMC Symmetrix Environments ... (20)

More from webhostingguy (20)

Backup of Microsoft SQL Server in EMC Symmetrix Environments ...