Technologies

What Our Customers Are Saying

Reverse Polarity has been our partner in inventive solutions and competitive edge since 2002 - from consulting to firewall configuration and maintenance. Security as our number one priority, we have been relieved of the burden so many have carried, with Reverse Polarity at the helm. We started our business in the Northwest corner of Connecticut and had it nourished and protected from the ravages of technology by Reverse Polarity. I shudder to think of where we would be without their help. Long live the small business owner!

In April of 2013, a request was made on the Bacula mailing list for a way to get daily and weekly backup reports. This got me to thinking that such a daily email would be useful.

So, off I went to write a simple bash shell script to generate these reports. Over time, many features were added to this script and it has evolved quite a bit over the past 4 years. The original posting about this script may be found here: http://www.revpol.com/baculasummaryemails-ORIG

The script expects to see one command line parameter which is the number of hours to report on. The following would generate a report going back 24 hours:

$ baculabackupreport.sh 24

The plain text version of this email report would something look like this:

This is at least the second time I have seen this suggestion. I think I do have a github account already, so this is probably where it will end up - unless someone else has already done so - it is open source you know. :)

Hello,
Very interested in your bacula backup report script. Just downloaded the current version and tried running it against my setup, but got a "psql: FATAL: Peer authentication failed for user "bacula"
" error. Which is very strange because user bacula is the same as in my bacula-dir.conf file and that runs every night.

My guess is that with "peer" authentication in postgresql, you cannot run this script as the root user because the script is going to run the psql command as user "root", but tell the postgresql database server that it is user "bacula".

There are other types of authentication settings for postgresql, and you can edit the pg_hba.conf and pg_ident.conf files to configure this to allow, for example, root unix user to log in as bacula db user.

If you are not too concerned about outside access to this DB server, you can set the postgresql auth to "trust" and this problem disappears.

Also, I run this nightly from the bacula user's cron, so this problem you are seeing would also disappear since the bacula user will be the one running it: