Backup of VM Linux running Oracle

[ARosenstand]

HI all

After doing some searching around the web, I aren't finding anything to answer my call properly, so I am hoping that some of you may have an idea.

I'm running Veeam B&R and it's taking backup of one of my VM.
That VM is running RedHat Linux, with Oracle.

Oracle DB backup are handling by RMAN and perform it's backup to a seperat location, so Veeam are not handling the RMAN backup.

But when Veeam B&R is performing backup of the VM, it's perform an timeout to the Oracle services, so each DB have a timeout, where access to the DB is disconnected.
This is shown up in Oracle as: "VKTM detected a time drift"

Unfortunally some of our applications are so affected by this, that they craches when it happens, and then needed to be manually started again.

Veeam B&R is performing "Hot Disk Backup" of the VM, through a Backup Proxy.

But are there a better way for performing backup of an VM running Linux with Oracle, there may not have the same impact?
VM running in VMware 7.0 on Dell VRTX hardware.
Veeam running on seperat Dell Physical server with 10Gbit connection to Veeam Proxy, running on the same Dell VRTX hardware.

Thanks.

[Andreas Neufert]

Looking from the outside without access to the environment or logs it is a bit hard to guess. So let´s discuss usual things and how you can test it.

1) Veeam is creating normal VMware Snapshots for backup and remove those snapshots. During that time, VMware freezes the VM for a very short period of time. This is by design of VMware and usually does not affect the applications. But in several situations under high load or if the storage backend has already a higher latency, this can affect the VMs.
You can verify it by checking how long the backup took. Then at nearly the same time, go to VMware and create a snapshot (without quiescence and without memory dump) then wait the same amount of time as the backup would have taken and remove the snapshot. Check if your application is affected the same way. Perform it multiple times to see if you can reproduce.
Workarounds if this is causing the same issues:
a) Reduce IO and change load during backup (VM Snapshot window). Less changed data means faster snapshot (removal) processing. For example do not backup with RMAN while doing image backups.
b) Work with VMware on optimizing the configuration and let them know that your application is affected while VM snapshots are processed (independent of Veeam confirmed with the test above).
c) Use our Storage Snapshot Integrations if possible/compatible as it reduces snapshot lifetime and so the snapshot removal is way faster (less stun).
d) Backup with our Managed Agents as it is not using any VMware VM Snapshot (you can restore as VM then and use even instant restore to VMware as needed).

2) Sometimes customer face some application issues (mainly on Linux) when VM Snapshots are mounted by VMware across ESXi nodes. For example VM runs on Host1 but HotAdd Proxy is on Host2. This is usually only an issue if you have a high latency environment with an NFS backend. To workaround the issue, you could move the HotAdd Proxy to the same host as the VM is running (temporarly for testing) and select in the Veeam Job this specific Proxy. Run the backup and see if this solves the issue. If this solves it, you can rollout more small proxies to all hosts and enable SameHostHotadd processing in the registry. See https://bp.veeam.com/vbr/3_Build_struct ... phere.html
Another option for testing is, to switch the Proxy temporarly to NBD-Network mode in the settings, we read then data from VMKernel interface of the specific host where the VM runs.

Maybe it is a combination of boths.
The above are things that you can test on your own, if you still face issues after testing this, please open a support ticket at Veeam.