Feature Request: Fail if DB not found by App Aware Processing

[segfault]

We recently had an issue where the /etc/oratab file was missing on a pair of servers and thus log processing was not occurring on two of our Oracle VM's with no errors or warnings to point us in the right direction. (Oracle was fine since it does not need that file. Nothing in our environment cares about that file except for Veeam.)

Even with app aware processing set to "require success," the backup otherwise finished with no errors. It seems that the "require success" flag only applies to apps that Veeam finds, and an empty list of applications is not a cause for concern.

It would be nice if for policies with the "Require successful processing" option set, Veeam would return a failure or at least a warning if it does not find an application to process. Bonus points if it we can also specify which app Veeam should find. (e.g., this is an Oracle box. If you don't find oracle on it, then fail.)

--john

[PTide]

Hi,

It seems that the "require success" flag only applies to apps that Veeam finds, and an empty list of applications is not a cause for concern.

Right, that's exactly how it works.

It would be nice if for policies with the "Require successful processing" option set, Veeam would return a failure or at least a warning if it does not find an application to process. Bonus points if it we can also specify which app Veeam should find. (e.g., this is an Oracle box. If you don't find oracle on it, then fail.)

This one draws some questions, such as "how do we tell for sure if the app is (not)present to avoid false positives?". Specific config files (seems to be not very reliable, right), specific packages installed (those usually have versions changing, so will have to use masks), services running (what if the app's been shut down?), or something else? Don't get me wrong, I am not asking you to provide a solution, but it would be interesting to hear your opinion on the subject.

Thanks!

[AlexB82]

If the application isn't working/missingon your server, wouldn't that present itself as a bigger issue like your services not working?

I think it would be good if Veeam could notify to say "x database has been removed since last job", similar to how you get the current warnings for "x VM is no longer processed by this job - check this is correct".

[PTide]

The fact that /etc/oratab is missing from the servers most likely means that the final step of Oracle installation where it asks to run certain scripts manually has been ignored. Although the database itself can work without it, certain Oracle tools rely on that file. Taking that into account, I'd suggest that maybe it would make more sense to fix that couple of servers than to adjust the existing and working mechanisms in the product?

Alex,

I think it would be good if Veeam could notify to say "x database has been removed since last job", similar to how you get the current warnings for "x VM is no longer processed by this job - check this is correct".

Sounds reasonable, thank you for your suggestion.

Thanks!

[segfault]

This one draws some questions, such as "how do we tell for sure if the app is (not)present to avoid false positives?". Specific config files (seems to be not very reliable, right), specific packages installed (those usually have versions changing, so will have to use masks), services running (what if the app's been shut down?), or something else? Don't get me wrong, I am not asking you to provide a solution, but it would be interesting to hear your opinion on the subject.

The way I envision it working is a variation of the existing "require success" flag that would fail/warn on any issues, including not finding anything to do. So if it is a linux box and it can't find the oracle/mssql config files it should issue a warning. If the packages are there but there is no db found, issue a warning. Basically I'd like the ability to say "this is a database server: if you don't find any databases, then I want to know about it so I can figure out what is wrong."

I'd suggest that maybe it would make more sense to fix that couple of servers than to adjust the existing and working mechanisms in the product?

That is what we did. Normally we can rely on Veeam to flag a warning / failure to the VM so we know to investigate the system. And for things like a bad password it works great. In this case, there was no warning or error so we did not go looking. It was not until we noticed that the log backups only were showing 3 of the 5 vm's that we started to dig deeper.

Side note: In the unix world, the lazy dba just installs an oracle home on one system and then rsyncs over the entire thing to other systems. It saves them a good bit of time to deploy oracle to a handful of systems. Yeah, there are better ways to do this, but old habits die hard for a platform with a 30+ year history behind it.

--john