v12 Plugin for Oracle RMAN Is Broken

[dmtinklenb]

I opened this case (Case #06375330) in October and there has been no resolution.

To be clear, our Oracle RMAN backups are managed by RMAN on the database server, not by Veeam.

Since the upgrade to v12, when a new Oracle RMAN backup job is created, the first time it runs and does the directory creation on our Linux repository, the directory is created with apostrophe's to deal with the spaces in the job name instead of using underscores to deal with the spaces as it did in previous versions of the Oracle RMAN plugin.

Directory Name Example:

v11 - hostname.domain.com_Oracle_backup__Le_Mars_RMAN_1_
v12 - 'hostname.domain.com Oracle backup (Le MarsRMAN 1)'

While the backup job works with this different naming format, the offload to AWS job fails because it can't find the backup files. Obviously, the job is looking for the older naming format. Older RMAN backup jobs that were originally created with a v11 or older plugin work just fine.

This also effects database restore/cloning from the backup of an older job to any of the new database servers that use the new naming format.


I was told by support that they know what the problem is and it should be fixed in v12.1. Well, that didn't happen. We are still seeing the same behavior using the v12.1 plugin.

When I let support know it still doesn't work, this was the response:

"I have clarified this and found that the issue should be corrected in the current version and new jobs created should use the correct format."

So the reason for this forum post is that I don't know what I'm supposed to do now. I'll continue to work with support but if they're telling me it's fixed in the current version and we're seeing that it's not, I don't know where else to turn. Very frustrating.

[PetrM]

Hello,

Maybe it's my bad but I hear for the first time that the job name string format was changed. Please let me clarify the issue and update this topic once I have more information.

Thanks!

[PetrM]

@dmtinklenb it looks like there are some unrevealed environment specifics that led to the issue described above. The conclusion made by our engineer is based on debugging and detailed logs analysis, effectively, it was fair to assume that the problem should have been solved in 12.1, however, in this case the problem turned out to be more sophisticated than it seemed at first glance.

I started two parallel discussion threads with the support team leaders and our developers, we work on it. Stay tuned.

Thanks!

[dmtinklenb]

Ok, thanks for the update. That's more information than I've received from support.

[PetrM]

Hello,

We had a quite productive meeting today on which we defined the next steps for further analysis. Long story short, there is an idea of the potential solution but our engineers need to collect more information about your infrastructure to validate the hypothesis. Please continue working with our support and provide our engineers with all the requested info. In addition, you're very welcome to share your concerns, thoughts, and feedback over here.

Thanks!

[dmtinklenb]

I plan on providing any information requested, which I have been doing for the past several months, however now seems like a really bad time for Veeam to switch ticketing systems. The original ticket was closed in the old system and new one created in the new system however all of that information I sent in the past is not in the new ticket, so the engineers, once again, asked for VBR logs, RMAN logs and a copy of the database. Now I have to spend my time, along with the time of our DBA to gather all this information which has already been supplied in the past.

[PetrM]

Hello,

As far as I understand, our last idea of a workaround did not work but you fixed the issue by changing the backup approach to not split the job between two different repositories as the v12 performance optimizations allow you to get the desired processing rate using a single repository. I'm glad to know that the solution was found and everything works. However, I would appreciate it if you could clarify how exactly you split the job because it could help us to build a similar environment and continue the research internally.

Also, please keep in mind that you always can request an escalation of a support case if you feel that it's not on the right track.

Thanks!