SnapManager jobs fail

Posted on April 3rd, 2008 in Backup Exec, Excahnge 2003, NetApp, Other by Gil Kreslavsky

After a backup job run you receive error messages.

Backup SG [First Storage Group] Error: SnapManager detected the following Exchange writer error. Please retry SnapManager operation.

VSS_E_WRITERERROR_RETRYABLE: The writer failed due to an error that might not occur if another snapshot copy is created.

Backup SG [First Storage Group]: Failed

Backup failed.

Error Code: 0xC00413CA

SnapManager detected the following Exchange writer error. Please retry SnapManager operation.

VSS_E_WRITERERROR_RETRYABLE: The writer failed due to an error that might not occur if another snapshot copy is created.

After few hours of check I found out that the guilty one is Backup Exec Agent..

Even found article on netapp, Actualy I just removed BackupExec agent, and started to use alternative backup solution , but you can follow the article.

SnapManager for Exchange (SME) backup fails with VSS_E_PROVIDER_VETO


Symptoms

SME backup fails with VSS_E_PROVIDER_VETO

After a reboot of the Exchange Server (either clustered or non clustered), the first SME backup works fine.

The next (and the following) backup(s) fail with VSS_E_PROVIDER_VETO:

VSS Event ID: 8193:
Volume Shadow Copy Service error: Unexpected error calling routine DeviceIoControl(IOCTL_VOLUME_SET_GPT_ATTRIBUTES). hr = 0×800700aa

Navssprv Event ID 4356:
NetApp VSS hardware provider’s AbortSnapshot method is called [SnapshotSetId={c1bfe1c1-a6f7-4636-adad-8d60515123e8}]
VSS has failed the current shadow copy session because the previous errors are not continuable

SnapDrive Event ID 191:
Failed to create a consistent snapshot({c1bfe1c1-a6f7-4636-adad-8d60515123e8}) of the virtual disk(s) [J: I: E: F: G: H: ]

SME:
Error in calling VSS API: Error code = 0×80042306 Error description: VSS_E_PROVIDER_VETO (Error Code: 0×80042306)


Solution

Follow these steps to determine the root cause:

1. Take a manual snapshot using SnapDrive and mount a LUN in that snapshot. If this is possible, then this is not a SnapDrive problem. Go to the next step.

2. Ensure the SnapDrive account in a member of the local administrators group on both the filer and the host.

3. Is a preferred IP Address configured? If not, configure it. In SnapDrive 3.2 and above, this can be done in the SD GUI by right-clicking on “Disks” after expanding “SnapDrive”. Choose properties from the pop-up menu and then go to the “Preferred filer” tab. Enter the filer name and the preferred IP address in the respective columns. The PIP should be a public interface on the filer NOT the private interface used for ISCSI-BLOCK traffic.

4. Make sure that no non-Exchange/SQL data is being stored on the LOGS LUN.

5. Make sure that a stand-alone VSS Hardware Provider from SnapDrive 3.0x has not been installed. This can be checked by running “vssadmin list providers” anywhere on the SnapDrive Server. Only two providers should be listed. If doing an upgrade from SnapDrive 3.0x, then completely uninstall SnapDrive 3.0x and the Hardware Provider first. Then install SnapDrive 3.1x from scratch.

6. Is Veritas Agent used for backing up SnapDrive Server? If so, using Volume Shadowcopy Service (VSS) and Veritas Snapshot Provider (VSP) can cause volumes to become marked read-only. Check the version of the “vsp.sys” driver. If it is less than 1.4, upgrade it. To download the updated driver and to get more info on this problem read the following Veritas Article .

Check for the following file: windowssystem32driversvsp.sys. If the file version is 1.03, either remove the “Veritas Remote Backup Agent ” Or update vsp.sys to version 1.04 (Veritas Hotfix 272771). After installing Veritas Hotfix 272771 (vsp.sys and vspapi.dll), multiple SME backups will work fine.

Related links:
Veritas Backup Exec: http://seer.support.veritas.com/docs/272771.htm
NetBackup: http://seer.support.veritas.com/docs/272814.htm

Last updated: 26 MAR 2007

Related Blogs