Veeam Backup - VCB/SAN vs VCB/NBD -- odd behaviour

[cby]

Using Veeam Backup 3 on Windows 2003 server std ed. sp2.

Backed up three vdisks comprising two VMs each on the ESX hosts to FATA. Five of the VMs were backed up using the VCB/SAN option and one using VCB/NBD. All seemed fine except when it came to restoring the VMs. Of the five VCB/SAN backups only two could be started in vmplayer once restored, the other three threw up this error:

Disk /dev/sda doesn't contain a valid partition table

Worrying to say the least. Restored back to the SAN and the ESX could not find a boot partition. Not sure why there weren't issues with the other two VMs backed up with VCB/SAN option.

The VM using VCB/NBD during backup restored fine. In fact I backed up all six machines with VCB/NBD and restored them without a problem. I've left the schedules running with NBD and the backup times do not seem to be disiimilar to those when using the SAN.

I was wondering if anyone else had encountered problems with VCB/SAN.

The only thing that springs to mind is that there was a lot of activity on the SAN and possibly congestion on the fibre channel, leading to data corruption? One option may be to implement a preferred path when backing up to FATA.

[ssimakov]

VCB has internal data integrity checks so I don't think data corruption occured. Could you please elaborate on how virtual disks are configured for this VMs? Also you may try to run vcbMounter manually and then check if VMDKs may be mounted successfully.

[cby]

Sorry for the delay in responding.

Made some investigations to confirm the paths to disks were correct. I re-ran a VCB/SAN backup last night. That is, 6 VMs on 3 LUNs. Started the backups at 10 minute intervals. Results were:

Backup #1 - completed successfully
Backups #2 and #3 both failed with the following error:

VCB error: No path to device LVID:499b07c6-500c3931-8d18-0022649bef3e/499b07c6-3cd34a39-320f-0022649bef3e/1 found. Error: Failed to open the disk: Cannot access a SAN/iSCSI LUN backing this virtual disk. (Hint: If you are using vcbMounter you can use the option "-m ndb" to switch to network based disk access if this is what you want.) If you were attempting file-level access, stop the vmount Service by typing "net stop vmount2" on a command prompt to force vmount to re-scan for SAN LUNs and re-try the command. An error occurred, cleaning up...

The only issue I can think of is that backup #1 was still running when #2 & #3 kicked in. I'll set up a scheduled job to back up the 6 VMs sequentailly via the SAN -- I suspect it will be successful.

In the meantime I have contacted our supplier's tech. support for their views.

[ssimakov]

By the way, what storage do you use?

[cby]

EVA 4400 with FC to SAN. Backup copies from FC to FATA