From an Oracle perspective the only supported method to backup databases on ASM would be via RMAN so I wouldn't expect any other answer from Oracle. However, that doesn't mean that it won't work, as long as you restore all ASM disks together, the database will be able to start and perform media recovery just like backing up a database without ASM.
The entire purpose of the 80-oracleasm.rules is to persistently bind logical device names, like /dev/sdb, to the physical devices based on SCSI ID so you are indeed using persistent binding, which is likely the cause of the problem in this case. Why is this a problem? Well, in the physical world this command would query the physical SCSI device for it's ID and map the same logical device name to it each time, however, in the virtual world this can get a little tricky since the SCSI devices are virtual.
Since the SCSI devices in a VM are virtual, VMware has to generate a UUID each time a new virtual disk is created. You can see this ID in the VMDK file as it typically looks like this:
Code: Select all
ddb.uuid = "60 00 C2 99 3c 65 28 48-12 a3 f3 e6 eb b3 b5 19"
Because this ID is really just "fake" VMware normally doesn't even pass this UUID to the host, and querying a virtual SCSI disk for the UUID will actually just return a null value, however, for applications that require the UUID you can enable the VMware advanced parameter "disk.EnableUUID=true" at which point this UUID is exposed to the guest OS. I'm guessing the VM you are referring to has this setting configured since that's quite normal for VMs using ASM.
However, when you restore an entire VM, it's a new VM with newly created virtual disks, and thus with new virtual SCSI UUIDs. This would effectively be the same as if you imaged existing physical disks to a new physical disk, the new physical disk would have the same data, but a different UUID.
There are several ways to work around this, perhaps the easiest is to just edit the ASM persistent rules to the new UUIDs, however, if you want to simply preserve the SCSI virtual disk UUIDs after restoring the VM you can use the following procedure:
1. Restore entire VM (don't power on)
2. Use the "Restore VM Files" to restore the VMDK descriptor files only (not the "flat" VMDK files) to the Veeam server
3. Use the vCenter Client File Browser or the Veeam file management feature to copy the VMDK descriptors files over the existing VMDK descriptors on the datastore.
4. Power on the VM and verify that SCSI UUIDs are consistent.
This would be slightly easier if Veeam allowed the VMDK descriptors to be restored directly over the existing ones but doing that directly from the "Restore VM Files" wizard wipes out the flat VMDK file for some reason (it does give a warning that it will do this). However, copying the VMDK descriptors via the Datastore browser or via the Veeam file management GUI does work fine and is not complex.
