Noone is using the plugins for Oracle RMAN or SAP HANA and has experience with them?

in current deployment for us for Oracle and Sap, we did some tests before. We don’t have enough experiences to provide some review at the moment 

Our database administrators don’t believe in Veeam BR but we need to this experience for our LTR project. Our customer needs keep backups for one year and restore it for checking financial records. I guess that RMAN plugin and native tape support will good choice for us. 

Hi Davoud,
as far as I have seen you cannot select a tape reprository as a target for RMAN backups. You have to use a disk repository and copy the backup files to tape afterwards.

This would be a nice feature to get direct tape suport with the plugin jobs...

Hi JMeixner,

We actively use the RMAN Plug-in. On the SAP side, we have integrated veeam directly with SAP HANA hardware. Performance and backup tasks are all successfully.Is there anything you are particularly curious about?

Hello @bynalbant ,
have you used one of the plugins with classic SAP?

@JMeixner 

Yes, we used Oracle RAC and ASM disks on a physical server.We are working smoothly.

Hello @bynalbant ,
are you using the brtools for backup of the SAP database? Or are you doing a “pure” RMAN backup?

@JMeixner We do not use brtools. rman plugin is successful enough, we don't need an extra copy.

Hi there,

we use brtools with Oracle RMAN Plugins cause we used Tivoli Storage Manager before and all backup and SAP guys are used to it. Works fine.
Any specific question here?

We also use SAP Hana Plugin without greater issues.

Only thing is: B&R Server needs a lot of CPU cores to handle normal VM backups and all our SAP Hana (~25) and Oracle RMan (~10) backups. And we got to a point where backups could not be handled and ran into a timeout.

Used couple of times with SAP HANA… not difficult to install but the biggest challenge was to convince SAP admins to install the plugin in their “toy”…

Now SAP recommend veeam for backuping Hana, things changes hehe. Can’t wait to play with hana, it will at the beginning of 2021 for us.

Like we’r talking Oracle things, we are impatient to try instant recovery oracle on production. Little bit affraid by how our backup repo will support the load during the total recovery.

Just found this thread now. We had to leverage this with a customer. I like the fact that scheduling and job control is in the hands of the Oracle DBA. I was disappointed to see that backup copy jobs to cloud connect are not supported.

Yes, copy jobs are a problem in general. The plugin jobs are not recognized by any copy job. I don't know if this was changed in V11, this special client is not on V11 up to now. I will have to try in May, as the upgrade is planned for end of April...

The only possible way to copy the plugin data I found was to create a file copy job which copies the repository directory...

I could be mistaken but I think you can put them in normal backup copy jobs not just to cloud connect.

Quick check of V11 docs and it looks to be there for sure now. Again I think we did see that before but.. being a cloud connect provider did not help much. It would be interesting to find out they have not done that yet.

https://helpcenter.veeam.com/docs/backup/plugins/backup_copy.html?ver=110

I will try in some weeks…

Thank you.

I was asking this same question recently and did not get any “real-world” responses. I have a customer that is deploying this at scale and I’ve been assembling some best practices. The biggest issues were resolved with v11, and the metadata improvements. One task = 5 channels, so plan repository resources accordingly. If doing a backup copy job, make sure you keep that in mind as well - limit the tasks on the target repo so it doesn’t suck up all the task slots on the source and hang up the RMAN jobs (especially the archived redo log jobs). I recommend increasing the registry settings for max user ports to 64K and shortening the TCP timed wait delay to 30 seconds. Summary of the big points.:

Recommendations for infrastructure optimization:

1. Set a backup window for backup copy jobs? No, no need.
2. Reduce tasks on the BCJ target repositories, set to 20 or 30 per extent server
3. BCJ can be set at repo level if there are two Oracle repos with different retention (e.g. for Prod and Non-Prod), or at job level if all RMAN backups go to one repository if you want different retention periods.
4. TCPTimedWaitDelay - default 240, set to 30
5. MaxUserPorts default 5000, set to 65536
   1. Do this on the Backup, repo and preferably on the database servers

Thank you @randyweis  for your detailed response. I am anxious to try this with V11.

You’re welcome. I should have edited item 2, since those numbers related to a ratio of cores on a physical server. It would be better put as “Reduce tasks on the BCJ target repo servers to 10-20% of the tasks allocated to the RMAN plugin tasks.”

Hope that helps.

Two more points (this might go on all day...)

1. Dedicate the repository to Oracle RMAN in large environments. Don’t mix in VM workloads. This is both a resource issue and a configuration issue. See the point below.
2. If targeting a SOBR, use the Performance Data Locality policy, so load balancing is based on available compute resources (cores). Note that this means that any Oracle database and redo log backups will likely be spread across extents. This setting works for plug-in backups since there is no Full and Incremental backup from Veeam’s perspective.

Yup, two more points (this is helping me put my list together...):

1. Immutability will not be applied to RMAN backups, if sent to a Linux repository set for immutability.
2. Fast Cloning will not apply to RMAN backup files.

Yes, an separate repository is very useful ans makes absolute sense for the RMAN backups.

All backups are single backups an no chains with synthetic fulls, so the block cloning has no effect.

What I have seen is that the deletion of outdated backups is not done by RMAN in all cases. Therefore it is very useful to set the force deletion option for the plugin and set it to some more days as your retention period.
See more information about this option here:
https://helpcenter.veeam.com/docs/backup/plugins/force_delete_rman.html?ver=110

A few more points:

1. Immediate copy is the only choice for Enterprise Application Backups. This has a bearing on managing how the BCJ impacts resource consumption and scheduling.
2. RMAN script: Every backup job process includes the following three phases. Ask customer to separate the catalog resync from the backup/crosscheck steps. The three way connection needed among the database server, Veeam backup server/repo and the RMAN Catalog Database can prolong the duration of the RMAN plug-in backup job.
   1. Backup
   2. Crosscheck
   3. Catalog resync
3. RMAN – dig into the details of how backup jobs are scripted, since this will impact your concurrent task slot usage and duration of each phase.
   1. How many backup files per set?
   2. How many channels per database backup?
   3. How many channels per redo log backup?
   4. Does the backup method include Full (level 0) and incrementals (level 1-9), or cumulative incrementals?
      1. Full backups daily will consume more repository space, prolong the backup job and prolong the backup copy job
4. Make sure that IPv6 is disabled on any Veeam infrastructure component, and if possible, on the Oracle database server NICs. https://www.veeam.com/kb2903

Huge amount of awesome informations for Oracle @randyweis , thank you very much from me and my dba