Troubleshooting VSS backup and restore operations

Edit online

If you encounter a problem during VSS backup and restore processing, attempt to reproduce the problem in your environment.

Before you begin

If a VSS backup fails, verify that sufficient disk space is available to store the snapshot.

Procedure

  1. Try the operation that failed again.
  2. If the problem still exists, close other applications, especially those applications that interact with SQL Server, for example, antivirus applications. Try the operation that failed again.
  3. If the problem persists, look for information in the event logs: tdpsql.log and dsmerror.log.
    You can also review the messages in the Windows™ System and Application Event Log. Log entries might exist to help you identify the VSS event that triggers the issue.
  4. If you do not find a resolution to the problem in the log files, complete the following steps:
    1. Shut down the SQL Server or the computer.
    2. Restart the SQL Server or the computer.
    3. Run the operation that failed.

Troubleshooting issues with tail-log backups

Edit online

A database restore operation might fail if transaction log records in the tail of the log are not backed up.

About this task

During the restore operation, you might see the following error message:
Failed - An exception occurred while executing a Transact-SQL statement 
or batch.
The tail-log backup of the dbName database has not been backed up.
Use BACKUP LOG WITH NORECOVERY to backup the log if it contains work you 
do not want to lose.
Use the WITH REPLACE or WITH STOPAT clause of the RESTORE statement to 
overwrite the contents of the log.

RESTORE DATABASE is terminating abnormally.
Changed database context to 'master'. (HRESULT:0x80131501)
To resolve the error, complete the tail-log backup.

Procedure

  1. On the Protect tab of the SQL Server instance, click Show Backup Options and set the Back Up Tail-log option to Yes.
  2. On the Actions pane, select Log Backup to TSM.

Troubleshooting VSS offline restore of a master database

Edit online

Microsoft™ SQL Server only supports offline VSS restores of the master database. Data Protection for SQL Server does not support offline restore operations. Therefore, you cannot use Data Protection for SQL Server to restore the master database.

Procedure

  1. Ensure that the SQL Server is online.
  2. Restore the master database to a new database in Microsoft Management Console (MMC), or at the command line. For example: Enter the tdpsqlc command with the /recovery=no option.
  3. After the restore operation is complete, verify that all data files are restored successfully.
  4. Stop the SQL Server instance, and rename all data files of the master database.
  5. Copy all data files from the new master_restore database to the location of the master database. Verify that all data files are copied.
  6. Start the SQL Server instance and verify that the master database is restored successfully.

Troubleshooting SQL Server failover cluster limitations for VSS operations

Edit online

Certain limitations apply when you complete VSS operations in an SQL Server failover cluster environment.

Procedure

  • Ensure that all servers within the cluster use the same levels of IBM® Storage Protect, Windows, and other applicable software.
  • Install the IBM Storage Protect client acceptor daemon (CAD) on each cluster node so that it can continue operations if servers fail over. Ensure that the CAD service name is named the same on all cluster nodes so that it can be started by a generic cluster service.
    Tip: The local DSMAGENT client node must be a separate node from your normal backup-archive client because the CAD service must be a non-cluster option. When you use the remote DSMAGENT client node, you do not have to register a separate node for each server within the cluster.
  • Use the Microsoft vssadmin and diskshadow commands to verify the environment.
  • Configure a Data Protection for SQL Server configuration file for each node in the cluster.
    These configuration files are almost identical, except that the localdsmagentnode parameter points to the corresponding local DSMAGENT on each node.
  • If you run scheduled VSS operations in an SQL Server failover cluster environment, complete the following steps.
    • Install the IBM Storage Protect scheduler as a Windows service on all cluster nodes.
    • If the command file is on a local drive, ensure that the file remains consistent on all cluster nodes. Optionally, you can create the command file on a shared drive. Make sure that the objects parameter, which is specified with the define schedule command on the IBM Storage Protect server, points to this command file.

What to do next

To resolve timeout issues, schedule VSS backups so that enough time elapses between backups, or increase the copy rate of the IBM SAN Volume Controller or IBM Storwize® V7000 background copy.

Troubleshooting VSS limitations with IBM SAN Volume Controller and IBM Storwize V7000

Edit online

When you run a Data Protection for SQL Server VSS backup (non-offloaded) to a IBM Storage® Protect server, the IBM SAN Volume Controller or IBM Storwize V7000 LUNs can sometimes remain mapped to the Windows host even though the backup is complete.

Procedure

Use a backup destination other than IBM Storage Protect server (BOTH or LOCAL).

Results

When you run two Data Protection for SQL Server VSS backups and if the volumes are large, or the background copy rate is set to a low number, or both conditions occur, the second VSS backup might be presented to be in a hang state. Typically, the SQL Server data is on IBM SAN Volume Controller or IBM Storwize V7000 disks. However, the second backup is waiting for the IBM SAN Volume Controller or IBM Storwize V7000 background copy of the first backup to complete before proceeding. IBM SAN Volume Controller or IBM Storwize V7000 does not allow two background copies of the same volume to occur at the same time. You might not know that the second backup is waiting for the first background copy to complete.

You might also see timeout errors if the previous IBM SAN Volume Controller or IBM Storwize V7000 background copy takes too long.

What to do next

To resolve timeout issues, schedule VSS backups so that enough time elapses between backups, or increase the copy rate of the IBM SAN Volume Controller or IBM Storwize V7000 background copy.

Troubleshooting VSS limitations with IBM N-series and NetApp FAS series

Edit online

If you plan to run VSS backups with backup destination set to LOCAL, understand the limitations in the VSS Provider for NetApp FAS series and IBM N-series, and in SnapDrive 4.2 and earlier versions, that affect the way in which you can run your VSS backup operations. You must configure your environment correctly to avoid snapshot deletions, backup failure, and out-of-space conditions on the production volumes.

Before you begin

  • Ensure that a NAS file server LUN that is used by SQL Server databases is fully dedicated to the database. SQL Server databases cannot share LUNs.
  • Ensure that a NAS filer LUN that is used by SQL Server databases is the only LUN on the filer volume. For example, if the SQL Server uses four LUNs, four corresponding filer volumes must exist, where each volume contains one LUN.
  • If the NetApp volume type is Traditional, ensure that VSS backups with backup destination set to LOCAL are bound to a management class that has verExists=1. This setting is not required if flexible volumes are used.
  • Ensure that VSS backups with backup destination set to LOCAL are either a full or copy backup. You cannot mix local backups of type FULL and COPY.
  • Ensure that VSS backups with backup destination set to TSM are a full or copy backup. There are no restrictions on IBM Storage Protect backups.
  • When you run VSS backups, ensure that previous backups finish completely before you start a new backup. To avoid issues on SQL Server, the VSS service, and, the NAS filer, avoid backup overlaps.

About this task

The following backup procedure is an example that shows how to optimally run VSS backups by using both IBM Storage Protect and local backup destinations. The following assumptions apply to this example backup procedure:
  • Stated configuration requirements are in place.
  • Daily VSS full backups to a local destination occurs every four hours - 12 a.m., 4 a.m., 8 a.m., 12 p.m., 4 p.m., 8 p.m.
  • The VSS backup to IBM Storage Protect takes one hour to complete.
  • The VSS backup to a local destination takes five minutes to complete.

Procedure

Set your daily VSS full back schedule to run in one of the following ways:
  • Run daily VSS full backups to a local destination every four hours - 12 a.m., 4 a.m., 8 a.m., 12 p.m., 4 p.m., 8 p.m.
  • Run daily VSS full backups to IBM Storage Protect storage by one of the following two methods:
    • Set backupdestination to BOTH to run at 12 a.m. Because this setting runs a 12 a.m. backup to a local destination, do not separately schedule a 12 a.m. backup to a local destination.
    • Set full offloaded-backup to run at 1 a.m. No VSS local backup is available to restore VSS backups between 1 a.m. and 4 a.m., when the next VSS backup to a local destination occurs.
  • Set weekly VSS full backups to run to IBM Storage Protect, as an offloaded backup, at 5 a.m.