SnapManager 2.1 for Microsoft SQL Server includes the ability to automatically run a command or script after a backup or verification operation is finished. This feature, called Run Command After Operation, enables you to specify that a particular SnapManager Backup operation is to automatically run a script when the backup is finished. The specification includes any command-line parameters that can be inserted based on the components of the backup or verification. A typical use for this feature, called Run Command After Operation, is to run a script that automatically archives a backup at the time it is created.
You can use SnapVault to automatically archive SnapManager backups sets. See the following topics for more information:
The following paragraphs summarize how SnapManager backups can be archived using SnapVault.
Use SnapManager to perform a full database backup and verify the databases in that backup set.
Note
SnapManager cannot be configured to perform database verification directly on the secondary storage. Verification operations must occur for databases residing on the primary storage.
The backup operation is specified with the Run Command After Operation option selected.
Note
Only backup sets that have been verified should be archived.
SnapVault, under the control of the script launched at the end of the SnapManager full database backup operation, is used to transfer the specified backup set from a SnapManager-initiated Snapshot copy on the primary storage system to a SnapVault-managed Snapshot copy on the secondary storage system. SnapVault is used to manage backup retention of the archives on the secondary storage volume.
In the event of a catastrophic failure of your SQL Server environment, SnapVault can be used to recover the LUNs, and then SnapManager can be used to restore your SQL Server databases from these SnapVault archives.
The following paragraphs describe points to consider when planning your archival scheme.
SnapVault Snapshot copies are queued so that a failure to create one archival Snapshot copy, where multiple primary storage filers point to a single secondary system, causes subsequent archival Snapshot copies not to finish.
By design, SnapVault operates on a volume-wide unit. All the SnapVault qtrees in a secondary volume must follow the same backup schedule, and volume-wide Snapshot copies are coalesced and shared among all the SnapVault qtrees in the volume. SnapVault avoids creating backup/archival Snapshot copies of the configured qtrees when the qtrees are in an unstable or transitioning state, such as when a transfer is in progress.
The backup schedules of the SnapVault qtrees in a secondary volume are inextricably tied. When SnapVault performs backups to all or a subset of these qtrees, some transfers might finish faster than others. However, no further SnapVault updates can begin until the entire group of qtrees is transferred and the data is captured and made visible in a Snapshot copy.
Because SnapVault backup schedules are set on a volume basis, you should aggregate SnapVault qtrees into different volumes, grouped by the desired backup policy and schedule. NetApp recommends that you do not group qtrees with slow data change rates or fast update cycles in the same volume as qtrees with high data change rates or slow update cycles. The reason is that all the SnapVault qtrees in the volume are able to update only as frequently as the qtree that takes the longest amount of time to update.
With the advent of open-systems SnapVault primaries, SnapVault is often used to back up remote offices over the WAN. When the amount of data change spikes, these long-distance updates can take considerably longer to finish, and this condition prevents multiple updates to other qtrees in the volume during that time. To avoid having long-running transfers block updates to other SnapVault secondary qtrees, do not group SnapVault secondary qtrees with vastly different average transfer lengths into the same secondary volume.
Data files for each file group can be located on different LUNs. These LUNs should be located in the same qtree rather than each LUN located in its own qtree. This way, only a single SnapVault relationship needs to be configured for the database as a whole. Configuring each LUN in its own qtree is not recommended because it would necessitate one SnapVault relationship for each qtree. For example, if one SnapVault relationship is unsynchronized or fails for any reason, then the database cannot be restored. SnapManager for SQL Server does not support backup or restore at the file group level.
Have the following documents available for reference:
Refer to this document for the following information:
Refer to this document for the following information:
The procedure for automatically archiving SnapManager backups using SnapVault consists of a sequence of tasks described in the paragraphs that follow:
The descriptions of these tasks are based on an example scenario in which there are two SQL Server computers sharing the same primary storage. A simple database layout is assumed, where the database and associated log files reside on the same LUN.
The primary storage system is named filer_pri, and it contains two storage volumes, Srv1 and Srv2. These storage volumes in turn contain qtrees named db1 and db2, respectively.
The secondary storage system is named filer_sec, and it contains a single storage volume, sv_SQL.
During the SnapVault update, the two qtrees in the primary storage volumes will be coalesced on the secondary storage volume.
Use SnapDrive to create the LUNs in qtrees (rather than directly in the root of the volume) on the primary storage system. You only need to create the qtrees on the primary storage system. Later, when you initialize the SnapVault backup relationship, SnapVault automatically creates the qtrees on the secondary storage system.
Because a single volume on the secondary storage can be the secondary storage for several primary storage systems, the root of the volume on the secondary storage will contain the replicated qtrees from all of the primary storage sources that are configured to use it. When planning the disk configuration of the secondary storage device, minimize any confusion by assigning qtree names that are both descriptive and unique.
Consider using qtree names with the following naming conventions:
Examples:
sql_srvr_db1
sql_srvr_db2
sql_srvr_db3_and_4.
Examples:
sql_srvr_instance2_db5
sql_srvr_instance2_db6_and_7
Examples:
sql_srvr1_snapinfo
sq2_srvr1_snapinfo
Because a SnapVault restore operation restores the entire qtree, it causes any other data that might be on the primary storage system qtree to be overwritten with the data from the SnapVault secondary storage system. For example, if multiple databases share the same LUN, a SnapVault recovery restores both databases.
The same is true if multiple databases are located on their own individual LUNs and share the same qtree. The SnapInfo directory should be on its own LUN, and this LUN should be in its own qtree.
To perform a restore from archive using SnapManager for SQL Server, you need a backup set created by SnapManager. In the context of SnapVault, this means the following:
sqlsnap__SQLServerName_dd-mm-yyyy_hh.mm.ss
Example:
sqlsnap__sqlsrvr1_11-29-2004_03.16.32
sqlsnap__SQLServerName_dd-mm-yyyy_hh.mm.ss
Example:
sqlsnap__sqlsrvr1_11-29-2004_03.16.32
sqlinfo__SQLServerName_dd-mm-yyyy_hh.mm.ss
Example:
sqlinfo__sqlsrvr1_11-29-2004_03.16.32
Note
Because this is a restore-from-archive operation, it is a point-in-time restore.
After the qtrees and LUNs have been created on the primary storage system, you can configure SnapVault, as follows:
To configure SnapVault, complete the following steps.
| 1 |
Designate one storage system as the SnapVault primary storage and one as the secondary storage, then license each system accordingly using the following filer command: license add [ sv_ontap_pri | sv_ontap_sec ] = LicenseKey Example command on the primary storage system: filer_pri> license add sv_ontap_pri=1234567 Example command on the secondary storage system: filer_sec> license add sv_ontap_sec=2345678 |
|
| 2 |
Enable SnapVault on both storage systems by using the following filer command: Example command on the primary storage system: filer_pri> options snapvault.enable on Example command on the secondary storage system: filer_sec> options snapvault.enable on |
|
| 3 |
Configure access between the two storage systems by using the following filer command: options snapvault.access host=SnapVaultFilerName Example command on the primary storage system: filer_pri> options snapvault.access host=filer_sec Example command on the secondary storage system: filer_sec> options snapvault.access host=filer_pri |
|
| 4 |
Designate a volume on the secondary storage system as the destination for the transfers. If necessary, create a new volume by using the storage system's command-line or FilerView. |
|
|
Initialize the SnapVault relationship and perform a baseline data transfer |
||
| 5 |
This entails the following two tasks:
Both of the preceding tasks are accomplished using the following filer command: snapvault start [-k kbs] [-t n] -S PrimaryFilerName:PrimaryQtreePath [sec_host:] /vol/SecondaryVolumeName/SecondaryQtreePath For a complete description of the command syntax, see the SnapVault section in the Data ONTAP Data Protection Guide. The following commands exemplify the commands that you would use to initialize the SnapVault relationship in the configuration example: snapvault start -S filer_pri:/vol/Srvr1/db1 filer_sec:/vol/sv_SQL/Srvr1_db1 snapvault start -S filer_pri:/vol/Srvr2/db1 filer_sec:/vol/sv_SQL/Srvr2_db1 snapvault start -S filer_pri:/vol/Srvr1/SnapInfo filer_sec:/vol/sv_SQL/Srvr1_snapinfo snapvault start -S filer_pri:/vol/Srvr2/SnapInfo filer_sec:/vol/sv_SQL/Srvr2_snapinfo |
|
| 6 |
Create the SnapVault retention policy by issuing the following filer command at the storage system console: snapvault snap sched volume_name snap_name schedule_spec For a complete description of the command syntax, see the SnapVault section in the Data ONTAP Data Protection Guide. The following sample commands direct SnapVault to create a retention policy for two different SQL databases that are located on different servers and configured to use the same secondary storage volume named sv_SQL: snapvault snap sched sv_SQL sqlsnap_srvr1 6@- snapvault snap sched sv_SQL sqlsnap_srvr2 8@- Note that the prefix for the first server is sqlsnap_srvr1 and the retention level is six Snapshot copies. The prefix for the second server is sqlsnap_srvr2 and the retention level is eight Snapshot copies. Specify Snapshot copy names with all lowercase letters. SnapDrive creates Snapshot copy names using lowercase letters and requires that any Snapshot copy you connect to also be in lowercase. If the Snapshot copy name in the retention policy is created with mixed or uppercase letters, SnapDrive will not be able to mount the LUN in this Snapshot copy. Specify archive schedules as shown in the preceding example. The @- indicates that this is a retention policy rather than a schedule of Snapshot copies. The SnapVault updates are driven by SnapManager rather than by the SnapVault Snapshot copy update schedule. Attention |
|
The result is a set of Snapshot copies named as follows, with the newest Snapshot copy having the lowest-numbered suffix:
sqlsnap_srvr1.0 <newest>
sqlsnap_srvr1.1
sqlsnap_srvr1.2
sqlsnap_srvr1.3
sqlsnap_srvr1.4
sqlsnap_srvr1.5 <oldest>
sqlsnap_srvr2.0 <newest>
sqlsnap_srvr2.1
sqlsnap_srvr2.2
sqlsnap_srvr2.3
sqlsnap_srvr2.4
sqlsnap_srvr2.5
sqlsnap_srvr2.6
sqlsnap_srvr2.7 <oldest>
After the SnapVault relationship is configured and a retention policy defined, you can use SnapManager to trigger SnapVault updates. You can configure SnapManager to run a command or script after a backup and then pass it variables that correspond to the required Snapshot copy names described previously.
To use SnapManager to trigger updates to the secondary storage, complete the following steps.
| 1 |
Create a script that requests SnapVault updates be made to the secondary storage system. The following sample script requests SnapVault updates for the qtrees in volume sv_SQL on the secondary storage and then requests an archival Snapshot copy for the retention policy you set up. In this case, sqlsnap_srvr1 is the Snapshot copy name prefix corresponding to the retention policy. REM Begin sample script REM Update SnapVault secondary using $SqlSnapshot rsh filer_sec snapvault update -s %1 filer_sec:/vol/sv_SQL/Srvr1_db1 REM Update SnapVault secondary using $InfoSnapshot rsh filer_sec snapvault update -s %2 filer_sec:/vol/sv_SQL/Srvr1_snapinfo REM Create snapshot to archive the above transfers rsh filer_sec snapvault snap create sv_SQL sqlsnap_srvr1 REM End sample script This example shows the complete command-line syntax is shown, but you can simplify the command by omitting the secondary filer's name ("filer_sec:") from the secondary qtree path. SnapVault queues up the transfers and subsequent archival Snapshot copy so that the script finishes quickly, even though the transfer might not finish right away. The sample script assumes that the database and log files reside in the same qtree (whether on the same LUN or different LUNs in the same qtree). Note |
|
| 2 |
If the script is located on a UNC path (a network share) and if SnapManager is running on Windows Server 2003, then be aware of the following limitation: With Windows Server 2003, Enhanced Internet Explorer Security Configuration is enabled by default, preventing SnapManager from running scripts located at a UNC path. If the script is located on a UNC path and SnapManager is running on a Windows Server 2003 system on which Enhanced Internet Explorer Security Configuration is enabled, then SnapManager can run the script only if you add the network location to Internet Explorer's list of trusted sites. For details, see Running a script from a UNC path on a Windows Server 2003 system. |
|
|
Configure SnapManager to create uniquely named backup Snapshot copies |
||
| 3 |
Configure SnapManager to use a unique Snapshot copy name rather than the generic "_recent" name. This causes all database backup Snapshot copy names--even for the most recent backup--to contain the Snapshot copy creation date and time. To do this, use the Backup Settings dialog box and select Use Unique in the "Select a backup naming convention..." panel. For details, see Configuring the profile of a full database backup. |
|
|
Start or schedule a SnapManager full database backup and verification operation that also launches the SnapVault update script |
||
| 4 |
Start or schedule a full database backup, being sure to select the Run Command After Operation option. ResultWhen you start or schedule the backup operation, the Run Command After Operation dialog box appears. |
|
| 5 |
In the Run Command After Operation dialog box, specify the following information:
For details, see Using the Run Command After Operation feature. Note |
|
| 6 |
Understand and use the following commands on the storage system to monitor the SnapVault status: snapvault status snap list -q snap list -o These commands are documented in the SnapVault section of the Data ONTAP Data Protection Guide. |
|
Copyright © 1994-2006, Network Appliance, Inc. All rights
reserved.
Part No. 215-01752_A0
File: archbkp6.htm
Last updated: 01-Sep-2006 07:41:22