I have 3.1.2 Virtual (ROBO) appliance. I have configured email notification via Settings\Alerts\Email and it looks ok. So I have defined Software+Hardware Admins and when I issue Email Test they receive the test email.
According to the documentation, Software Admin should then also receive "An email of your catalog backup disaster recovery file." (Admin Guide, page 270). But I have performed many tests (catalog Policy runs with Email Checked/NoChecked, when checked then with Software Admin email) but email has never been received.
Solved! Go to Solution.
Did you add valid email address in the E-mail address box under Disaster Recovery tab in hot catalog policy??
I am having ca 20 NBU appliances and this is working quite well everywhere... well not the ROBO as you - but I assume this is the same piece of software but running in a VM....
I have the same issue here with master runing on virtual appliance N3.1.2.
I guess it is a defect of N3.1.2 on virtual appliance.
I am agree with Quebek, it used to work with physical appliance (at least with N3.1.1).
I did not configure physical appliance with master role running N3.1.2 ...
Any other idea ?
All of the physical appliances we upgraded to 3.1.2 no longer send DR Catalog backup emails. The article referenced is no longer publishied. Can the fix be posted here?
No mention of it here in the LBN:
...and no mention of it in the EEB guides for 8.1.1 or 8.1.2 or 8.2
@Michal_Mikulik1 hoping you might be able to expand upon how you solved it, and what the true root cause might have been, and if there is a work-around ?
I wonder if our 'resident' Veritas experts can assist here?
Could you please assist in locating the missing article with details on how to fix the issue?
THANKS in advance!
I'm unable to find the article internally either, but I am (mostly) aware of what it suggests to do, as this problem occurred at a customer of mine (I was able to see the public article at the time).
The file the article was suggsting to unlink is a script in /usr/openv/netbackup/bin. The file is mail_dr_info.sh which is a symbolic link into the appliance script directory. I don't recall if there were additional details besides removing the file (the symbolic link, not the actual file).
Since Veritas has pulled the article, this sounds like this is not the proper solution to the issue (I know in my case the result was that the recipient was recieving multiple emails for every catalog backup - but at least receiving something). I haven't personally had a chance to follow up with the customer yet to find a propoer fix.
Use the above information at your own risk - I can't see it doing any real harm - but keep track of the original location of the symbolic link (or better yet, simply move the file out of the bin directory).
This was the fix for my issue:
Workaround: unlink the /usr/openv/netbackup/bin/mail_dr_info.sh symbolic link from elevated prompt:
# unlink /usr/openv/netbackup/bin/mail_dr_info.sh
I've discovered the proper fix for this issue. However it requires opening an elevated command prompt in the CLISH and as such I am reluctant to share this here.
That said, it is a relatively simply fix to the mail_dr_info.sh file (that should remain in place and not be unlinked as I suggested previously). If you open a support case and reference this case number (190806-000439) indicating you have a similar issue, support should be able to fix the problem or you.
If you need to put the link back (if you did remove the file/link), the command to run would be:
# link -s /opt/NBUAppliance/scripts/mail_dr_info.pl /usr/openv/netbackup bin/mail_dr_info.sh
(I know the extensions are different!).
Veritas really need to get better with their supporting documentation.
We've spent a good few weeks looking at this and finding any info on it has been very hard.
The original article has been archived and there is a new article but it is again restricted for internal use only.
If you are having this issue then log a case and reference either the original article number or the new one (which is 100047439).
A better option may be to upgrade to appliance version 3.2 and apply EEB from ET 3997942 where this problem is supposed to have been fixed.