Restoring Oracle DB with ASM

[peterb]

Veeam support is unable to provide any documentation for backups and restores of OracleDB with ASM so i will try my luck here.
Running Oracle 12c on Oracle Linux using ASM disks.
I can run sucessfull backups, however when i try to restore, the restore fails on "Failed to rename mounted disk group REDO to REDO_001" (or any other disk group i try)
If i look at the bash history i can see that the restore runs

Code: Select all

renamed dgname=REDO newdgname=REDO_001

with some other parameters.
the question is:

How can a restore software try to rename a DG which has other production data on it?
The reason it fails to do so is obvious, but first it should not happen at all, right?

As i said, the Veeam support is useless in this case. They told me they have no documentation on requirements for ASM restores, neither they are able to explain how that restore works. Just the marketing

"Veeam fully supports image-level backup and recovery even for databases leveraging Oracle Automatic Storage Management (ASM), which is a popular Oracle deployment scenario since every competing vendor today only supports via agent-based, file-level backup and recovery."

So i hope there is someone in this community with some experience who can bring some light into this.

[PTide]

Hi,

Would you provide case ID, so we could fetch some additional info from the conversation that took place between you and the support team?

Thank you

[tsightler]

If i look at the bash history i can see that the restore runs

Code: Select all

renamed dgname=REDO newdgname=REDO_001

with some other parameters.
the question is:

How can a restore software try to rename a DG which has other production data on it?
The reason it fails to do so is obvious, but first it should not happen at all, right?

The way that Veeam performs restores with Oracle on Linux is by presenting the disk images from the backup to the restore target system. This is especially important with ASM because we need the Oracle tools to be able to access the ASM volumes.

The thing is, when we present these disk images from a previous point in time, they will have the same disk group name as your production disk groups, so we use the renamedg command to rename the not yet mounted ASM disk to a new name so that they will no conflict with the running production disk group that is mounted. This is one of the primary purposes of renamedg, to allow renaming of cloned disk groups (for example with storage snapshots), which is, at a practical level, very similar to what we are doing, i.e. presenting clones of your active disk group from a prior point in time.

I'm not sure why the rename is failing in your case, but proper log investigation should be able to reveal this. I'd suggest asking for a support escalation, although, as Pavel requested, if you can provide your case ID it can be investigated on our side.