We use NetApp CIFS'S shares as backup targets and see some strange errors. Has anyone seen this in context of Veeam and backup to CIFS shares? Currently CA is not activated on NetApp Shares.
Network Attached Storage (NAS) able to present its capacity as NFS share (protocol version 3.0 and 4.1 only) or SMB/CIFS share (any protocol version). Using SMB protocol for non-continuously available (CA) file shares is not recommended for reliability reasons. NFS shares are supported both for direct operation and when mounted to a Linux repository server.
Please keep working with support but if I read as a non r&d person, it feels that "\\vdenasvea12a\Veeam01\BJ-DE-ViCluster21-2-WOP\BJ-DE-ViCluster21-2-WOP.vbm" is not readable or does not exist. Could you manually verify that part?
Another month has passed and we still have no solution for this problem.
- we enabled Continuous Availability on NetApps
- we changed some regkeys on Veeam servers to 0(FileInfoCacheLifetime, DirectoryCacheLifetime, FileNotFoundCacheLifetime)
- we rechecked AV (Kaspersky) settings on Veeam servers, we have no indication that AV is interfering with Veeam
- we installed a script on each Veeam server that checks access to a test directory on the affected shares, no error
- we installed a script that checks the existence and readability of first x bytes of all vbm files on shares, no error
Still I see this "Failed to compare two elements in the array" error each day in my job logs. Sometimes just a few, other times more. And it's always the vbm file that is the problem.
Here is a filtered output from SVC.VeeamInstallerDll.log from a time were the problem happend (log filtered for FC.*BJ-DE-ViCluster01-1-WBE.vbm). Is it possible that multiple jobs are trying to change the vbm file at this time?
[EDIT] I tried to understand what happens at this time. For me it looks as Veeam is trying to access the vbm file before is was renamed from .vbm.temp to .vbm. But maybe I'm reading the log not correct.
Kindly don't post debug logs into the forum posts, as requested when you click New Topic.
You really should not be wasting your own time trying to figure out the issue from debug logs by yourself. Neither this is something for the team behind this forum to do. It's on our support and R&D engineers to tell you exactly what is the issue is, based on the debug logs and/or troubleshooting steps they determine.
Any time you feel support case is "stuck", the best way forward is to escalate it using the Talk to a Manager functionality in the Сustomer Portal. This note will go directly to the support management, who will assign someone from the higher support tier to review the case. So please don't hesitate doing this any time you have "Another month has passed and we still have no solution for this problem" type of situation.
Yay \o/, it's a bug! I finally can stop flooding Veeams sftp server with logs. Now I just need to convince someone that we get a hotfix because we won't jump on v11 right after go live.