I had a new issue but I was able to recreate the FIB problem. This time I received these errors. Now I'm starting to wonder if it's because of controller giveback/takebacks. Yesterday afternoon I performed some testing of our NetApp controller failover and giveback. I’ve been doing some of that testing for about a month or so and although I don’t recall each time I did it, I definitely did it yesterday and now I’m having issues.
The current configuration –
4 Backup Jobs
o3 VMs backed up, all Virtual Appliances, Reversed incremental, monthly active full on first Sunday of each month
o 10/9/2012 failed
PrepStorageForWriteEx failed 'Z:\Backups\CH_APPLIANCE_BACKUP\CH_APPLIANCE_BACKUP2012-10-07T211541.vbk' Client error: The specified number of stored banks (1613797575) does not match to supported limit (744).
oAttempted resolution – Edit job and recalculate VMs to ensure they show up. Had to remove one VM and re-add to job. Job still fails with the above error.
o1 VM backed up, Reversed incremental, monthly active full on first Sunday of each month
Failed to save backup meta to 'Z:\Backups\CH_EXCHANGE_OS_BACKUP\CH_EXCHANGE_OS_BACKUP.vbm' [CHPVBR01] Failed to save file content. The file or directory is corrupted and unreadable. --tr:FC: Failed to create file. File path: [Z:\Backups\CH_EXCHANGE_OS_BACKUP\CH_EXCHANGE_OS_BACKUP.vbm]. Desired access: . Creation disposition: . --tr:Failed to call DoRpc. CmdName: [FcCreateFile] inParam: [<InputArguments><FilePath value="Z:\Backups\CH_EXCHANGE_OS_BACKUP\CH_EXCHANGE_OS_BACKUP.vbm" /><Desired
Attempted resolution – Edit job and recalculate VM to ensure they show up. Noticed that folder 'Z:\Backups\CH_EXCHANGE_OS_BACKUP\ is completely corrupted and will not open any longer. I ran chkdsk on the volume and it corrected issues and now I'm able to open the folder. Re-running the job now gives me the FIB error. - yay!
o6 VMs that include the Veeam B&R server, 5 proxy servers (3 offline). Reversed incremental, monthly active full on first Sunday of each month
One of the proxy servers, it was offline at the time, was not found. Removing and re-adding to the job and then restarting job allowed it to complete successfully.
o2 VMs backed up using standalone host method to ensure vCenter/Veeam DB server can be backed up properly. Reversed incremental, monthly active full on first Sunday of each month
oJob completed successfully with no issues.
I still have not moved this volume to be controlled by SnapDrive yet. I do have SnapDrive configured for my new Exchange server that we're building and testing and I'm not noticing anything like the above on it's NTFS volumes. My next course of action would be to remove the LUN and pass it through via SnapDrive.