Tchater maintenant avec le support
Tchattez avec un ingénieur du support

NetVault Plug-in for SQL Server 11.2 - User Guide

Introducing Quest® NetVault® Backup Plug-in  for SQL Server® Planning your SQL Server deployment Installing and removing the plug-in Configuring the plug-in Backing up data
Defining a backup strategy Reviewing the compression features Performing Online VDI backups Performing VSS backups in SQL Server® Example of creating a full VDI backup of an AlwaysOn Availability Group
Restoring data Troubleshooting

Using other restore procedures

This topic describes other restore operations that you can perform with the plug-in:

•
Restoring data to a Virtual Client
•
Renaming or relocating a database
•
Restoring a database to an alternate instance
•
Restoring data to an alternate SQL Server®

Restoring data to a Virtual Client

All options available for a restore with the plug-in are also available in high-availability — SQL Server Failover Cluster and AlwaysOn Availability Group — environments. Data selection is performed the same way. The difference is that restorable backups of a Virtual Client are displayed on the Create Restore Job — Choose Saveset page under the name of the Virtual Client, not the specific NetVault Backup Client or node that was active during each backup. When a restore job is initiated, NetVault Backup communicates with all member Clients to determine which machine controls the cluster, and then targets this machine for the restore.

Also, you can restore a NetVault Backup Virtual Client to a non-clustered (standalone) NetVault Backup Client.

 
* 
NOTE: During a restore, run the process using the node for the Virtual Client. Do not use one of the nodes for an individual client in the cluster to run the process. If you open or expand one of the nodes and drill down through the hierarchy, you might see a dimmed SQL Server Instance identified as local. While the system might use this instance in maintaining log information, do not run any processes at this level.
Important considerations restoring data to a Virtual Client for an AlwaysOn Availability Group

Use the following guidelines when you restore data that resides in an AlwaysOn Availability Group.

•
You can restore data from the backup of an AlwaysOn Availability Group to the same group. You cannot restore an AlwaysOn Availability Group to an alternate SQL Server Instance, standalone deployment, or a different AlwaysOn Availability Group.
•
If you complete multiple sequential restores of the primary replica and you want to omit the primary replica after the first restore, Quest recommends that you complete the Enter the NetVault Backup Client Name on the AlwaysOn Availability Groups Primary Node field.
•
Unless you want to use SQL Server Management Studio to add the primary replica to the group, select the Add Primary Database to the AlwaysOn Availability Group After Restore check box.
•
Ensure that the secondary replicas are always removed from the group before restoring the primary replica. You can do this manually using SQL Server Management Studio or by selecting the Remove Database Secondary Copies from the AlwaysOn Availability Group Before Restore check box.
If you do not remove the secondary replicas before completing the restore, it might prevent the plug-in from removing the primary replica or the restore might complete with warnings. Also, failing to remove the secondary replicas might prevent you from adding the secondary replicas during the subsequent backup of the primary replica.
•
If you select With NO RECOVERY for the Restore Type of the primary replica, do not select the Add Primary Database to the AlwaysOn Availability Group After Restore check box. You must complete the recovery before you can add the database to the group.
•
You cannot use the same job to restore databases from multiple AlwaysOn Availability Groups.
•
You cannot use the same job to restore a database that belongs to an AlwaysOn Availability Group and a different database that does not belong to a group.
•
If you use SQL Server's named instances for your AlwaysOn Availability Group nodes, the restore process requires that any database that is backed up using the Virtual Client must belong to the same named instance on each node of the group.
•
You must create separate jobs to restore databases from an AlwaysOn Availability Group and databases that are not included in a group. Also, use the same job to restore databases from an AlwaysOn Availability Group if they reside in the same group.

Restoring data to a Virtual Client in an AlwaysOn Availability Group

The following topics list the high-level steps for restoring data in AlwaysOn Availability Group deployments and provide examples of different restores.

•
High-level restore steps for restoring data to a Virtual Client in an AlwaysOn Availability Groups
•
Example of restoring a database that was added to all replicas in an AlwaysOn Availability Group
•
Example of restoring a secondary replica and converting it to a primary replica
•
Example of restoring a VDI backup of an AlwaysOn Availability Group
•
Example of restoring a database that does not exist on the primary replica
High-level restore steps for restoring data to a Virtual Client in an AlwaysOn Availability Groups

These topics describe the general steps that you must take to complete a restore.

Performing a VSS restore of an AlwaysOn Availability Group

When restoring a VSS-based backup, be aware of the following:

•
VSS is a generic interface that requires objects included in the snapshot comply with certain requirements. For example, SQL Server databases that have a status of Restoring conflict with the creation of VSS backup snapshots.
•
SQL Server databases participating in an AlwaysOn Availability Group cannot be included in a VSS restore snapshot, and some operations are not available for databases that are joined in a group.
•
If you use the Copy Database Files to Target Directory option, do not remove the database from the group.
•
As noted previously, a disadvantage of VSS backups is that the SQL Server VSS Writer does not support the ability to restore a database to an alternate instance whether that instance is on the same server and host or an alternate server and host.
•
The following procedure applies if you are restoring the group to its original destination or if you are restoring the group using the Rename/Relocate option. However, if you are performing a restore with rename or relocate, or both, the original database cannot be joined in an AlwaysOn Availability Group.
1
Use SQL Server Management Studio to remove the database from the AlwaysOn Group.
a
On the primary replica, select Suspend Data Movement for the database.
b
On all secondary replicas, remove the database from the group.
c
On the primary replica, remove the database from the group.
2
Restore the primary from the applicable backups.
3
Add the database to the AlwaysOn Availability Group on the primary replica.
4
Add the database to the AlwaysOn Availability Group on each secondary replica.
Performing a VDI restore of an AlwaysOn Availability Group
1
Remove the secondary replicas.
2
Remove the primary replica.
3
Restore the primary from the applicable backups.
4
Using the process for a standalone deployment, perform Full and Differential Transaction Log backups of the primary replica.
5
Using the process for a standalone deployment, perform Full and Differential Transaction Log restores of each secondary replica.
These restores set the secondary replicas to match the primary replica.
6
Add the database to the AlwaysOn Availability Group on the primary replica.
7
Add the database to the AlwaysOn Availability Group on each secondary replica.
Example of restoring a database that was added to all replicas in an AlwaysOn Availability Group

The following procedure describes how to restore a database that was added to the primary replica and all secondary replicas in the AlwaysOn Availability Group.

1
Select the data to restore.
For more information, see Selecting Online VDI data for restore under Restoring data from Online VDI backups or Selecting data for a VSS restore under Restoring data from VSS backups.
As described previously, you cannot use the same job to restore databases from multiple groups. Nor can you use the same job to restore a database that belongs to a group and a different database that does not.
2
On the Create Selection Set page, click Edit Plugin Options, and configure the applicable parameters depending on whether you are performing a VSS or VDI restore.
For information on the options that are common to all restore jobs, see Setting Online VDI restore options under Restoring data from Online VDI backups or Setting VSS restore options under Restoring data from VSS backups.
3
In the AlwaysOn Availability Groups section, select the applicable check boxes:
•
Remove Database Secondary Copies from the AlwaysOn Availability Group Before Restore
•
Remove Primary Database from the AlwaysOn Availability Group Before Restore
•
Add Primary Database to the AlwaysOn Availability Group After Restore
Where you are in the process determines which check boxes you should select. For example, when you run the restore of the Full Backup, select all the check boxes. When you run the restore of the Transaction Logs, do not select the check boxes. Also, do not select Add Primary Database to the AlwaysOn Availability Group After Restore if you selected the With NO RECOVERY option.
4
If you previously removed the database from the AlwaysOn Availability Group on the primary node, complete the following fields:
•
Restore to the following AlwaysOn Availability Group: Enter the name of the group.
•
Enter the NetVault Backup Client Name on the AlwaysOn Availability Groups Primary Node (optional): Enter the name of the client that is running on the primary node. If you enter a name for a different node, the restore fails. If you are unsure which client is running on the primary node, use SQL Server Management Studio to determine which node is the primary node in the group.
 
* 
IMPORTANT: Although the second field is labeled optional, it is required in this scenario.

If you enter the correct information and the database is already part of the group, but you do not select the Remove Primary Database from the AlwaysOn Availability Group Before Restore check box, the restore fails.

If the database is not part of the group, you specify an incorrect name, and the plug-in is unable to check that the client resides on the primary replica, the plug-in restores the database. However, you cannot add the database to the group.

If a failover to a different node occurs after the restore job is run and you have entered the primary client and group names, update the information stored in Restore Options to reflect the name of the new client. Otherwise, subsequent runs of the same restore job fail.
5
In the Instance Name, If Restoring to an AlwaysOn Named Instance field, enter the name of the instance.
 
* 
TIP: Only enter the name of the instance. If you enter the fully qualified name, <HostName>\<InstanceName>, the plug-in ignores the hostname.
6
Complete the steps outlined in Finalizing and submitting an Online VDI restore job under Restoring data from Online VDI backups.
7
Perform a Full Database backup from the primary replica.
8
Perform a restore from each secondary replica that was backed up by the Full Database backup performed in Step 7.
Complete a separate restore operation for each secondary replica that makes up the primary replica.
9
Use SQL Server Management Studio to add the secondary replicas to the AlwaysOn Availability Group.
Example of restoring a secondary replica and converting it to a primary replica

The following procedure describes how to restore a secondary replica to a backup taken from the Virtual Client and then convert the secondary replica to function as the primary replica.

1
On the secondary replica, remove the database from the AlwaysOn Availability Group.
2
Select the data to restore.
For more information, see Selecting Online VDI data for restore under Restoring data from Online VDI backups or Selecting data for a VSS restore under Restoring data from VSS backups.
As described previously, you cannot use the same job to restore databases from multiple groups. Nor can you use the same job to restore a database that belongs to a group and a different database that does not.
3
On the Create Selection Set page, click Edit Plugin Options, and configure the applicable parameters depending on whether you are performing a VSS or VDI restore.
For information on the options that are common to all restore jobs, see Setting Online VDI restore options under Restoring data from Online VDI backups or Setting VSS restore options under Restoring data from VSS backups.
4
In the Target Instance field in the Restore Options section, enter the name of the client running on the secondary replica.
5
In the AlwaysOn Availability Groups section, select the applicable check boxes:
•
Remove Primary Database from the AlwaysOn Availability Group Before Restore
•
Add Primary Database to the AlwaysOn Availability Group After Restore
Where you are in the process determines which check boxes you should select. For example, when you run the restore of the Full Backup, select all the check boxes. When you run the restore of the Transaction Logs, do not select the check boxes. Also, do not select Add Primary Database to the AlwaysOn Availability Group After Restore if you selected the With NO RECOVERY option.
6
In Restore to the following AlwaysOn Availability Group, enter the name of the group.
7
In the Instance Name, If Restoring to an AlwaysOn Named Instance field, enter the name of the instance.
 
* 
TIP: Only enter the name of the instance. If you enter the fully qualified name, <HostName>\<InstanceName>, the plug-in ignores the hostname.
8
Complete the steps outlined in Finalizing and submitting an Online VDI restore job under Restoring data from Online VDI backups.
9
Perform a failover to the secondary replica.
10
Use SQL Server Management Studio to identify the secondary replica as the primary replica for all databases assigned to the AlwaysOn Availability Group.
11
Use SQL Server Management Studio to add the database back to the group on the new primary replica.
 
* 
IMPORTANT: To complete this step, you might need to remove the database from the remaining secondary replicas and postpone adding the database to the new primary replica until the process is finished.
12
Perform Full Database and Transaction Log backups of the new primary replica.
13
Perform a restore of each secondary replica using the Full and Transaction Log backups completed in the previous step.
For each secondary replica, remove the database on that node from the AlwaysOn Availability Group, and complete the Full and Transaction Log restores.
14
Use SQL Server Management Studio to add the secondary replicas to the AlwaysOn Availability Group.
Example of restoring a VDI backup of an AlwaysOn Availability Group

The following procedure describes how to restore a VDI backup. This procedure is based on the example described in Example of creating a full VDI backup of an AlwaysOn Availability Group. The following procedure also requires that you restore Transaction Log backups, a process that was not included in the previous backup example.

1
In the Navigation pane, click Create Restore Job.
2
In the saveset table on the Create Restore Job — Choose Saveset page, select the Full Backup of the primary replica that you are restoring, and click Next.
3
On the Create Selection Set page, select the AlwaysOn Availability Group that you want to restore.
Include all databases included in the saveset.
4
Click Edit Plugin Options.
5
In the Restore Type section, select With NO RECOVERY.
6
In the AlwaysOn Availability Groups sections, select the Remove Database Secondary Copies from the AlwaysOn Availability Group Before Restore and Remove Primary Database from the AlwaysOn Availability Group Before Restore check boxes.
Do not select the Add Primary Database to the AlwaysOn Availability Group After Restore because you selected the With NO RECOVERY option.
7
Click OK to save the settings, and then click Next.
8
In Job Name, specify a name for the job if you do not want to use the default setting.
9
In the Target Client list, select the same Virtual Client that was the target of the backup.
10
Click Save & Submit, and use the Job Status page to monitor progress.
You might see a “Waiting for secondaries” status for up to 20 minutes. Do not proceed until the Run Status is “Restore Completed.”
11
In the Navigation pane, click Create Restore Job.
12
In the saveset table on the Create Restore Job — Choose Saveset page, select the Incremental Transaction Log backup of the primary replica that you are restoring, and click Next.
13
On the Create Selection Set page, select the same AlwaysOn Availability Group and databases that you selected during the restore of the Full Backup.
14
Click Edit Plugin Options.
15
In the Restore Type section, select With RECOVERY.
16
In the AlwaysOn Availability Groups section, select the Add Primary Database to the AlwaysOn Availability Group After Restore check box.
Do not select the other check boxes.
17
In the Restore to the following AlwaysOn Availability Group field, enter the name of the group.
18
In the Enter the NetVault Backup Client Name on the AlwaysOn Availability Groups Primary Node field, enter the name of the client on the primary node.
Check that you entered the NetVault Backup Virtual Client name; do not enter a different name, such as the host name or SQL Server Instance.
19
If you are restoring the backup to a named SQL Server Instance, not the default instance, enter the name of the instance in the Instance Name, If Restoring to an AlwaysOn Named Instance field.
 
* 
TIP: Only enter the name of the instance. If you enter the fully qualified name, <HostName>\<InstanceName>, the plug-in ignores the hostname.
20
Click OK to save the settings, and then click Next.
21
In Job Name, specify a name for the job if you do not want to use the default setting.
22
In the Target Client list, select the same Virtual Client that was the target of the backup.
23
Click Save & Submit, and use the Job Status page to monitor progress.
Do not proceed until the Run Status is “Restore Completed.”
After the restore of the primary replica is finished, create a backup of the primary replica. After the backup is finished, use the new backup to restore each secondary replica.
24
In the Navigation pane, click Create Backup Job.
25
In Job Name, specify a name for the job.
26
Next to the Selections list, click Create New.
27
In the selection tree, open the first secondary replica that you are restoring, and then open the All Instances node.
The databases that were part of the AlwaysOn Availability Group showing “(Restoring)” after their names.
28
Select the All Instances node, and select Configure from the Actions menu.
29
Enter the security information, enter the applicable login information, such as (local), for the Instance Name, and click OK.
30
Repeat Step 27 through Step 29 for each secondary replica.
31
In the selection tree for the primary replica, select that databases that you are backing up.
These databases are the same ones identified as “(Restoring)” on the secondary replica.
32
Run a VDI-based, Full Database backup.
33
Using the same Selections set that you used for the Full Database backup, run an Incremental Transaction Log backup.
34
In the Navigation pane, click Create Restore Job.
35
In the saveset table on the Create Restore Job — Choose Saveset page, select the Full Backup of the primary replica that you completed Step 32, and click Next.
36
On the Create Selection Set page, select the databases that you want to restore, and click Edit Plugin Options.
37
In the Restore Type section, select With NO RECOVERY, click OK, and then click Next.
38
In Job Name, specify a name for the job if you do not want to use the default setting.
39
In the Target Client list, select the Virtual Client name of the secondary replica.
40
Click Save & Submit, and use the Job Status page to monitor progress.
41
Repeat Step 34 through Step 40 to restore the Incremental Transaction Log backup from the primary replica to the secondary replica.
42
From the secondary replica, use SQL Server Management Studio to add each applicable database to the AlwaysOn Availability Group.
Perform this step locally on the applicable secondary node.
43
Repeat Step 34 through Step 42 for each secondary replica that is part of the group.
Example of restoring a database that does not exist on the primary replica

The following procedure describes how to restore a database to an AlwaysOn Availability Group if the database was removed from the primary replica before the restore.

1
Select the data to restore.
For more information, see Selecting Online VDI data for restore under Restoring data from Online VDI backups or Selecting data for a VSS restore under Restoring data from VSS backups.
As described previously, you cannot use the same job to restore databases from multiple groups. Nor can you use the same job to restore a database that belongs to a group and a different database that does not.
2
On the Create Selection Set page, click Edit Plugin Options, and configure the applicable parameters depending on whether you are performing a VSS or VDI restore.
For information on the options that are common to all restore jobs, see Setting Online VDI restore options under Restoring data from Online VDI backups or Setting VSS restore options under Restoring data from VSS backups.
3
In the AlwaysOn Availability Groups section, clear the following check boxes:
•
Remove Database Secondary Copies from the AlwaysOn Availability Group Before Restore
•
Remove Primary Database from the AlwaysOn Availability Group Before Restore
4
Select or clear the Add Primary Database to the AlwaysOn Availability Group After Restore check box, whichever is applicable.
5
Complete the following fields (required):
•
Restore to the following AlwaysOn Availability Group: Enter the name of the group.
•
Enter the NetVault Backup Client Name on the AlwaysOn Availability Groups Primary Node (optional): Enter the name of the client that is running on the primary node. If you enter a name for a different node, the restore fails. If you are unsure which client is running on the primary node, use SQL Server Management Studio to determine which node is the primary node in the group.
6
If you are restoring the backup to a named SQL Server Instance, not the default instance, enter the name of the instance in the Instance Name, If Restoring to an AlwaysOn Named Instance field.
 
* 
TIP: Only enter the name of the instance. If you enter the fully qualified name, <HostName>\<InstanceName>, the plug-in ignores the hostname.
7
Complete the steps outlined in Finalizing and submitting an Online VDI restore job under Restoring data from Online VDI backups.
8
Perform a Full Database backup from the primary replica.
9
Perform a restore from each secondary replica that was backed up by the Full Database backup performed in Step 7.
Complete a separate restore operation for each secondary replica that makes up the primary replica.
10
Use SQL Server Management Studio to add the secondary replicas to the AlwaysOn Availability Group.

Renaming or relocating a database

The plug-in lets you restore a database to a different name during restore. The renaming of a database can be useful if you do not want to overwrite the existing version and want to create a copy of the database. You can also relocate the database to a different directory while restoring it with the plug-in.

 
* 
IMPORTANT: To make a copy of a database using the Full File and Filegroup Backup method, available only for VDI, it must be restored to a different SQL Server® Instance.

When renaming a database during a VSS-based restore, the database files must also be relocated to an alternate directory. If the database files are not relocated to an alternate directory, the restore fails. This failure is because VSS does not let you rename the database without moving the data and log files to a different directory. When relocating data and log files for VSS-based restores, you can relocate the data files to one directory and the log files to a separate directory if both directories are different than the original.
1
In the Navigation pane, click Create Restore Job, select Plug‑in for SQL Server from the Plugin Type list, select the applicable saveset, and click Next.
Select the database to restore from the backup saveset by following the instructions outlined in Restoring data from Online VDI backups.
2
With the database selected on the Create Selection Set page, select Rename from the Actions list.
3
In the Rename/Relocate dialog box, enter the applicable information:
•
Rename: Enter the new name.
 
* 
IMPORTANT: When renaming a database during a VSS-based restore, the database files must also be relocated to an alternate directory. If the database files are not relocated to an alternate directory, the restore fails. This failure is because VSS does not let you rename the database without moving the data and log files to a different directory. When relocating data and log files for VSS-based restores, you can relocate the data files to one directory and the log files to a separate directory if both directories are different from the original.
•
Relocate: Enter the new path.
The plug-in lets you relocate the log files to a directory other than the data files directory. To restore to separate directories, type in the paths to the directories where the data files and log files are to be restored. Enter the data file directory first, and then enter the path to the log file directory. Separate the two directory paths using a comma — no space must exist before or after the comma. The directory specified in this field must exist at job run-time.
4
To apply your changes, click OK.
* 
NOTE: In the WebUI, the database name is accompanied by the rename and relocate information in parentheses. The database files are renamed using a concatenation of the new name and the original name, that is, <NewName>_<OriginalName>.
5
Continue with the restore procedure as explained in Restoring data from Online VDI backups.
Documents connexes

The document was helpful.

Sélectionner une évaluation

I easily found the information I needed.

Sélectionner une évaluation