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 |
|
|
|
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: |
|
Navssprv Event ID 4356: |
|
SnapDrive Event ID 191: |
|
SME: |
|
|
|
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: |
|
Last updated: 26 MAR 2007 |
Related Blogs
- Related Blogs on NetApp
- Moshable Music
Just recently I had to troubleshoot 2 vss_e_unexpected_provider_error errors regarding Snapmanager for Exchange. As it turns out Snapdrive is critical. Check out Snapdrive, disks and make sure the luns show and the path looks good.
Both cases showed an odd path error.
I shutdown all exchange services. Used Snapdrive to forcefully disconnect the luns. I then reconnected using snapdrive and CIFs shares (yes, you have to share out the database and log volumes).
Started Exchange and performed a successful backup. Problem solved.
Thank you Chauncey Willard.
Also is very important to ensure that you have enough space on exchange volumes.
I saw lot of VSS errors caused by disk space problems
great.. i will try it now, thanks
Rescolved: VSS_E_UNEXPECTED_PROVIDER_ERROR
Sorry, this is a solution to a slightly different, but similar error: VSS_E_UNEXPECTED_PROVIDER_ERROR. SnapManager will often fail with this error despite restarting SnapDrive/ Virtual Disk Service/ Volume Shadow Copy etc. If you go through the Event Viewer, you will notice in 1 of the errors that it specifies a particular volume which is out of space, hence stops the process. Alternative, Take snapshots individually of all LUNs involved – snapshots of atleast 1 would fail and this is your point of error.
I had to reduce my fractional reserve from say 100% to 80% (even though I had no snapshots for the particular volume.)