SnapCenter Software 1.0

Transcription

1 SnapCenter Software 1.0 Operations Guide For SnapCenter Plug-in 1.0 for Microsoft SQL Server NetApp, Inc. 495 East Java Drive Sunnyvale, CA U.S. Telephone: +1 (408) Fax: +1 (408) Support telephone: +1 (888) Web: Feedback: Part number: _C0 December 2015

2

3 Table of Contents 3 Contents SnapCenter Plug-in for Microsoft SQL Server overview... 5 What you can do with the SnapCenter Plug-in for Microsoft SQL Server... 5 SnapCenter Plug-in for Microsoft SQL Server features... 5 SnapCenter overview... 6 SnapCenter components... 6 Resources, datasets, and policies... 8 Types of role-based access control in SnapCenter... 9 SnapCenter Plug-in for Microsoft SQL Server data protection workflow Preparing for data protection Prerequisites for using SnapCenter Plug-in for Microsoft SQL Server Defining a data protection strategy Type of backup needed When to back up your databases Number of backup jobs needed Which backup naming convention to use When to schedule verification jobs Backup copy verification using the primary or secondary storage volume How to retain backup copies on the source storage system and the SnapMirror destination How long to retain transaction log backups on the source storage system Use of SnapMirror and SnapVault technology Logging in to SnapCenter Backing up resources Determining whether resources are available for backup using the Inventory page Creating backup policies Creating backup datasets and attaching policies Backing up resources on demand Types of on-demand backup operations Backing up datasets on demand Monitoring backup operations on the Jobs page Verifying backups Configuring your verification server Assigning a verification server to backup datasets Creating verification policies Verifying backups on demand Scheduling backup verification Monitoring verification operations on the Jobs page Restoring databases... 37

4 4 Operations Guide for SnapCenter Plug-in for Microsoft SQL Server Preparing to restore a database Sources and destinations for a restore operation Requirements for restoring a database SQL Server recovery models supported by SnapCenter Plug-in for Microsoft SQL Server Types of restore operations Restoring SQL Server databases Restoring a database to an up-to-the-minute backup Restoring a database to a previous point-in-time Restoring a database from secondary storage Restoring a database to an alternate path Restoring Availability Group databases Monitoring restore operations on the Jobs page Cloning database resources How a clone operation works Types of clone operations Creating clone policies Creating clone datasets Cloning from a SQL Server database backup Clone lifecycle Monitoring clone operations on the Jobs page Where to go next Copyright information Trademark information How to send comments about documentation and receive update notifications Index... 63

5 5 SnapCenter Plug-in for Microsoft SQL Server overview The SnapCenter Plug-in for Microsoft SQL Server is a host-side component of the NetApp SnapCenter Software that enables application-aware data protection management of Microsoft SQL Server databases. The Plug-in for SQL Server automates SQL Server database backup, verify, restore, and cloning operations in your SnapCenter environment. When the Plug-in for SQL Server is installed, you can use SnapCenter with NetApp SnapMirror technology to create mirror copies of backup sets on another volume and with NetApp SnapVault technology to perform disk-to-disk backup replication for standards compliance. For details, see SnapCenter Software installation instructions and getting started information. Related information SnapCenter Software 1.0 Installation and Setup Guide SnapCenter Software 1.0 Getting Started Guide What you can do with the SnapCenter Plug-in for Microsoft SQL Server When the SnapCenter Plug-in for Microsoft SQL Server is installed in your environment, you can use SnapCenter to back up, restore, and clone SQL Server databases and their resources. You can also perform tasks supporting those operations. Back up SQL Server databases and associated transaction logs Restore database resources, including databases, instances, or Availability Groups Create point-in-time clones of production databases Verify backup operations immediately or defer verification until later Schedule backup and clone operations Monitor backup, restore, and clone operations Note: The Plug-in for SQL Server does not support backup and recovery of SQL Server databases on SMB shares. SnapCenter Plug-in for Microsoft SQL Server features The Plug-in for SQL Server integrates with Microsoft SQL Server on the Windows host and with NetApp Snapshot copy technology on the storage system. To work with the Plug-in for SQL Server, you use the SnapCenter interface. The Plug-in for SQL Server includes these major features: Unified product user interface powered by SnapCenter The SnapCenter interface provides you with standardization and consistency across plugins and environments. The SnapCenter interface enables you to complete consistent backup and restore processes across plug-ins, use centralized reporting, use at-a-glance dashboard views, set up role-based access control (RBAC), and monitor jobs across all

6 6 Operations Guide for SnapCenter Plug-in for Microsoft SQL Server plug-ins. SnapCenter also offers centralized scheduling and policy management to support backup and clone operations. Automated central administration You can schedule routine SQL Server database backups, configure policy-based backup retention, and set up point-in-time and up-to-the-minute restore operations. You can also proactively monitor your SQL Server environment with periodic alerts. Nondisruptive NetApp Snapshot copy technology The Plug-in for SQL Server uses NetApp Snapshot copy technology with the NetApp SnapCenter Plug-in for Microsoft Windows. This enables you to back up databases in seconds and restore them quickly without taking SQL offline. Snapshot copies consume minimal storage space. Integration with the Microsoft Volume Shadow Copy Service (VSS) The integration with VSS ensures that write requests are frozen and write caches are flushed before you make backup copies. In addition to these major features, the Plug-in for SQL Server offers the following benefits: Backup, restore, clone, and verification workflow support RBAC-supported security and centralized role delegation Creation of space-efficient, point-in-time copies of production databases for testing or data extraction by using NetApp FlexClone technology A FlexClone license is required on the storage system holding the clone. Nondisruptive and automated backup verification Ability to run multiple backups at the same time across multiple servers PowerShell cmdlets for scripting of backup, verify, restore, and clone operations Support for AlwaysOn Availability Groups (AGs) in SQL Server to accelerate AG setup, backup, and restore operations In-memory database and Buffer Pool Extension (BPE) as part of SQL Server 2014 Support for backup of LUNs and VMDKs Support for physical and virtualized infrastructures Support for iscsi, Fibre Channel, FCoE, RDM, and VMDK over NFS and VMFS Support for standalone instances of SQL Express for all operations except migration SnapCenter overview SnapCenter is a unified, scalable platform for application-consistent data protection. SnapCenter provides centralized control and oversight, while delegating the ability for users to manage application-specific backup, restore, and clone jobs. SnapCenter also provides you with a single user interface, seamless scalability, high availability, and load balancing. SnapCenter components SnapCenter consists of the SnapCenter Server, the SnapCenter Plug-in for Microsoft SQL Server, and the SnapCenter Plug-in for Microsoft Windows. SnapCenter interacts with Virtual Storage Console for VMware vsphere to provide support for database backup and recovery on RDMs and

7 SnapCenter Plug-in for Microsoft SQL Server overview 7 VMDKs. When you are installing and configuring SnapCenter, it is helpful to understand its components. SnapCenter Server SnapCenter Server includes a web server, a centralized HTML5-based user interface, and the SnapCenter database. SnapCenter enables load balancing, high availability, and horizontal scaling across multiple SnapCenter Servers within a single user interface. You might need multiple SnapCenter Servers for high availability. For larger environments with thousands of SQL hosts or another type of plug-in host, adding multiple SnapCenter Servers can help balance the load. The SnapCenter platform is based on a multi-tiered architecture, including a centralized management server (SnapCenter Server), which manages different SnapCenter Agents known as SMCore. These agents communicate with SnapCenter application plug-ins installed on physical or virtual hosts. SnapCenter also enables centralized application resource management and easy data protection job execution through the use of datasets and policy management (including scheduling and retention settings). SnapCenter provides unified reporting through the use of a Dashboard, multiple reporting options, job monitoring tools, and log and event viewers. SnapCenter data protection capabilities can be delegated to application administrators using granular role-based access control (RBAC). SnapCenter Plug-in for Microsoft SQL Server The Plug-in for SQL Server is a host-side component of the NetApp integrated storage solution offering application-aware backup management of Microsoft SQL Server databases. With the Plug-in

8 8 Operations Guide for SnapCenter Plug-in for Microsoft SQL Server for SQL Server installed in your environment, SnapCenter automates Microsoft SQL Server database backup, restore, and cloning operations. SnapCenter Plug-in for Microsoft Windows The Plug-in for Windows provides storage provisioning for the host, Snapshot copy consistency, and space reclamation. With the plug-in installed in your environment, you can use SnapCenter to create and resize disks, initiate iscsi sessions, manage igroups, and manage SMB shares. The Plug-in for Windows is a required component of the Plug-in for SQL Server workflows. Support is provided for provisioning SMB shares only. You cannot use SnapCenter to back up databases on SMB shares. VSC for VMware vsphere Virtual Storage Console for VMware vsphere enables SnapCenter to communicate with VMware vsphere when SnapCenter performs backup and restore operations for SQL databases on VMDKs or RDMs. In addition, VSC uses SnapCenter to perform backup and restore operations for storage systems running clustered Data ONTAP or later. You must register VSC with SnapCenter, using either the SnapCenter Add Hosts wizard or the VSC Configure SnapCenter Server dialog box. Note: You do not need to register VSC with SnapCenter if your SQL environment uses an iscsi initiator. VSC is a vcenter Server plug-in that provides end-to-end lifecycle management for virtual machines in VMware environments using NetApp storage systems. Resources, datasets, and policies Before you begin using SnapCenter, it is helpful to understand some basic concepts related to the backup, clone, and restore operations you want to perform. You interact with resources, datasets, and policies in every backup and clone operation that you perform. Resources are typically databases but can include anything you back up or clone with a SnapCenter plug-in, including instances and Availability Groups. A SnapCenter dataset is a collection of related resources on a host or Windows cluster. When you back up or clone a dataset in SnapCenter, you back up or clone the resources defined in the dataset. The policies attached to a dataset specify the schedule, copy retention, and other characteristics of backup, clone, or verification jobs associated with the dataset. You select the policy when you perform the operation. Think of a dataset as defining what you want to protect and a policy as defining how you want to protect it. If you are backing up an SQL Server instance, for example, you might create a dataset that includes all of the databases in the instance. You could then attach two policies to the dataset, one that performs a full backup daily and another that performs transaction log backups hourly. The following image illustrates the relationship between resources, datasets, and policies:

9 SnapCenter Plug-in for Microsoft SQL Server overview 9 Types of role-based access control in SnapCenter SnapCenter role-based access control (RBAC) enables the SnapCenter administrator to create roles and set access permissions. This centrally managed access empowers application administrators to work securely within delegated environments. Configuring SnapCenter RBAC is a simple process, but it is important to understand the RBAC components and configure them correctly to ensure that all users are able to access SnapCenter and the plug-ins. SnapCenter uses the following types of role-based access control: SnapCenter RBAC Application-level RBAC Clustered Data ONTAP permissions SnapCenter RBAC Roles and permissions SnapCenter ships with several predefined roles with permissions already assigned. You can add users or groups of users to these existing roles. You can also create new roles and manage permissions and users. You can grant permissions to both roles and resources. You cannot change permissions of the SnapCenterAdmin role. Authentication Users are required to provide authentication during login, through the user interface or using PowerShell cmdlets. If users are members of more than one role, after entering login credentials, they are prompted to specify the role they want to use. Application-level RBAC SnapCenter uses Run As account credentials to ensure that authorized SnapCenter users also have application-level permissions. For example, if you want to perform Snapshot copy and data protection jobs in a SQL Server environment, you must set your Run As account with the proper Windows or SQL credentials. The SnapCenter Server authenticates the credentials set using either method. Clustered Data ONTAP permissions You should ensure that you have vsadmin account permissions.

10 10 SnapCenter Plug-in for Microsoft SQL Server data protection workflow Before you can use SnapCenter to protect Microsoft SQL Server databases, your SnapCenter Server administrator must have installed and configured the Plug-in for SQL Server. Related references Backing up resources on page 18 Verifying backups on page 29 Restoring databases on page 37 Cloning database resources on page 50 Related information SnapCenter Software 1.0 Installation and Setup Guide

11 11 Preparing for data protection Before performing any data protection such as backup, clone, or restore operations, you must define your strategy and set up the environment. You can also set up the SnapCenter Server to use SnapMirror and SnapVault technology. If you want to take advantage of SnapVault and SnapMirror technology, you must configure a data-protection relationship between the source and destination volumes and initialize the relationship. Steps 1. Prerequisites for using SnapCenter Plug-in for Microsoft SQL Server on page 11 Before you begin to use the Plug-in for SQL Server, the SnapCenter administrator must install and configure SnapCenter Server and perform prerequisite tasks. 2. Defining a data protection strategy on page 12 Defining a data protection strategy before you create your backup jobs helps ensure that you have the backups that you need to successfully restore or clone your databases. Your Service Level Agreement (SLA) Recovery Time Objective (RTO), and Recovery Point Objective (RPO) largely determine your backup strategy. Prerequisites for using SnapCenter Plug-in for Microsoft SQL Server Before you begin to use the Plug-in for SQL Server, the SnapCenter administrator must install and configure SnapCenter Server and perform prerequisite tasks. Install and configure SnapCenter Server. Log in to SnapCenter. Configure the SnapCenter environment by adding SVM connections and creating a Run As account, which is needed for scheduling jobs. Add hosts, install the plug-ins, discover (refresh) the resources, and configure the plug-ins. If SQL is not installed yet, you must refresh resources again after you complete the provisioning steps. If you are using SnapCenter Server to protect SQL databases that reside on VMware RDM LUNs or VMDKs, you must register Virtual Storage Console with SnapCenter Server. This registration occurs in the VSC interface, and it enables SnapCenter Server to communicate with VMware vsphere. Perform host-side storage provisioning using the SnapCenter Plug-in for Microsoft Windows. Move existing databases into NetApp storage. For details, see SnapCenter migration information. Set up SnapMirror and SnapVault, if you want backup replication. For details, see SnapCenter installation information. Related information SnapCenter Software 1.0 Installation and Setup Guide SnapCenter Software 1.0 Migration Guide for SnapManager Backup Jobs

12 12 Operations Guide for SnapCenter Plug-in for Microsoft SQL Server Defining a data protection strategy Defining a data protection strategy before you create your backup jobs helps ensure that you have the backups that you need to successfully restore or clone your databases. Your Service Level Agreement (SLA) Recovery Time Objective (RTO), and Recovery Point Objective (RPO) largely determine your backup strategy. About this task An SLA defines the level of service expected and addresses many service-related issues, including the availability and performance of service. The RTO is the time by which a business process must be restored after a disruption in service. An RPO defines the strategy for the age of the files that must be recovered from backup storage for regular operations to resume after a failure. The SLA, RTO, and RPO contribute to the data protection strategy. Steps 1. Decide the type of backup you need. 2. Determine when you should back up your databases. 3. Decide how many backup jobs you need. 4. Decide how to name your backups. 5. Determine when you should verify copies. 6. Decide whether you want to verify backup copies using the source volume or a destination volume. 7. Determine how long you want to retain backup copies on the source storage system and the SnapMirror destination. 8. Determine how long you want to retain transaction log backups on the source storage system. 9. Decide whether you want to use NetApp SnapMirror disaster recovery or SnapVault archiving technology in conjunction with the SnapCenter Plug-in for Microsoft SQL Server. Related concepts Type of backup needed on page 13 When to back up your databases on page 13 Number of backup jobs needed on page 14 Which backup naming convention to use on page 14 When to schedule verification jobs on page 14 Backup copy verification using the primary or secondary storage volume on page 15 How to retain backup copies on the source storage system and the SnapMirror destination on page 15 How long to retain transaction log backups on the source storage system on page 15 Related references Use of SnapMirror and SnapVault technology on page 15

13 Preparing for data protection 13 Type of backup needed Backing up SQL Server databases using SnapCenter requires that you choose the resource type, such as databases, SQL server instances, and Availability Groups (AG). Snapshot copy technology is leveraged to create online, read-only copies of the volumes on which the resources reside. You can select the copy-only option to specify that SQL Server does not truncate transaction logs. You should use this option when you are also managing the SQL Server with other backup applications. Keeping transaction logs intact enables any backup application to restore the databases. Copy-only backups are independent of the sequence of scheduled backups and do not affect the backup and restore procedures of the database. Backup type Description Copy-only option with backup type Full backup and log backup Full database backup Transaction log backup Backs up the database and truncates the transaction logs. SQL Server truncates transaction logs by removing entries already committed to the database. After the full backup is complete, this option creates a transaction log that captures transaction information. Typically, you should choose this option. However, if your backup time is short you might not want to run transaction log backup with full backup. Backs up database files. Backs up truncated transaction logs, copying only transactions committed since the most recent transaction log. If you schedule frequent transaction log backups alongside full database backups, you can choose granular recovery points. Backs up database files and transaction logs without truncating the logs. A copy-only backup cannot serve as a differential base or differential backup, and does not affect the differential base. Restoring a copyonly full backup is the same as restoring any other full backup. Backs up database files. Backs up only transaction logs without truncating them. This type does not affect the sequencing of regular log backups. Copy-only log backups are useful for performing online restore operations. When to back up your databases The most critical factor in determining a database backup schedule is the rate of change for the database. The more often you back up your databases, the fewer transaction logs SnapCenter has to use at restore time, which can result in faster restore operations. You might back up a heavily used database every hour, while you might back up a rarely used database once a day. Other factors include the importance of the database to your organization, your Service Level Agreement (SLA), and your Recover Point Objective (RPO). An SLA defines the level of service expected and addresses many service-related issues, including the availability and performance of service. An RPO defines the strategy for the age of the files that must be recovered from backup storage for regular operations to resume after a failure. The SLA and RPO contribute to the data protection strategy. Even for a heavily used database, there is no requirement to run a full backup more than once or twice a day. Regular transaction log backups might be sufficient to ensure that you have the backups you need.

14 14 Operations Guide for SnapCenter Plug-in for Microsoft SQL Server Related tasks Creating backup policies on page 20 Number of backup jobs needed Factors that determine the number of backup jobs that you need include the size of the database, the number of volumes used, the rate of change of the database, and your Service Level Agreement (SLA). The number of backup jobs that you choose typically depends on the number of volumes on which you placed your databases. For example, if you placed a group of small databases on one volume and a large database on another volume, you might create one backup job for the small databases and one backup job for the large database. Which backup naming convention to use You can use the default Snapshot copy naming convention or use a custom name format. The default backup naming convention adds a timestamp to Snapshot copy names that helps you identify when the copies were created. The Snapshot copy uses the following default naming convention: datasetname_hostname_timestamp. You should name your backup datasets logically, as in the following example: dts1_mach1x88_ _ In this example, the syntax elements have the following meanings: dts1 is the dataset name. mach1x88 is the machine name _ is the date and timestamp. Alternatively, you can specify the Snapshot copy name format, while creating backup or clone datasets by selecting Use custom name format, for example, customtext_dataset_policy_hostname or dataset_hostname. By default, the time stamp suffix is added to the Snapshot copy name. Related tasks Creating backup policies on page 20 When to schedule verification jobs Although SnapCenter can verify backups immediately after it creates them, doing so can significantly increase the time required to complete the backup job and is resource intensive. Hence, it is almost always best to schedule verification in a separate job for a later time. For example, if you back up a database at 5:00 p.m. every day, you might schedule verification to occur an hour later at 6:00 p.m. For the same reason, it is usually not necessary to run backup verification every time you perform a backup. Performing verification at regular but less frequent intervals is usually sufficient to ensure the integrity of the backup. A single verification job can verify multiple backups at the same time. Related tasks Creating verification policies on page 31 Related references Verifying backups on page 29

15 Preparing for data protection 15 Backup copy verification using the primary or secondary storage volume You can verify backup copies on the primary storage volume or on either the SnapMirror or SnapVault secondary storage volume. Verification using a secondary storage volume reduces load on the primary storage volume. When you verify on the primary or secondary storage volume, both the primary and the secondary Snapshot copies are marked as verified. SnapRestore license is required to verify backup copies on SnapMirror and SnapVault secondary storage volume. Related tasks Creating verification policies on page 31 How to retain backup copies on the source storage system and the SnapMirror destination You can choose either the number of days to retain backup copies or specify the number of backup copies you want to retain, up to 255. For example, your organization might require that you retain 10 days of backup copies. If you set up SnapMirror replication, the retention policy is mirrored on the destination volume. Note: For long-term retention of backup copies, you should use SnapVault. How long to retain transaction log backups on the source storage system SnapCenter Plug-in for Microsoft SQL Server needs transaction log backups to perform up-to-theminute restore operations, which restore your database to a time between two full backups. For example, if Plug-in for SQL Server took a full backup at 8:00 a.m. and another full backup at 5:00 p.m, it could use the latest transaction log backup to restore the database to any time between 8:00 a.m. and 5:00 p.m. If transaction logs are not available, Plug-in for SQL Server can perform point-in-time restore operations only, which restore a database to the time that Plug-in for SQL Server completed a full backup. Typically, you require up-to-the-minute restore operations for only a day or two, which means you would retain transaction log backups for one or two days. Use of SnapMirror and SnapVault technology With the SnapCenter Plug-in for Microsoft SQL Server, you can use SnapMirror to create mirror copies of backups on another volume. You can use it with SnapVault technology to perform disk-todisk backup replication for standard compliance. Before you can perform these tasks in SnapCenter, you must configure a data-protection relationship between the source and destination volumes and initialize the relationship. Subsequently, when you are preparing a backup, you set up a policy in which you can choose to use the SnapMirror and SnapVault technology. For details about preparing storage systems for SnapMirror and SnapVault replication, see SnapCenter installation instructions. Related tasks Creating backup policies on page 20

16 16 Operations Guide for SnapCenter Plug-in for Microsoft SQL Server Related information SnapCenter Software 1.0 Installation and Setup Guide

17 17 Logging in to SnapCenter When you log in to the SnapCenter user interface, you log in as a specific user role, depending on the tasks you want to perform. About this task The SnapCenter user interface URL is configured based on information you provide during installation. It is useful to know where to find it after you complete the SnapCenter installation. During the installation, the SnapCenter Server Install wizard creates a shortcut and places it on your local host desktop. Additionally, at the end of the installation, the Install wizard provides the SnapCenter URL. You can copy this URL in case the shortcut does not work or if you want to log in from a remote system. The default user interface URL is a secure connection to port 8146 on the server where the SnapCenter Server is installed ( If you provided a different server port during the SnapCenter installation, that port is used instead. For Network Load Balance (NLB) deployment, you must access SnapCenter using the NLB cluster IP ( In addition to using the SnapCenter user interface, you can use PowerShell cmdlets to script configuration, backup, restore, and clone operations. For details, use the SnapCenter cmdlet help or see the SnapCenter cmdlet reference information. Steps 1. Launch SnapCenter either from the shortcut located on your local host desktop, from the URL provided at the end of the installation, or from the URL provided to you by your SnapCenter administrator. 2. Complete the following steps: If you want to... Log in as the SnapCenter administrator Log in as a SnapCenter user Do the following Enter the domain user with local administrator credentials provided during the SnapCenter installation. The first time you log in to SnapCenter, you must log in as an administrator. Enter your user credentials: Domain\UserName 3. If you are assigned more than one role, from the Role box, select the role you want to use for this log in session. You are logged in to SnapCenter. Related information SnapCenter Software 1.0 Cmdlet Reference Guide

18 18 Backing up resources When you install the SnapCenter Plug-in for Microsoft SQL Server in your environment, you can use SnapCenter to back up SQL Server resources. You can schedule multiple backups to run at the same time across servers. Backup and restore operations cannot be performed simultaneously on the same resource. The following workflow shows the sequence in which you must perform different operations: How SnapCenter backs up databases SnapCenter uses Snapshot copy technology to back up SQL Server databases that reside on LUNs or VMDKs. With this method, SnapCenter creates the backup by creating Snapshot copies of the databases. When you select a database for a full database backup from the Datasets page, SnapCenter automatically selects all other databases that reside on the same storage volume. If the LUN or VMDK stores only a single database, you can clear or reselect that database individually. If the LUN or VMDK houses multiple databases, you must clear or reselect those databases as a group. All of the databases that reside on a single volume are backed up concurrently using Snapshot copies. If the maximum number of concurrent backup databases is 35 and if more than 35 databases reside in that storage volume, then the total number of Snapshot copies created equals the number of databases divided by 35. Note: You can configure the maximum number of databases for each Snapshot copy in the backup policy. When SnapCenter creates a Snapshot copy, the entire storage system volume is captured in that Snapshot copy; however, that backup is valid only for the SQL host server for which the backup was created.

19 Backing up resources 19 If data from other SQL host servers resides on the same volume, that data is not restorable from the Snapshot copy. Related tasks Logging in to SnapCenter on page 17 Defining a data protection strategy on page 12 Defining a data protection strategy before you create your backup jobs helps ensure that you have the backups that you need to successfully restore or clone your databases. Your Service Level Agreement (SLA) Recovery Time Objective (RTO), and Recovery Point Objective (RPO) largely determine your backup strategy. Determining whether resources are available for backup using the Inventory page Resources are the databases, application instances, Availability Groups, and similar components that are maintained by the plug-ins you have installed. You can add those resources to datasets so that you can perform data protection jobs, but first you must identify which resources you have available. Determining available resources also verifies that the plug-in installation has completed successfully. Before you begin You must have already completed tasks such as installing SnapCenter Server, adding hosts, creating SVM connections and adding Run As credentials. If databases reside on VMDK, you must configure Virtual Storage Console (VSC) with SnapCenter Server information. Steps 1. In the left navigation pane, click Inventory. 2. On the Resources page, select the host, resource type, and SQL Server instance to filter the list of resources. 3. Click Refresh Resources. Note: Newly added or deleted SQL server databases are updated to the SnapCenter Server inventory after you click Refresh Resources. You cannot back up the databases when the Selectable option in the Details page is set to false. The Selectable option is set to false when any of the following is true: Databases are not on a NetApp LUN. Databases are not in normal state. Databases are not in normal state when they are offline, restoring, recovery pending, suspect, and so on. Databases have insufficient privileges. For example, if a user has only view access to the database, files and properties of the database cannot be identified and hence cannot be backed up. Databases are provisioned on Asymmetric Logical Unit Access (ALUA) ALUA, also known as Target Port Groups Support (TPGS), is a set of SCSI concepts and commands that define path prioritization for SCSI devices.

20 20 Operations Guide for SnapCenter Plug-in for Microsoft SQL Server Creating backup policies Before you use SnapCenter to back up SQL Server resources, you must create a backup policy for the dataset you want to back up. A backup policy is a set of rules that governs how you manage, schedule, and retain backups. Additionally, you can specify replication, script, backup type, and availability group (AG) settings. Specifying options in a policy saves time when you want to reuse the policy on another dataset. Before you begin You must have already defined your data protection strategy. For additional information, see the information about defining a data protection strategy. You must have already prepared for data protection by completing tasks such as installing SnapCenter, adding hosts, identifying resources, and creating Storage Virtual Machine (SVM) connections. You must have configured the log directory in SVM for log backup. You must have refreshed (discovered) SQL Server resources. If you are replicating Snapshot copies to a mirror or vault, the SnapCenter administrator must have assigned you the Storage Virtual Machines (SVMs) for both the source and destination volumes. For information about how administrators assign resources to users, see SnapCenter installation information. About this task Most of the fields on these wizard pages are self-explanatory. The following information describes fields for which you might need guidance. Steps 1. On the left navigation pane, click Policies. 2. Click New > SQL Server Policy > Backup. 3. On the Name page, enter the policy name and a description. 4. On the Schedule page, define the schedule information. Choose either the SQL Server scheduler or the Windows scheduler. 5. On the Retention page, specify either the number of Snapshot copies to maintain before deleting them or the number of days to retain a backup copy before automatically deleting it. Important: You should set the retention count to 2 or higher if you plan to enable SnapVault replication. If you set the replication count to 1, the retention operation can fail because the first Snapshot copy is the reference Snapshot copy for the SnapVault relationship until the newer Snapshot copy is replicated to the target. 6. On the Replication page, specify replication to the secondary storage system: For this field Update SnapMirror after creating a local Snapshot copy Do this Select this to create mirror copies of backup sets on another volume (SnapMirror).

21 Backing up resources 21 For this field Update SnapVault after creating a Snapshot copy Secondary policy label Error retry count Do this Select this to perform disk-to-disk backup replication. Enter the frequency label for the secondary storage Snapshot copy. This label is attached to every Snapshot copy to identify it from the different groups on the secondary storage. For example, SnapmirrorLabel: weekly Enter the number of replication attempts that should occur before the process halts. 7. Optional: On the Script page, enter the path and the arguments of the prescript or postscript that should be run before or after the backup operation, respectively. For example, you can run a script to update SNMP traps, automate alerts, send logs, and so on. 8. On the Backup Type page, do the following to select the type of backup: a. Select whether you want to back up database files and transaction logs or just the transaction logs. See details about backup types and the copy-only option. b. If applicable, choose Copy-only backup. Use this option when you are backing up your resources with another backup application. Keeping transaction logs intact allows any backup application to restore the databases. You typically should not use copy-only in any other circumstance. 9. Click the Full backup or Log backup arrows to set additional backup options. 10. If you clicked the Full backup section on the Backup Type page, do the following:

22 22 Operations Guide for SnapCenter Plug-in for Microsoft SQL Server For this field Run verification after backup Do this a. Select this option to verify the backup immediately after the backup operation is performed. b. Choose the verification policy to be used for verification. Maximum databases per Snapshot copy Enter the maximum number of databases that should be backed up for each Snapshot copy. 11. If you clicked the Log backup section on the Backup Type page, do the following: a. Select the options in these fields: For this field Truncate committed transactions during log backup Verify log backup upon completion Do this Choose this to truncate the transactions that were committed during the backup. The transaction log must be truncated on a regular basis to keep it from filling up and running out of space. Choose this to verify the backup of the log immediately after the backup.

23 Backing up resources 23 b. Click the Log Folder Snapshot retention arrow and do the following: For this field Create Log Folder Snapshot copy for log backup Delete older Log Folder Snapshot copies Do this Choose this to create a Snapshot copy of the log folder every time a new log backup operation is performed. Choose this to retain only a specified number of Snapshot copies. If you near this limit, you might want to delete older copies. c. Click the Retain up-to-the-minute restore settings arrow and select one of the following: For this field Do not delete any log backups Most recent number of backups Backups generated in the last (days) Do this Select this if you do not want to delete the metadata for log backups in the central repository database. It is recommended not to select this option. Enter the number of full backups taken recently to retain up-tothe-minute. The older full backups prior to this number can be restored only to that point-in-time. Enter the number of days during which the full backups generated are to be retained up-to-the-minute. 12. On the AG Settings page, do the following: For this field Backup on preferred backup replica only Select replicas for backup Do this Choose this to back up only on the preferred backup replica. Preferred backup replica is decided by the backup preferences configured for the AG in the SQL Server. Choose the primary or secondary AG replica for the backup.

24 24 Operations Guide for SnapCenter Plug-in for Microsoft SQL Server For this field Backup priority (Minimum and maximum backup priority) Do this Enter a minimum and maximum backup priority number that decides the AG replicas for backup. For example, you can have a minimum priority of 10 and a maximum priority of 50, in which case all of the AG replicas having a priority of more than 10 and less than 50 are considered for backup. 13. Review the summary, and then click Finish. Related concepts Type of backup needed on page 13 Related tasks Defining a data protection strategy on page 12 Defining a data protection strategy before you create your backup jobs helps ensure that you have the backups that you need to successfully restore or clone your databases. Your Service Level Agreement (SLA) Recovery Time Objective (RTO), and Recovery Point Objective (RPO) largely determine your backup strategy. Related information SnapCenter Software 1.0 Administration Guide SnapCenter Software 1.0 Installation and Setup Guide Creating backup datasets and attaching policies Before you perform backups, you must create a SnapCenter Plug-in for Microsoft SQL Server backup dataset. A dataset is a set of virtual containers that you can configure as a unit for the purpose of group protection or group provisioning operations. You must also attach a backup policy to a backup dataset. A backup policy is a set of rules that governs how you manage, schedule, and retain backups. Steps 1. In the left navigation pane, click Datasets. 2. Click New > Backup Dataset. 3. On the Name page, do the following: For this field Name Policy Run as Scheduler Instance Do this Enter the dataset name. Do not include spaces. Select the policy that governs the backup settings, retention, and schedule. This option is available only when the selected policy has a schedule. Choose a database access account with which to connect to the SQL Server. The account must be a Windows user with access to the plugin host. This is required for scheduling backups. Choose a scheduler instance to associate with the scheduling policy. This is required for scheduling backups.

25 Backing up resources 25 For this field Use custom name format for Snapshot copy Do this (Optional) Enter a specific Snapshot copy name and format: for example, customtext_dataset_policy_hostname or dataset_hostname. By default, a timestamp is appended to the Snapshot copy name. 4. On the Resources page, select the host, resource type, and SQL Server instance by which to filter the list of resources. 5. Click the databases, instances, or Availability Groups you want to back up in the Available Resources section and click the right arrow to move them to the Selected Resources section. When you click a resource in the Available Resources section, all resources on the same volume are selected. When you move them to the Selected Resources section, all the resources on the same volume move together. To add just one resource, move all the resources on the volume into the Selected Resources section and then remove resources individually as needed from the Selected Resources section by clicking the left arrow. 6. On the Verification page, select the verification server for the SQL Server backup. You can select multiple verification servers. 7. On the Notification page, perform the following operations: For this field Log SnapCenter Server events to storage system syslog Send AutoSupport notification for failed operations to the storage system preference Do this Select to log SnapCenter Server events to the storage system's syslog. Select to send information about any failed operations using AutoSupport to technical support. Select Always, On Failure, or On failure or warning to send messages to recipients after any backups occur or are attempted. Enter the SMTP server, default subject line, and To and From addresses. 8. Review the summary, and then click Finish. After you finish Continue by performing the backup on demand or by waiting for the scheduled backup to occur. Related information SnapCenter Software 1.0 Administration Guide Backing up resources on demand After you create a backup policy and create a backup dataset, you can back up resources immediately rather than wait for a backup to occur as part of a scheduled backup. About this task You can create a back up on demand by choosing one of the following methods:

26 26 Operations Guide for SnapCenter Plug-in for Microsoft SQL Server Create an on-demand backup of a specific resource from the Inventory page. Create an on-demand backup of a dataset from the Datasets page. You might want to choose this method to back up multiple resources at one time. Related concepts Types of on-demand backup operations on page 26 Related tasks Backing up datasets on demand on page 26 Types of on-demand backup operations While it is a best practice to schedule your backup operations using a policy, you can perform backups on demand for immediate data protection. From the Dataset page, you can back up an entire dataset, or from the Inventory page, you can select a specific database resource to back up. On-demand backup type On-demand backup of a specific resource from the Inventory page On-demand backup of a dataset from the Datasets page Description Backs up an individual database resource. You might do this if you have resources that are not yet part of a dataset, to ensure that all of your resources are protected. A dataset is required to perform every backup job, even if you are backing up a resource using the Inventory page. When you click Backup Now, you are asked to create a dataset. Backup Now creates a new dataset, even if you are backing up the same resource for a single use. Backs up a dataset, which could include multiple database resources. You might do this if your regularly scheduled backups have failed and you want to ensure that your resources are protected. Backing up datasets on demand You can back up datasets containing multiple resources from the Datasets page or back up specific resources from the Inventory page immediately rather than waiting for a backup to occur per a schedule. By creating a backup copy of your data periodically, you can restore lost data. Before you begin You must have already defined your backup strategy. For details, see the information about defining your backup strategy. You must have already prepared for data protection by completing tasks such as adding hosts, identifying resources, and creating Storage Virtual Machine (SVM) connections. You must have created a policy. You must have created a dataset and attached a policy. Steps 1. In the left navigation pane, do one of the following: To back up an individual resource, click Inventory and select the resource you want to back up.

27 Backing up resources 27 To back up multiple resources, click Datasets and select the dataset. 2. Choose policy. 3. Click Backup Now. Note: The Backup Now, Restore, Manage Backups, and Clone options on the Inventory page are disabled if you select a non-netapp LUN, a database that is corrupted, or a database that is being restored. 4. On the Backup Now page, enter information and select options, and click Backup on the Datasets page or OK on the Inventory page. Related concepts Preparing for data protection on page 11 Related tasks Defining a data protection strategy on page 12 Defining a data protection strategy before you create your backup jobs helps ensure that you have the backups that you need to successfully restore or clone your databases. Your Service Level Agreement (SLA) Recovery Time Objective (RTO), and Recovery Point Objective (RPO) largely determine your backup strategy. Creating backup policies on page 20 Creating backup datasets and attaching policies on page 24 Monitoring backup operations on the Jobs page You can monitor the progress of different SnapCenter operations by using the Jobs page. You might want to check the progress of an operation to determine when it is complete or if there is an issue. This procedure describes how to monitor backup operations. About this task The following icons appear on the Jobs page and indicate the state of the operation: In progress Completed successfully Failed Completed with warnings Queued Verification job is queued Steps 1. From the left navigation pane, click Monitor. 2. From the top navigation bar, click Jobs. 3. Optional: On the Jobs page, filter the list so that only backup operations appear in the list by clicking Filter, selecting Backup from Type, and clicking.

28 28 Operations Guide for SnapCenter Plug-in for Microsoft SQL Server 4. Optional: To see the logs, select a backup copy from the list and click Details.

29 29 Verifying backups You can verify that a backup was successful either during or after a backup process. Verification also runs database integrity checks on backups. Verifying a backup requires that you perform a series of tasks by using SnapCenter. The following workflow shows the sequence in which you must perform verification operations: To verify backups, you use a verification server, which enables you to offload backup verification from a primary SQL Server host. Backup verification feature uses the Microsoft SQL Server Database Consistency Check (DBCC) to verify the page-level integrity of databases. Because verification is a CPU-intensive operation that can degrade SQL Server performance, it is a best practice to run the utility on a dedicated server separate from the production SQL server. The verification server must have iscsi or FC connectivity with the storage system. When a deferred verification operation is performed on an availability group (AG) dataset and the backup policy associated with the dataset has a setting to create backups on all replicas or some of the replicas, the number of backups to be verified is counted based on the backups created on all AG replicas or on some of the replicas and not based on individual AG replica. Backup verification might take longer when you have multiple databases on a single LUN. Related tasks Configuring your verification server on page 30 Assigning a verification server to backup datasets on page 30 Creating verification policies on page 31 Verifying backups on demand on page 33 Scheduling backup verification on page 34 Monitoring verification operations on the Jobs page on page 35

30 30 Operations Guide for SnapCenter Plug-in for Microsoft SQL Server Related information SnapCenter Software 1.0 Installation and Setup Guide Configuring your verification server You can use the plug-in configuration wizard to configure your verification server. You must do this before performing any verification jobs. Steps 1. From the left navigation pane, click Hosts. 2. From the Managed Hosts page, click Configure Plug-In. 3. From the Verification Server page of the Configure SQL Server Plug-in wizard, select the SQL Server instance you want to use as the verification server. Assigning a verification server to backup datasets To verify backups, you use a verification server, which enables you to offload backup verification from a primary SQL Server host. Before you perform backup verification, you must create a SnapCenter Plug-in for Microsoft SQL Server backup dataset and assign the verification server to the dataset. About this task Most of the fields on these wizard pages are self-explanatory. The following information describes fields for which you might need guidance. Steps 1. In the left navigation pane, click Datasets. 2. Click New > Backup Dataset or select an existing dataset and click Modify. 3. On the Name page, do the following: For this field Name Policy Run as Scheduler Instance Use custom name format for Snapshot copy Do this Enter the dataset name. Do not include spaces. Select the policy that governs the backup settings, retention, and schedule. This option is available only when a policy with a schedule is chosen. Choose a database access account with which to connect to the SQL server. The account user must be a Windows user with access to the plug-in host. This is required for scheduling backups. Choose a scheduler instance to associate with the scheduling policy. This is required for scheduling only SQL backup jobs. (Optional) Enter a specific Snapshot copy name format, for example, customtext_dataset_policy_hostname or dataset_hostname. By default, time stamp suffix is added to the Snapshot copy name. 4. On the Resources page, select the host, resource type, and SQL Server instance to filter the list of resources.

31 Verifying backups Click the databases, instances, and Availability Groups you want to back up in the Available Resources section and click the right arrow to move them to the Selected Resources section. When you click a resource in the Available Resources section, all resources on the same volume are selected. When you move them to the Selected Resources section, all the resources on the same volume move together. To add just one resource, move all the resources on the volume into the Selected Resources section and then remove resources individually as needed from the Selected Resources section by clicking on the left arrow. 6. On the Verification page, select the verification server for the SQL Server backup. You can select multiple verification servers (local host or remote host). 7. On the Notification page, perform the following operations: For this field Log SnapCenter Server events to storage system syslog Send AutoSupport notification for failed operations to the storage system preference Do this Select to log SnapCenter Server events to the storage system's syslog. Select to send information about any failed operations using AutoSupport to NetApp technical support. Select Always, On Failure, or On failure or warning, to send s to recipients after any backups occur or are attempted. Enter the SMTP server, default subject line, and to and from addresses. 8. Review the summary, and then click Finish. Creating verification policies Before you run a backup verification, you must create a verification policy. A verification policy is a set of rules that governs how you manage and schedule verification. Additionally, you can specify replication, script, and DBCC CHECKDB options. Specifying options in a policy saves time when you want to reuse the policy to verify other backups. Before you begin You must have configured SnapCenter Plug-in for Microsoft SQL Server with verification server settings. You must have assigned one or more verification servers to backup datasets. If you are replicating Snapshot copies to a mirror or vault, the SnapCenter administrator must have assigned you the Storage Virtual Machines (SVMs) for both the source and destination volumes. For information about how administrators assign resources to users, see SnapCenter installation information. About this task Most of the fields on these wizard pages are self-explanatory. The following information describes fields for which you might need guidance.

32 32 Operations Guide for SnapCenter Plug-in for Microsoft SQL Server Steps 1. In the left navigation pane, click Policies. 2. Click New > Verification. 3. On the Verification page, enter the policy name and an optional description. 4. On the Schedule page, do the following: For this field Schedule type Choose scheduler type Do this Select how frequently the operation should occur, when the schedule should start, which day the schedule should occur, and when the schedule should expire. Choose either the SQL Server scheduler or the Windows scheduler. You might want to use the SQL Server scheduler if you cannot access the Windows Scheduler on the server. 5. On the Replication page, specify whether you want to verify the backup on a secondary storage volume. The Snapshot copies are verified on the secondary storage volume and the primary Snapshot copies are marked as verified. Ensure that the SVM settings of secondary storage are updated in the SnapCenter Server settings if you are verifying on the secondary storage. 6. Optional: On the Script page, enter the path and the arguments of the prescript or postscript that should be run before or after the backup operation, respectively. For example, you can run a script to update SNMP traps, automate alerts, send logs, and so on. 7. On the Options page, do the following: For this field Number of backups to verify for deferred verifications DBCC CHECKDB options Do this Enter the number of backups to verify for deferred verification. NOINDEX: The Plug-in for SQL Server uses Microsoft's SQL Server Database Consistency Checker (DBCC) to check the logical and physical integrity of objects in the database. Select this option if you do not want to check nonclustered indexes. You might want to check this to decrease the execution time. ALL_ERRORMSGS: Select this option to display all reported errors per object. NO_INFOMSGS: Select this option to suppress all informational messages. Selected by default. TABLOCK: Select this option to limit the checks and obtain locks instead of using an internal database Snapshot copy. PHYSICAL_ONLY: Select this option to limit the integrity check to the physical structure of the database and detect torn pages, checksum failures, and common hardware failures that impact the database. Selected by default. 8. Review the summary, and then click Finish.

33 Verifying backups 33 Related tasks Configuring your verification server on page 30 Assigning a verification server to backup datasets on page 30 Related information SnapCenter Software 1.0 Administration Guide SnapCenter Software 1.0 Installation and Setup Guide Verifying backups on demand You can verify backup jobs on demand by using the SnapCenter Plug-in for Microsoft SQL Server. The backup verification process protects you from restoring a backup that contains any physical-level corruption or missing database tables or rows. Verifying backups ensures that the databases can be restored as needed. Before you begin You must have configured the log directory for log backup and full backup with log. You must have created a verification policy. You must have backed up a dataset to verify. About this task The backups are verified using the Database Consistency Checker (DBCC), which is a Microsoft SQL Server utility to verify the page-level integrity of databases. DBCC CHECKDB SQL query is used to verify the physical integrity of the database. Steps 1. In the navigation pane, select Datasets. 2. Select the backup copy that you want to verify. 3. Click Verification. 4. On the Verification page, select Verify now mode, the verification policy, and optionally the backup policy. An unverified backup should exist with the selected backup policy.

34 34 Operations Guide for SnapCenter Plug-in for Microsoft SQL Server 5. Click OK. Related tasks Creating verification policies on page 31 Scheduling backup verification If you want to automate the backup verification process, you can schedule verification jobs by using the SnapCenter Plug-in for Microsoft SQL Server. The backup verification process protects you from restoring a backup that contains any physical-level corruption or missing database tables or rows. Verifying backups ensures that the databases can be restored as needed. Before you begin You must have configured the log directory for log backup and full backup with log. You must have created a verification policy with a schedule. You must have an unverified backup to verify. You must have a backup policy with Run verification after backup selected in the Full backup section or the Verify log backup upon completion option selected in the Log backup section on the Backup Type page. About this task The backups are verified using the Database Consistency Checker (DBCC), which is a Microsoft SQL Server utility to verify the page-level integrity of databases. The DBCC CHECKDB SQL query is used to verify the physical integrity of the database. Steps 1. In the navigation pane, select Datasets. 2. Select the backup copy that you want to verify. 3. Click Verification.

35 Verifying backups On the Verification page, select Schedule mode, the verification policy, run as, and optionally the backup policy. An unverified backup should exist with the selected backup policy. 5. Click OK. Related tasks Creating backup policies on page 20 Related information SnapCenter Software 1.0 Installation and Setup Guide Monitoring verification operations on the Jobs page You can monitor the progress of SnapCenter Plug-in for Microsoft SQL Server verification operations by using the Jobs page. You might want to check the progress to determine when it is complete or if there is a issue. About this task The following icons appear on the Jobs page and indicate the state of the operation: In progress Completed successfully Failed Completed with warnings Queued

36 36 Operations Guide for SnapCenter Plug-in for Microsoft SQL Server Verification job is queued Steps 1. From the left navigation pane, click Monitor. 2. From the top navigation bar, click Jobs. 3. Optional: From the Jobs page, filter the list so that only verification operations appear in the list by clicking Filter, selecting Verification from Type, and clicking. 4. Optional: To see the logs, select a verification job from the list and click Details.

37 37 Restoring databases You can restore SQL Server databases, which restores data from one or more backups to your active file system and then recovers the database. You can also restore databases in Availability Groups and then add them to the Availability Group. Before restoring a SQL Server backup, you must perform several preparatory tasks using the SnapCenter Plug-in for Microsoft SQL Server. The following workflow shows the database restoration workflow: Related tasks Preparing to restore a database on page 37 Restoring a database to an up-to-the-minute backup on page 44 Restoring a database to a previous point-in-time on page 45 Restoring a database from secondary storage on page 46 Restoring a database to an alternate path on page 47 Restoring Availability Group databases on page 48 Related references Types of restore operations on page 39 Preparing to restore a database Preparing for database restoration by determining the source, destination, and other requirements for the restore operation, the recovery models, and the type of restore enables you to restore your database successfully. Steps 1. Determine the source and destination for the restore operation. 2. Determine the requirements for restoring the database. 3. Determine the SQL Server recovery models.

38 38 Operations Guide for SnapCenter Plug-in for Microsoft SQL Server 4. Decide the type of restore you require. Related concepts Requirements for restoring a database on page 38 SQL Server recovery models supported by SnapCenter Plug-in for Microsoft SQL Server on page 39 Related references Sources and destinations for a restore operation on page 38 Types of restore operations on page 39 Sources and destinations for a restore operation You can restore a SQL Server database from a backup copy on either primary or secondary storage. You also can restore the database to different destinations in addition to its original location, enabling you to choose the destination that supports your requirements. Sources for a restore operation You can restore databases from primary or secondary storage. Destinations for a restore operation You can restore databases to various types of destinations: Destination The original location A different location Original or different location using different database names Description By default, the Plug-in for SQL Server restores to a database to the same location on the same SQL Server instance. You can restore a database to a different location on any SQL Server instance within the same host. You can restore the database with a different name to any SQL Server instance on the same host where the backup was created. Requirements for restoring a database Before you restore a database from a SnapCenter Plug-in for Microsoft SQL Server backup, you must ensure that several requirements are met. The SQL Server must be online and running before you can restore a database. This applies to both user database restore operations and system database restore operations. Plug-in for SQL Server operations that are scheduled to run against the SQL Server data you are restoring must be disabled, including any jobs scheduled on remote management or remote verification servers. If system databases are not functional, you must first rebuild the system databases using a SQL Server utility. You should also consider the following: If you want to restore while the databases are online, the online restore option should be enabled in the Restore page.

39 Restoring databases 39 SQL Server recovery models supported by SnapCenter Plug-in for Microsoft SQL Server Specific recovery models are assigned to each database type by default. However, the SQL Server database administrator can reassign each database to a different recovery model. The Plug-in for SQL Server supports three types of SQL Server recovery models: Simple recovery model When you use the simple recovery model, you cannot back up the transaction logs. Full recovery model When you use the full recovery model, you can restore a database to its previous state from the point of failure. Bulk logged recovery model When you use the bulk logged recovery model, you must manually re-execute the bulk logged operation. You must perform the bulk logged operation if the transaction log that contains the operation's commit record has not been backed up before restore. If the bulk logged operation inserts 10 million rows in a database, and the database fails before the transaction log is backed up, the restored database will not contain the rows that were inserted by the bulk logged operation. Types of restore operations You can use the SnapCenter Plug-in for Microsoft SQL Server to perform different types of restore operations. Restore up-to-the-minute Restore to a previous point-in-time You can restore up-to-the-minute or restore to a previous point in time in the following situations: Restore from SnapVault secondary storage Restore to alternate path (location) Restore Availability Group database Restore up-to-the-minute In an up-to-the-minute restore (selected by default), databases are recovered up to the point of failure. The Plug-in for SQL Server accomplishes this by performing the following sequence: 1. Backs up the last active transaction log before restoring the database. 2. Restores the databases from the full database that you select. 3. Applies all the transaction logs that were not committed to the databases (including transaction logs from the backups from the time the backup was created up to the most current time). Transaction logs are played forward and applied to any selected databases. An up-to-the-minute restore requires a contiguous set of transaction logs. As the Plug-in for SQL Server cannot restore SQL Server database transaction logs from logshipping backup files (log-shipping enables you to automatically send transaction log backups from a primary database on a primary server instance to one or more secondary databases on separate secondary server instances), you will not be able to perform an up to minute restore from the transaction log backups. Due to this reason, you should use the Plug-in for SQL Server to back up your SQL Server database transaction log files.

40 40 Operations Guide for SnapCenter Plug-in for Microsoft SQL Server If you do not need to retain up-to-the-minute restore capability for all backups, you can configure your system's transaction log backup retention through the backup policies. Example of an up-to-the-minute restore operation You run the Plug-in for SQL Server backup every day at noon and on Wednesday at 4:00 p.m. you need to restore from a backup. For some reason, the backup from Wednesday noon failed verification, so you decide to restore from the Tuesday noon backup. After that, if the backup is restored, all the transaction logs are played forward and applied to the restored databases, starting with those that were not committed when you created Tuesday's backup and continuing through the latest transaction log written on Wednesday at 4:00 p.m. (if the transaction logs were backed up). Restore to a previous point-in-time In a point-in-time restore operation, databases are restored only to a specific time from the past. A point-in-time restore operation occurs in the following restore situations: The database is restored to a given time in a backed-up transaction log. The database is restored, and only a subset of backed-up transaction logs are applied to it. Note: When you restore a database to a point in time, it results in a new recovery path. The following image illustrates the concerns when a point-in-time restore operation is performed: In the image, recovery path 1 consists of a full backup followed by the number of transaction log backups. You restore the database to a point in time. New transaction log backups are created after the point-in-time restore operations, which results in recovery path 2. The new transaction log backups are created without creating a new full backup. Due to data corruption or other problems, you cannot restore the current database until a new full backup is created. Also, it is not possible to apply the transaction logs created in recovery path 2 to the full backup belonging to recovery path 1. If you apply transaction log backups, you can also specify a particular date and time at which you want to stop the application of backed up transactions. To do this, you specify a date and time within the available range and the Plug-in for SQL Server rolls back any transactions that were not committed prior to that point in time. You can use this method to restore databases to a point in time before a corruption occurred, or to recover from an accidental database or table deletion.

41 Restoring databases 41 Example of a point-in-time restore operation Suppose you make full database backups once at midnight and a transaction log backup every hour. The database crashes at 9:45 a.m., but you still back up the transaction logs of the failed database. You can choose from among these point-in-time restore scenarios: Restore the full database backup made at midnight and accept the loss of the database changes made afterward. (Option: None) Restore the full database backup and apply all the transaction log backups until 9:45 a.m. (Option: Log until) Restore the full database backup and apply transaction log backups, specifying the time you want the transactions to restore from the last set of transaction log backups. (Option: By specific time) In this case, you would calculate the date and time at which a certain error was reported. Any transactions that were not committed prior to the date and time specified are rolled back. Related tasks Restoring a database to an up-to-the-minute backup on page 44 Restoring a database to a previous point-in-time on page 45 Restoring a database from secondary storage on page 46 Restoring a database to an alternate path on page 47 Restoring Availability Group databases on page 48 Restoring SQL Server databases You can use SnapCenter to restore backed-up SQL Server databases. Database restoration is a multiphase process that copies all the data and log pages from a specified SQL Server backup to a specified database. Before you begin You must have backed up the datasets. If you are replicating Snapshot copies to a mirror or vault, the SnapCenter administrator must have assigned you the Storage Virtual Machines (SVMs) for both the source and destination volumes. For information about how administrators assign resources to users, see SnapCenter installation information. About this task You cannot restore the database if the SQL Server Agent is running and the users are accessing the database. You must stop the SQL Server Agent before restoring the database. You cannot restore system databases to an alternate path. Most of the fields on the Restore wizard pages are self-explanatory. The following information describes fields for which you might need guidance. SnapCenter can restore databases in a Windows cluster without taking the SQL Server cluster group offline.

42 42 Operations Guide for SnapCenter Plug-in for Microsoft SQL Server If a cluster failure (a cluster group move operation) occurs during the restore operation (for example, if the node that owns the resources goes down), you must reconnect to the SQL Server instance and then restart the restore operation. Steps 1. In the left navigation pane, click Inventory. 2. To filter the list of resources, select the Host, Resource Type, and SQL Server Instance options. 3. Select a database from the list and click Restore. Note: The Backup Now, Restore, Manage Backups, and Clone options on the Inventory page are disabled if you select a non-netapp LUN, a database that is corrupted, or a database that is being restored. 4. On the Backups page, select whether you want to restore from primary or secondary storage systems, and then select a backup to restore. 5. On the Logs page, select one of the following options: For this field None All log backups By log backups until By specific date until Do this Choose this when you need to restore only the full back without any logs. Choose this to restore all of the available log backups dated after the full backup. Choose this to restore the database based on backup logs created up to the backup log with the selected date. Specify the date and time after which transaction logs are not applied to the restored database. This point-in-time restore operation halts the restoration of transaction log entries that were recorded after the specified date and time. 6. On the Restore As page, provide a new database name to restore the database to an alternate name, select an instance, and specify restore paths. 7. Optional: On the Script page, enter the path and the arguments of the prescript or postscript that should be run before or after the restore operation respectively. For example, you can run a script to update SNMP traps, automate alerts, send logs, and so on. 8. On the Options page, select the following restore options: For this field Restore databases even if existing databases are online Retain SQL database replication settings Create transaction log backup before restore Quit restore if transaction log backup before restore fails Do this Choose this to restore databases without having to place the database offline. Choose this to restore the database and retains the existing replication settings. Choose this to create a transaction log before the restore operation begins. You should enable this. Choose this to abort the restore operation if the transaction log backup fails.

43 Restoring databases 43 a. Choose the state in which the database should exist after the restore operation finishes: For this field Operational, but unavailable for restoring additional transactional logs Non-operational, but available for restoring additional transactional logs Read-only mode, available for restoring additional transactional logs Do this Select this option if you are restoring all of the necessary backups now. This is the default behavior, which leaves the database ready for use by rolling back the uncommitted transactions. Additional transaction logs cannot be restored until you create a new backup. Choose this to leave the database non-operational and does not roll back the uncommitted transactions. Additional transaction logs can be restored. The database cannot be used until it is recovered. Choose this to leave the database in read-only mode. It undoes uncommitted transactions, but saves the undo actions in a standby file so that recovery effects can be reverted. If the undo directory option is enabled, more transaction logs are restored. If the restore operation for the transaction log is unsuccessful, the changes can be rolled back. For more information, see SQL Server documentation. 9. On the Notification page, select the following options: For this field Log SnapCenter server events to storage system syslog Send AutoSupport notification for failed operations to storage system Send notification Do this Select to log SnapCenter Server events to the storage system's syslog. Select to send information to NetApp any failed operations using AutoSupport. Select Always, On Failure, or On failure or warning to send messages to recipients after any backups occur or are attempted. Enter the SMTP server, default subject line, and To and From addresses. 10. Review the summary and click Finish. After you finish You should monitor the restore process using the Monitor > Jobs page. You must always create a full backup after restoring a database. Related information SnapCenter Software 1.0 Installation and Setup Guide

44 44 Operations Guide for SnapCenter Plug-in for Microsoft SQL Server Restoring a database to an up-to-the-minute backup In an up-to-the-minute restore operation, databases are recovered up to the point of failure. You should use this process if you do not want to restore a database to a specified point in time. Before you begin You must have created a backup policy that retains the up-to-the-minute settings. An up-to-theminute restore operation requires a contiguous set of transaction logs. About this task Most of the fields on the Restore wizard pages are explained in the basic restore process. The following information describes fields for which you might need guidance. Steps 1. In the left navigation pane, click Inventory. 2. To filter the list of resources, select the Host, Resource Type, and SQL Server Instance options. 3. Select a database from the list and click Restore. Note: The Backup Now, Restore, Manage Backups, and Clone options on the Inventory page are disabled if you select a non-netapp LUN, a database that is corrupted, or a database that is being restored. 4. On the Backups page, select whether you want to restore from primary or secondary storage systems, and then select a backup to restore. 5. On the Logs page, select or enter the following information: For this field All log backups Do this Choose this up-to-the-minute backup restore operation to restore all of the available log backups after the full backup. 6. Complete the Restore wizard.

45 Restoring databases Click Finish. After you finish You should perform a full backup and verification to confirm that your restored database is free of physical-level corruption. This task is especially important if you restored to a database in a different path, which is shared by other databases. Related references Types of restore operations on page 39 Restoring a database to a previous point-in-time You can specify the time to which you want the database to be restored. For example, if you are aware that wrong data was added to the database at 5:30 p.m., you can restore the database till 5:25 p.m. on the same day. Before you begin You must have created a backup policy. About this task Most of the fields on the Restore wizard pages are explained in the basic restore process. The following information describes fields for which you might need guidance. Steps 1. In the left navigation pane, click Inventory. 2. To filter the list of resources, select the Host, Resource Type, and SQL Server Instance options. 3. Select a database from the list and click Restore. Note: The Backup Now, Restore, Manage Backups, and Clone options on the Inventory page are disabled if you select a non-netapp LUN, a database that is corrupted, or a database that is being restored. 4. On the Backups page, select whether you want to restore from primary or secondary storage systems, and then select a backup to restore. 5. On the Logs page, select one of the following options: For this field By log backups until By specific date until Do this Choose to perform a point-in-time restore operation, which restores the database based on backup logs until the backup log with the selected date. Specify the date and time after which transaction logs are not applied to the restored database. This point-in-time restore operation halts the restoration of transaction log entries that were recorded after the specified date and time.

46 46 Operations Guide for SnapCenter Plug-in for Microsoft SQL Server 6. Complete the Restore wizard. 7. Click Finish. After you finish You should perform a full backup and verification to confirm that your restored database is free of physical-level corruption. This task is especially important if you restored to a database in a different path, which is shared by other databases. Related references Types of restore operations on page 39 Restoring a database from secondary storage You can restore the backed-up SQL Server databases from physical LUNs (RDM, iscsi, or FCP) on secondary storage. The Restore feature is a multiphase process that copies all the data and log pages from a specified SQL Server backup residing on secondary storage to a specified database. Before you begin You must have backed up the datasets to secondary storage. About this task Most of the fields on the Restore wizard pages are explained in the basic restore process. The following information describes fields for which you might need guidance. Steps 1. In the left navigation pane, click Inventory. 2. To filter the list of resources, select the Host, Resource Type, and SQL Server Instance options. 3. Click Restore. 4. On the Backups page, select secondary to restore a database from secondary storage system, and then select the backup to restore.

47 Restoring databases Complete the Restore wizard and review the summary and click Finish. After you finish You should perform a full backup and verification to confirm that your restored database is free of physical-level corruption. This step is especially important if you restored to a database in a different path that is shared by existing databases. Restoring a database to an alternate path You can restore the backed-up SQL Server databases using the SnapCenter Plug-in for Microsoft SQL Server to a different SQL instance on the same host where the backup was created. You might want to restore an older backup to an alternate path so that you do not replace a production version. Before you begin You must have backed up the datasets. About this task Most of the fields on the Restore wizard pages are explained in the basic restore process. The following information describes fields for which you might need guidance. Steps 1. In the left navigation pane, click Inventory. 2. To filter the list of resources, select the Host, Resource Type, and SQL Server Instance options. 3. Click Restore. 4. On the Backups page, select whether you want to restore from primary or secondary storage systems, and then select the backup to restore. 5. On the Logs page, select the log backup duration. 6. On the Restore As page, provide an optional database name, select an instance, and specify restore paths.

48 48 Operations Guide for SnapCenter Plug-in for Microsoft SQL Server Only SQL Servers from the same host are listed. 7. Complete the Restore wizard and review the summary and click Finish. After you finish If you restored a database to a different path that is shared by existing databases, you should perform a full backup and backup verification to confirm that your restored database is free of physical-level corruption. Restoring Availability Group databases You can restore the Availability Group (AG) databases using the SnapCenter Plug-in for Microsoft SQL Server. An AG supports a failover environment for a discrete set of user databases, known as availability databases, that fail over together. About this task You must be aware of the following limitations: You must return the database to an AG manually after an AG database restore operation is completed on a secondary AG node replica. You cannot use the AG after an AG database restore operation is completed on a primary AG node replica. You must copy all the log backups from the nodes present in the log directory to the local node log folder for AG up-to-the-minute or AG point-in-time restore operations. Most of the fields on the Restore wizard pages are explained in the basic restore process. The following information describes fields for which you might need guidance. Steps 1. In the left navigation pane, click Inventory. 2. To filter the list of resources, select the Host, Resource Type, and SQL Server Instance options. Note: Only SQL Servers from the same host are listed. 3. Select a database that belongs to an AG from the list and click Restore.

49 Restoring databases 49 Note: The Backup Now, Restore, Manage Backups, and Clone options on the Inventory page are disabled if you select a non-netapp LUN, a database that is corrupted, or a database that is being restored. 4. Complete the Restore wizard and review the summary and click Finish. After you finish You should perform a full backup and verification to confirm that your restored database is free of physical-level corruption. This task is especially important if you restored to a database in a different path, which is shared by other databases. Monitoring restore operations on the Jobs page You can monitor the progress of SnapCenter Plug-in for Microsoft SQL Server restore operations by using the Jobs page. You might want to check the progress to determine when the operation is complete or if there is an issue. About this task Post-restore database recovery states describe the conditions of the database after a restore operation and any further restore actions that you can take. The following icons appear on the Jobs page and indicate the state of the operation: In progress Completed successfully Failed Completed with warnings Queued Verification job is queued Steps 1. From the left navigation pane, click Monitor. 2. From the top navigation bar, click Jobs. 3. Optional: From the Jobs page, filter the list so that only verification operations appear in the list by clicking Filter, selecting Restore from Type, and clicking. 4. Optional: To see the logs, select a restored database from the list and click Details.

50 50 Cloning database resources You must perform several tasks using the SnapCenter Server before cloning from a backup. Database cloning is the process of creating a point-in-time copy of a production database or its backup set. You might clone databases to test functionality that has to be implemented using the current database structure and content during application development cycles, for data extraction and manipulation tools when populating data warehouses, or to recover data that was mistakenly deleted or changed. A database cloning operation generates reports based on the job IDs. The following workflow shows the sequence in which you must perform cloning operations: Related tasks Creating clone policies on page 51 Creating clone datasets on page 52 Cloning from a SQL Server database backup on page 55 Clone lifecycle on page 57 Monitoring clone operations on the Jobs page on page 58 How a clone operation works SnapCenter Plug-in for Microsoft SQL Server clones the databases that you select to the active file system. Database cloning is the process of creating a point-in-time copy of a production database. You might clone databases during application development to populate data warehouses or to recover data. The database cloning feature enables you to clone specific databases or all databases simultaneously without impacting your production data. You must provide a suffix for the cloned database when an identical database name is present on the SQL server instance. You can select the SQL Server instance either from a host on which the database resides or from a remote host connected to the storage system. You must consider the following before performing the clone operation:

51 Cloning database resources 51 If a database resides on a virtual machine with a VMDK disk, Plug-in for SQL Server cannot clone the database to a physical server. For a clone operation, the root directory of the volume mount point cannot be a shared directory. You cannot create a clone on a node that is not the home node for the aggregate. Types of clone operations You can use SnapCenter Plug-in for Microsoft SQL Server to clone either from a database backup or a production database. Clone from a database backup The cloned database can serve as a baseline for developing new applications, help isolate application errors that occur in the production environment, or be used for recovery from soft database errors. Clone lifecycle You might want to clone the production database during a time that is not busy. You can schedule recurring clone jobs using the Plug-in for SQL Server. Creating clone policies Before you clone a database resource, you must create a SQL Server clone policy for the dataset you want to clone. A clone policy is a set of rules that governs how you manage, schedule, and retain clones. Additionally, you can specify the backup policy, the secondary location to clone, and scripts to run before or after the clone. Specifying options in a policy saves time when you want to reuse the policy on another dataset. Before you begin You must have created a backup. About this task Using a policy enables you to reuse prescripts and postscripts that you might have set up. Most of the fields on these wizard pages are self-explanatory. The following information describes fields for which you might need guidance. Steps 1. In the left navigation pane, click Policies. 2. Click New > SQL Server Policy > Clone. 3. On the Name page, enter the policy name and an optional description. 4. On the Schedule page, do the following: For this field Schedule type Do this Select how frequently the clone should occur, when the clone schedule should start, which day the clone should occur, and when the schedule should expire.

52 52 Operations Guide for SnapCenter Plug-in for Microsoft SQL Server For this field Choose scheduler type Do this Choose a scheduler type: for example, use the SQL Server scheduler or the Windows scheduler. SQL has its own scheduler that you could use. You might want to use the SQL Server scheduler if you cannot access the Windows Scheduler on the server. 5. On the Options page, do the following: For this field Choose archive location Backup policy Delete clone if schedule expires Do this Choose whether you want to place the clone on primary or secondary storage. Select the backup policy that is applicable to the clone operation. The backup policy governs the replication, retention, script, backup type, and Availability Group settings. The clone schedule overrides the backup schedule. The backup policy is required as the clone from a database backup operation first creates a Snapshot copy and then clones from this newly created Snapshot copy. If you want to delete clones after the schedule expires, check the option. 6. Optional: On the Script page, enter the path and the arguments of the prescript or postscript that should be run before or after the backup operation respectively. For example, you can run a script to update SNMP traps, automate alerts, send logs, and so on. 7. Review the summary, and then click Finish. After you finish Continue by creating a clone dataset, attaching the policy to the clone dataset, and then cloning the database. Related tasks Creating clone datasets on page 52 Cloning from a SQL Server database backup on page 55 Clone lifecycle on page 57 Related information SnapCenter Software 1.0 Administration Guide Creating clone datasets Before you clone from a production database, you must create a clone dataset. A dataset is a set of virtual or physical containers that you can configure as a unit for group protection or group provisioning operations. Creating a clone dataset enables you to clone from a production database. About this task Most of the fields on these wizard pages are self-explanatory. The following information describes fields for which you might need guidance.

53 Cloning database resources 53 Steps 1. In the left navigation pane, click Datasets. 2. Click New > Clone Dataset. 3. On the Name page, do the following: For this field Name Policy Run as Scheduler Instance Use custom name format for Snapshot copy Do this Enter the dataset name. Do not include spaces. Select the clone policy that governs the clone settings and schedule. Choose a database access account with which to connect to the SQL Server. The account must be a Windows user with access to the plugin host. This is required for scheduling clones. Note: This option is available only when the selected policy has a schedule. Choose a scheduler instance to associate with the scheduling policy. This is required for scheduling clones. Optional: Enter a specific Snapshot copy name and format. For example, customtext_dataset_policy_hostname or dataset_hostname. By default, a timestamp is appended to the Snapshot copy name. 4. Optional: To filter the list of resources, select the host and resource type. If you filter, matching resources are populated in the Available Resources section. Resources of the same volume are automatically selected. You can deselect resources manually if they are not required. Note: You can add only virtual resources or only physical resources to a clone dataset. You cannot add both to the same dataset.

54 54 Operations Guide for SnapCenter Plug-in for Microsoft SQL Server 5. Click the databases that you want to clone in the Available Resources section, and then click the right arrow to move them to the Selected Resources section. 6. On the Clone Options page, do the following: For this field Clone server Clone instance Auto assign mount point or Auto assign volume mount point under path Clone suffix Archive location Do this Choose the host on which the clone will be placed. Choose the clone instance to which you want to clone. This SQL instance must be located within the specified clone server. Choose to automatically assign a mount point or volume mount point in a path. Choosing to auto assign a volume mount point under path enables you to provide a specific directory. Mount points will be created within that directory. If you choose this option, you must ensure that the directory is empty. If there is a database in the directory, the database will be in an invalid state after the mount. Enter a suffix that will be appended to the clone database to identify that it is a clone. Each SQL instance used to create the clone dataset must have a unique database name. For example, if a clone dataset contains source database db1 from SQL instance inst1, and if db1 is cloned to SQL instance inst1, then the clone database name is db1 clone, where clone is a mandatory user-defined suffix because it is being cloned to the same instance. If db1 is cloned to SQL instance inst2, then the clone database name can remain as db1 (the suffix is optional) because it is being cloned to a different instance. Choose an archive location if the clone policy preference is to clone from an archive location. The clone operation will be performed from the selected archive location. 7. On the Notification page, do the following: For this field Log SnapCenter Server events to storage system syslog Send AutoSupport notification for failed operations to the storage system preference Do this Select this option to log SnapCenter Server events to the storage system's syslog file. Select this option to send information about any failed operations using AutoSupport to technical support. Select Always, On Failure, or On failure or warning to send messages to recipients after any backups occur or are attempted. Enter the SMTP server, default subject line, and To and From addresses. 8. Review the summary, and then click Finish. Related tasks Creating clone policies on page 51

55 Cloning database resources 55 Cloning from a SQL Server database backup You can clone a database backup by using SnapCenter Plug-in for Microsoft SQL Server. If you want to refresh a production environment, you must schedule a clone operation. However, if you want to access or restore an older version of the data, you can clone backups on demand. Before you begin You must have prepared for data protection by completing tasks such as adding hosts, identifying resources, and creating SVM connections. You must have backed up the datasets. You must have created a clone policy. About this task Most of the fields on the Clone wizard pages are self-explanatory. The following information describes some of the fields for which you might require guidance. Steps 1. In the left navigation pane, click Inventory. 2. Optional: To filter the resources list, select the resources from the Host, Resource Type, and SQL Server Instance options. 3. From the resources list, select the database that you want to clone and click Clone backup. Note: The Backup Now, Restore, Manage Backups, and Clone options on the Inventory page are disabled if you select a non-netapp LUN, a database that is corrupted, or a database that is being restored. 4. On the Policy page, select the clone policy. 5. On the Options page, do the following: For this field Clone server Clone instance Clone suffix Do this Choose the host on which the clone should be placed. Choose the clone instance to which you want to clone the database backup. This SQL instance must be located in the specified clone server. Enter a suffix that will be appended to the clone filename to identify that it is a clone. For example, db1_clone. If you are cloning to the same location as the original database, you must provide a suffix to differentiate the cloned database from the original database; otherwise, the operation fails.

56 56 Operations Guide for SnapCenter Plug-in for Microsoft SQL Server For this field Auto assign mount point or Auto assign volume mount point under path Archive location Do this Choose whether to automatically assign a mount point or volume mount point under a path. Auto assign volume mount point under path: The mount point under a path allows you to provide a specific directory. The mount points will be created within that directory. Before you choose this option, you must ensure that the directory is empty. If there is a database in the directory, the database will be in an invalid state after the mount operation. Choose an archive location if the Archive option in the Clone policy page is enabled. 6. On the Backups page, select the backup that you want to clone. 7. On the Resources page, select the resources that you want to clone. Note: The backup that you select might contain multiple databases. The option to change resources enables you to select the databases from a backup that you want to clone. 8. On the Logs page, select one of the following options: For this field None All log backups By log backups until Do this Choose this option when you want to clone only the full back without any logs. Choose this option to clone all the available log backups dated after the full backup. Choose this option to clone the database based on the backup logs that were created up to the backup log with the selected date.