cancel
Showing results for 
Search instead for 
Did you mean: 

Quiesced Snapshot fail with transport mode SAN, but LAN bkps snap its OK.

Hello everyone!

I am having trouble backing up some VMs with "quiesced snap" functionality via SAN. These fail with status 6..11. I have validated that the volumes are presented to the Appliance, and we are OK. When trying backups with "quiesced snap" via LAN (nbd) they run without problems, but when trying via SAN they fail.

This does not happen for all VMs, it is an isolated case.

I understand that Veritas recommends running backups with a "quiescing snap" to validate the integrity of the data. So we have a lot of VmWare policies with File Level Recovery (granular bkp) functionality, and we are concerned that by taking backups without "quiesing snap" we risk losing data, or its integrity.

Any ideas why this could be happening?

I understand that when snapshots cannot be generated with "quiesced snap" (status 156), vmware tools and VSP services must be validated on the VM. But this is not the case, the snapshot jobs do not fail with status 156, the snapshot is created but when "backing up the VM" the backup channel fails with status 11..6 etc.

My environment is a NBU Appliance 5230 ver. 3.1, NetBackup 8.1.2.

Please, if you need more information please comment.

Tags (2)
1 Solution

Accepted Solutions
Accepted Solution!

Re: Quiesced Snapshot fail with transport mode SAN, but LAN bkps snap its OK.

Hello
Vxms log with VERBOSE 8 can only help investigate further. Please enable it on backup host and rerun the job.
Post the logs here if possible.

View solution in original post

2 Replies
Accepted Solution!

Re: Quiesced Snapshot fail with transport mode SAN, but LAN bkps snap its OK.

Hello
Vxms log with VERBOSE 8 can only help investigate further. Please enable it on backup host and rerun the job.
Post the logs here if possible.

View solution in original post

Re: Quiesced Snapshot fail with transport mode SAN, but LAN bkps snap its OK.

Hello,

Sorry for the delay, the solution was to raise the verbose of the log vxms to 8. I found the following in the vxms_provider Log:

03/31/2021 12:43:57 : g_vixInterfaceLogger:libvix.cpp:1805 <DEBUG> : [VFM_ESINFO] 2021-03-31T12:43:57.203-03:00 error -[7F34684F8780] [Originator@6876 sub=Default] San transport error: I/O Operation failed.

03/31/2021 12:43:57 : g_vixInterfaceLogger:libvix.cpp:1805 <DEBUG> : [VFM_ESINFO] DISKLIB-LIB : RWv failed ioId: #387639 (4096062) (62) .

03/31/2021 12:43:57 : g_vixInterfaceLogger:libvix.cpp:1805 <DEBUG> : [VFM_ESINFO] VixDiskLib: Detected DiskLib error 4096062 (One of the parameters supplied is invalid).

03/31/2021 12:43:57 : g_vixInterfaceLogger:libvix.cpp:1805 <DEBUG> : [VFM_ESINFO] VixDiskLib: VixDiskLib_Read: Read 256 sectors at 109346752 failed. Error 16000 (One of the parameters supplied is invalid) (DiskLib error 4096062: One of the parameters supplied is invalid) at 5235.

DiegoRS_0-1617632989803.png

So, I looked more about the errors and was able to apply the following technical note.

- Rescan the LUNs and also sanity-reboot the appliance, which solved the problem.

https://www.veritas.com/support/en_US/article.100042898

 

Thanks for the help !!

 

PD: I can't load the log file because its size is huge.